Unusual Referencing of the Registry between 32-bit and 64-bit apps

To all:

Our team has discovered another strange referencing issue, this time with
the Registry between 32-bit and 64-bit. I am wondering if others also see
this and what their workaround is.

If you run a script or application under a 64-bit context and create a key
under HKLM, it appears as normal.
Example: HKLM\Software\Test64

If you execute Regedit under a 32-bit context, the key does not exist.

I believe this is due to the 32-bit Registry being mapped to
HKLM\Software\WOW6432Node.

We confirmed which bit versions were running by checking the Task Manager.
TaskMan displays 32-bit apps with an extension of "*32". 64-bit apps do not
have this extension.

So, my question is: if we run applications, scripts, HTAs, etc under 64-bit
and then have some applications that are NOT 64-bit aware but require access
to these Registry areas, how do we manage this?

One simple solution would be to always write to the \WOW6432Node area of the
Registry. However, this defeats the purpose of going towards 64-bit.

Any help would be much appreciated.

 

Have you tried manually reflecting that key with RegEnableReflectionKey?

Philip Sloss

 

Have you tried manually reflecting that key with RegEnableReflectionKey?

No. I've never heard of that. I'll Google it right now but have you got
more information?

many thanks,

 

I haven't tried it myself, I'm just aware of the documentation -- it's in
the online MSDN Library. Browsing through it, I also find this:
http://msdn.microsoft.com/library/en-us/win64/win64/accessing_an_alternate_registry_view.asp

Which suggests that the KEY_WOW64_64KEY flag might also work without manual
reflection...

The whole WOW64 section might be useful:
http://msdn.microsoft.com/library/en-us/win64/win64/running_32_bit_applications.asp

Philip Sloss

 

Excellent. I've gone through the pages and it appears to do what is needed.
However...

We have developed an automated system build process with HTAs, WSFs, and VBS
scripts, which work on both the 32-bit systems and 64-bit systems. But
we're seeing registry differences when we go to look after we've written
something. It's not where it's supposed to be; i.e. written by 64-bit and
can't be seen by 32-bit, and vice versa.

And the function calls that are described are based on C code (or a
derivative thereof.) It will not work for script code since library
handling is difficult if not impossible.

But I'm going to run some tests and see what I can do with a basic test
script.

If anyone can assist in this problem using scripts, it would be well
appreciated.

Many thanks for all your help.

 

I've written a VBS script that determines what architecture (x86, AMD64,
etc.) and what platform (64 or 32-bit). It creates a key with these two
values and writes it to the Registry; HKLM\Software\{new key}.

As expected, writing under a 32-bit context does NOT write to the same place
as under a 64-bit context. Using a 64-bit RegEdit.exe, I can see the 64-bit
key as expected, and under \Wow6432Node, I see the 32-bit key.

Since this difficulty is compounded by an .HTA running only the 32-bit
MSHTA.exe, what happens when the HTA executes a WSF or VBS script? Which
bit version? And if we execute CMD.EXE via any of these methods, what
version runs?

Very confusing, to say the least. Does you have some ideas about how to
stay in 64-bit under all conditions?

many thanks for your help,

 

Have you looked into using RegDisableReflectionKey()?

See:
http://msdn.microsoft.com/library/d...n-us/sysinfo/base/regdisablereflectionkey.asp

Rafael Rivera
Extended64 | http://www.extended64.com
Blog | http://www.extended64.com/blogs/Rafael

 

Thanks, Rafael.

But what I desire is the functionality to write to the 64-bit area of the
Registry from SCRIPTS, i.e. HTA, VBS, or WSF.

From what I gather on the MSDN pages, these functions are available under
C++++, maybe VB, but NOT scripts. There is no MS-approved method to
reference libraries from scripts.

Thinking about this problem last night, I imagined a new Registry hive key
like, HKEY_LOCAL_MACHINE64, which would be available to 32-bit apps that
points to the top of the 64-bit hive. This would solve all our problems.

Ok, it appears that MS has again dropped the ball because this is only one
of many issues we're having with discrepancies between 32-bit and 64-bit on
an x64 machine. These issues aren't related to hardware, as we're using HP
but in developing world-class software, especially a system build process
that works across 32 and 64-bit systems.

If you can think of anything that works under scripts, it would be well
appreciated.

Many thanks for all your help.

--
Mark-Allen Perry
ALPHA Systems
Marly, Switzerland
mark-allen_AT_mvps_DOT_org