Windows 64-bit registry v.s. 32-bit registry

Question

I heard on Windows x64 architecture, in order to support to run both x86 and x64 application, there is two separate/different sets of Windows registry -- one for x86 application to access and the other for x64 application to access? For example, if a COM registers CLSID in the x86 set of registry, then x64 application will never be able to access the COM component by CLSID, because x86/x64 have different sets of registry?

So, my question is whether my understanding of the above sample is correct? I also want to get some more documents to learn this topic, about the two different sets of registry on x64 architecture. (I did some search, but not found any valuable information.)

Semiotics

Answer 1

I ran into this issue not long ago. The short answer is that if you run a 32 bit application on a 64 bit machine then it's registry keys are located under a Wow6432Node.

For example, let's say you have an application that stores its registry information under:

HKEY_LOCAL_MACHINE\SOFTWARE\CompanyX

If you compile your application as a 64 bit binary and run it on a 64 bit machine then the registry keys are in the location above. However, if you compile your application as a 32 bit binary and run it on a 64 bit machine then your registry information is now located here:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\CompanyX

This means that if you run both the 32 bit and 64 bit versions of your application on the same machine then they will each be looking at a different set of registry keys.

Ryswick

A quick question, if I am using regsvr32 to register a COM component, how did we know whether we register under x86 or x64 registry? My ocnfusion is, if registered under x86 registry, x64 application will not be able to access the COM component? – Semiotics

There are two versions of regsrv32 on a 64 bit machine. One registers 64 bit binaries and one registers 32 bit binaries in the Wow6432 node. This Microsoft kb article might be helpful to you: support.microsoft.com/kb/282747 – Ryswick

1. when we register a new COM component using 32-bit regsvr32, the COM component must be built for x86 (when we register a new COM component using 64-bit regsvr32, the COM component must be built for x64) -- means we can not use 32-bit regsvr32 to register 64-bit COM component (or using 64-bit regsvr32 to register 32-bit COM component), correct? 2. 64-bit process could only acccess x64 registry for COM CLSID, and 32-bit process could only access x86 registry for COM CLISD, no cross access. My understanding correct? – Semiotics

That's my understanding of it, but I offer no guarantees :). I only dealt with this in passing once a couple of months ago. – Ryswick

if I develop native COM component targetting for both x86 user and x64 user, then I need to provide two different builds (x86 build and x64 build)? No way to save my work by providing only one build for native build and fit for both x86/x64? – Semiotics

A 32 bit binary will work on both platforms, but if you specifically want to offer a 64 bit version of your binary then yes, you need to build one for each platform. – Ryswick

It IS possible to call a 32-bit COM DLL from a 64-bit process. To do this you either: introduce a 32-bit exe which hosts the 32-bit DLL, or let Windows handle it for you via DLL Surrogates (learn.microsoft.com/en-us/windows/win32/com/dll-surrogates) – Clevey

Answer 2

Your understanding is correct. There wouldn't be any need for a x64 app to access the x86 CLSIDs since it could never load those components anyway and vice versa.

If you want to create component for use by both x86 and x64 then you need to either create a pair of dlls one built for x86 and the other for x64 and register both in their appropriate parts of the registry. The regsrv32.exe in the System32 folder will perversely register the x64 component and the regsrv32.exe in the SysWOW64 folder will register the x86 component.

Alternatively build a .NET assembly for Any CPU which can used by either CPU architecture.

Schistosome

@AnthonyWJones, I am interested in the .Net Any CPU sample you mentioned. Suppose I have a .Net applicaiton built for Any CPU, and run it on x64, then it should be JITed to access x64 version of registry -- i.e. CLSIDs of COM registered under x64 registry? My understanding correct? – Semiotics

In that scenario its not JIT or .NET that decides which part of the registry to look up CLSIDs its the fact that the process in which the code is running is 64 bit which determine which set it will use to look up CLSIDs. This is something which happens automatically inside the COM support libraries installed in windows. – Schistosome

1. when we register a new COM component using regsvr32, do we register it under x86 registry or under x64 registry or under both? 2. My understanding is, 64-bit process could only acccess x64 registry for COM CLSID, and 32-bit process could only access x86 registry for COM CLISD, no cross access. My understanding correct? – Semiotics

Its not clear whether you are creating a COM component or trying to use one? My reference to .NET relates to the ability to create an assembly dll which will work in either a 32bit or a 64bit process. You are correct a 64bit process cannot load a 32bit dll and vice versa. – Schistosome

Sorry, I did not state my question clearly. Let me say again in some other words. :-) For a native COM component, if it is x86 then we should register it under x86 registry using x86 version of regsvr32, if it is x64 then we should register it under x64 registry using x64 version of regsvr32. And there is not all in one version of native COM component which fit for both x86/x64, so that we can register once and both x86/x64 process could load the in-proc COM component. My understanding correct? – Semiotics

@AnthonyWJones, if I develop native COM component targetting for both x86 user and x64 user, then I need to provide two different builds (x86 build and x64 build)? No way to save my work by providing only one build for native build and fit for both x86/x64? – Semiotics

Answer 3

They aren't separate registries--one is a subnode of the other, and the OS does virtualization to make sure that 32bit apps get their keys and 64bit apps get their keys.

Gast

The MSND article posted above is probably the best place to start. msdn.microsoft.com/en-us/library/ms724072.aspx – Gast

A quick question, if I am using regsvr32 to register a COM component, how did we know whether we register the COM component under x86 or x64 registry? My confusion is, if registered under x86 registry, x64 application will not be able to access the COM component? – Semiotics

So, it is why I want to know whether it is registered under x86 or x64. I think when we register it using regsvr32, we register under either x86 or x64, not under both? – Semiotics

Yes, you generally only register as one, since your control will either be in a 32bit DLL or a 64bit DLL, and you can't load a 32bit control into a 64bit process (and vice-versa). So you probably want to register the 32bit one and the 64bit one separately. However, I've never done this, so I'm not sure if that is the correct way to do it or not... – Gast

So, if I want to build a COM component for both 32-bit process and 64-bit process to use, I need to register twice and build two COM component -- x86 build and x64 build, and register one under x64 registry and the other registered under x86 registry? – Semiotics

when we register a new COM component using 32-bit regsvr32, the COM component must be built for x86 (when we register a new COM component using 64-bit regsvr32, the COM component must be built for x64) -- means we can not use 32-bit regsvr32 to register 64-bit COM component (or using 64-bit regsvr32 to register 32-bit COM component), correct? – Semiotics

Note: It is not virtualisation that is going on here it is redirection. If a 32bit component attempts to read a registry value HKEY_LOCAL_MACHINE\SOFTWARE\Google it is silently redirected to HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Google – Synthiasyntonic

Matt, yes, you are right. That's what I meant. Thanks for clearing it up. – Gast

Answer 4

I run an x64 bit machine as my desktop; and I have never run into any issues with the different registry configurations.

Per MSDN, there is apparently a difference: http://msdn.microsoft.com/en-us/library/ms724072(VS.85).aspx

HTH

Frisket

Answer 5

Here is the Wikipedia article on the WOW64 registry which may give you some of the information you are looking for:

http://en.wikipedia.org/wiki/WOW64

Effortful

Suppose I have a .Net applicaiton built for Any CPU, and run it on x64, then it should be JITed to access x64 version of registry -- i.e. CLSIDs of COM registered under x64 registry, and if I register a 32-bit COM component, the .Net application will not be able to find it? My understanding correct? – Semiotics

Answer 6

How to register .NET assembly to be used as COM in pure 64-bit application?

Problem: By default, if you enable "Register for COM Interop" in build settings, it DOES NOT register type library for 64-bit.

Solution: To register your assembly which is not in GAC on a 64-bit machine, open cmd window and do:

cd c:\windows\microsoft.net\framework64\v2.x.xxxxx
regasm /codebase "path to your compiled assembly dll"

This will eliminate "Class Not Registered Error" when using native C++ to instanciate .NET assembly as COM object.

Bennybenoit

This is precisely what was causing my 64 bit mixed mode application to fail - the assemblies were being 32 bit com registered by Visual Studio 2010. So instead of Register for COM interop, I put post build events to regasm as above (with /TLB generation in my case). Is there an MSDN article related to this behaviour? – Haiku