I am running 64-bit Windows, and I want to create the registry key HKCU\Software\Classes\Wow6432Node\CLSID\{myguid}\InprocServer32 using C#.
What registry key should I tell it to write, so that it will be redirected to the above key? This should also work on 32-bit Windows.
I am compiling my app to target x86.
If you are using .net 4 you should make use of the RegistryView enumeration.
Pass RegistryView.Registry32 when you call OpenBaseKey. Use HKCU\Software\Classes\CLSID{myguid}\InprocServer32 as your key and let the redirector do the work.
If you are using an older version of .net then I am afraid you will need to p/invoke the native Win32 API.
If you happen to be targetting x86 then you don't need to do anything. The registry redirector will do the right thing and redirect your registry access to the 32 bit view of the registry. You only need to take the steps outline above from a 64 bit process.
64-bit versions of Windows emulate 32-bit functionality through the "Windows on Windows" (WoW) subsystem.
In the case of the registry, they move the 32-bit keys over to a special subkey for compatibility reasons. It will automatically redirect 32-bit registry operations to HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node. More details can be found on the MSDN topic about the Registry Redirector.
You can use the RegistryView enum on RegistryKey.OpenBaseKey to open the 32-bit view explicitly and access HKCU\Software\Classes\CLSID{myguid}\InprocServer32 directly. This will automatically access the WOW64 node on 64-bit systems and the normal key on 32-bit systems.
Since you are targetting x86, simply using HKCU\Software\Classes\CLSID\{myguid}\InprocServer32 will work on all platforms.
By default your C# application is compiled using "Any CPU" (this is the default -- it means that your program will run as a x86 exe on x86 machine, and x64 on x64 machines). What you want to do is change the setting to Win32.
Now your program will always run as an x86 exe, so it will be automatically redirected by windows the WOW6432Node. When you access the HKCU\Software\Classes\CLSID{myguid}\InprocServer32 on an x64 machine you will be redirected to the desired key.
Related
Please correct me if I'm wrong on this, as I'm certain I read it somewhere: Registry virtualization is disabled for Windows Services. Also, virtualization is disabled for x64 binaries.
I have a windows service written in C# that needs to load a value from HKEY_LOCAL_MACHINE\SOFTWARE. When I compile the service as x86 and start it, it fails to read the value. When I compile the same code as x64 and start it, it reads the value just fine. I want my service to be able to run on x86 machines in addition to x64 machines, but it needs to also be able to read this value. How do I get my windows service to read the value non-virtualized?
Registry virtualization is disabled for Windows Services. Also, virtualization is disabled for x64 binaries.
Yes, you're right, it's disabled for 64 bit processes and for "processes that are not interactive, such as services".
Take a look to my previous post here on SO for some details about registry views. Please do not confuse views with virtualization. They're different. Views are needed to isolate 32-bit application from 64-bit applications.
In C# you can do the same simply asking the OS to open the 64 bit version of the registry:
RegistryKey baseKey = RegistryKey.OpenBaseKey(
RegistryHive.LocalMachine, RegistryView.Registry64);
RegistryKey key = baseKey.OpenSubKey("Software", false);
object value = key.GetValue("");
If your application/service will run in a 32-bit machine you'll always get the normal registry even if you ask for RegistryView.Registry64. When running in a 64-bit machine you'll always get the normal version of the registry (= 64-bit version).
Side question: why do you need to compile your application as X86 or X64? Can't simply keep AnyCPU?
Virtualization has a different purpose and it's not intended to separate the registry from 32 bit applications but to increase compatibility with legacy applications, we all hope that a 64 bit native application will use the registry in the correct way. To access the non-virtualized version of the registry you have to open the registry key using REG_KEY_DONT_VIRTUALIZE flag. It's not possible to use this flag with Microsoft.Win32 classes so you have to DllImport them and P/Invoke.
How to get a list of subkeys in the HKLM\SOFTWARE in the 64 bit system?
P.S. If I use
Registry.LocalMachine.OpenSubKey("SOFTWARE\\", false)
then I get in HKLM\SOFTWARE\Wow6432Node
I can use the .NET Framework is not higher than 2.0
The answer seems quite involved, and probably too much code to put here on Stack Overflow.
The summary is that you need to P/Invoke to access the native Windows API Calls for RegOpenKeyEx, and make sure to pass in the flag KEY_WOW64_64KEY to always access the 64bit registry. (KEY_WOW64_32KEY being the flag to always access the 32bit one)
A partial solution has been posted on this blog entry.
For anyone that can run .NET 4.0, then you can use the new support for this: RegistryKey.OpenBaseKey(RegistryHive.LocalMachine, RegistryView.Registry64);
You will get the registry for whichever architcture your app is running on or compiled for.
If you target x86 then you will always get the 32-bit registry ("Wow6432Node") on a 64-bit machine.
If you target AnyCPU, then you will get the real Software node for the machine's architecture.
I have an application (written in C#), which runs on an Windows Server 2008 (64bit). In this application I must check some registry keys regarding the IIS. Among others I want to access the key HKEY_LOCAL_MACHINE\Software\Microsoft\InetStp\Components\WMICompatibility"
to check if the IIS 6 compatibility mode is enabled or not. For this I use Registry.GetValue of Microsoft.Win32.
For some reasons the solution must be compiled with x86. The consequence is, that it is no longer possible to access HKEY_LOCAL_MACHINE\Software\Microsoft\InetStp\Components but it is still possible to read key from HKEY_LOCAL_MACHINE\Software\Microsoft\InetStp. When compiling it with "AnyCPU"-flag the registry-access works fine.
So what is the reason for this behavior? Is there a solution or workaround for this problem?
You are falling foul of registry redirection.
The best solution is to open a 64 bit view of the registry, like this:
using Microsoft.Win32;
...
RegistryKey registryKey =
RegistryKey.OpenBaseKey(RegistryHive.LocalMachine, RegistryView.Registry64).
OpenSubKey(#"Software\Microsoft\InetStp\Components");
object value = registryKey.GetValue(#"WMICompatibility");
If you want your code to work on both 32 and 64 bit machines then you'll need to code some switching between registry views.
Note: The capability of accessing 64 bit views from 32 bit processes was only added to the .net libraries in .net 4. It seems that prior to that you needed to use native APIs, e.g. with P/Invoke.
Windows x64 has a separate node for x86 programs (not the brightest idea)
All registry keys will be under HKEY_LOCAL_MACHINE\Software\WOW6432Node
More about this issue:
How to view the system registry by using 64-bit versions of Windows
The program still "thinks" it's writing to the same path.
I'd suggest you fix your setup (dispatch) program to write the initial settings in the right place.
Edit, Some "information" from MSDN:
Registry Keys Affected by WOW64
I have a .NET component written in C# that needs to register some registry values under the HKLM hive. I'm expecting this component to be installed on both x86 (32-bit) and x64 (64-bit) boxes running the appropriate flavour of Windows. On 64-bit systems, I want to make sure the component can be used by both 32- and 64-bit hosting processes. I'm stuck with using Visual Studio's deployment projects for the time being.
What I want is for my installer, when run on 64-bit systems, to put its registry entries under HKLM/Software/Blablah, so that when running in a 64-bit process, my component can find its global configuration settings. However, if my component is hosted by a 32-bit process running on the same machine, then it will read from what it thinks is the same key, but which Wow64 will translate to HKLM/Software/Wow6432Node/Blablah.
Is it OK to author my 64-bit installer so that:
it is marked as a x64 installer
it writes the entries under HKLM/Software/Blablah for the benefit of 64-bit processes
it writes exact copies of those entries under
HKLM/Software/Wow6432Node/Blablah for the benefit of 32-bit processes on the same machine.
I'm guessing that because I've marked the installer as x64, I will be forced to author another separate installer specifically for 32-bit systems, which only writes to HKLM/Software/Blablah.
The normal practise is to have both 32 bit and 64 bit install packages. On the 32 bit machine you just run the 32 bit package, on the 64 bit machine you run both.
Trying to handle all the registry and file redirection yourself is a nightmare and it's much better to install a 32 bit package on a 64 bit machine and let the system do the redirection for you. You've got to produce the 32 bit package anyway for 32 bit machines, so it's no extra work.
I'm updating my operating system to Windows 7 x64, I only have experience with running 32-bit operating systems. Does anyone have any bad/good experiences with a 64 bit environment?
For reference, the tools I use are:
Visual Studio 2008
Tortoise SVN
TestDriven.Net
Oracle 10g XE
PL/SQL Developer
Dundas Chart
Analysis Services from MS SQL Server 2008
Running on a 64-bit operating system has a number of side effects that will be noticeable to some extent. The most common issues:
Edit and Continue in Visual Studio won't work. You can fix this by forcing your .NET app to run in 32-bit mode. Project + Properties, Build tab, Platform Target = x86. Resolved in VS2013.
If you use any ActiveX controls or COM components in your .NET app you may find your program no longer works since your machine doesn't have a corresponding 64-bit version of the COM server. You'll get error 0x80040154, REGDB_E_CLASSNOTREG, "Class not registered". Same fix as above.
The 64-bit debugger doesn't support mixed-mode debugging, you'll have to commit to either Managed only or Native only debugging. Same fix as above, as long as you don't have 64-bit specific issues. Resolved in VS2010.
Poorly written P/Invoke declarations that declare an uint or int where an IntPtr is required will stop working in 64-bit mode. You'll generally get an AccessViolation exception or a failure return code. Or a PInvokeStackImbalance MDA warning. You should not have any trouble locating the mistake, just fix the declaration.
Several legacy end-of-life Microsoft libraries are not available in a 64-bit version. That's most commonly a problem with Microsoft Access databases. Same fix as above.
You must use the correct version of Regasm.exe to register [ComVisible] assemblies. Select the one from either Framework or Framework64, depending on whether the client program is going to run in 64-bit or 32-bit mode. Or both if you want the server to be available in either.
A few COM type libraries contain bit-ness dependent arguments in their method declarations. ADO 2.8 is a notable one. Be sure to use the correct bitness of Tlbimp.exe to generate the correct COM interop assembly, Visual Studio won't do this right. Same approach as Regasm.exe
A 32-bit program has a different view of the registry from a 64-bit program. Specifically the HKCR and HKLM\Software hives are virtualized. In Regedit.exe, the 32-bit visible keys are seen under the HKLM\Software\Wow6432Node key. This can cause many subtle problems with programs that use the registry. The .NET 4 RegistryKey.OpenBaseKey() allows specifying the view you want.
Again for COM, you'll have the use the correct bitness of Regsvr32.exe to register an unmanaged COM server (not .NET servers, they use Regasm.exe). Use the one in c:\windows\system32 for 64-bit servers, c:\windows\syswow64 for 32-bit servers.
Folders in the file system are virtualized, specifically c:\windows\system32 and c:\program files. A 32-bit program will see c:\windows\syswow64 and c:\program files (x86).
Installers need to take all the above issues in consideration.
I wouldn't worry too much, if each program has an x64 download link, then use that. If not then your code will run through WOW64 emulation. And it will seem to you like it is running like normal.
Please see this related question I answered about 5 minutes ago.
WOW64 refers to windows32 on windows64
and it is a transparent emulation
laywer that allows x86 programs to run
on x64 operating systems. WOW64 will
automatically be used if you run an
x86 Windows program on an x64 Windows
operating system.
I am running Windows 7 Ultimate x64.
Visual Studio 2008 works fine.
I am using Subversion, but not Tortoise. AnkhSVN works fine.
The others I have no experience with.
Majority of software I use has no issues with x64, it's been a few years since the XP x64 troubles, and people have caught up with x64 it seems.
The primary issue with development in x64 however, is when running in x64 mode in Visual Studio, you can not edit code while debugging.
You must use x86 as the target platform in order to do so.
This is one of the reasons one of the beta's for Visual Studio 2010 defaulted target platform to x32 instead of Any Platform...