How to delete 64 bit Registry keys/values (.NET 3.5)

• Download source code - 12.6 KB

Introduction

This tip showcases how to access (delete only) a 64 bit registry key/value from 32bit built application in .NET3.5 and lower. For example, in order to delete registry key "Sample" from the following registry entry "HKEY_LOCAL_MACHINE\Software\Sample" from a 32bit application wouldn't be possible because due to registry reflection, the registry opened for delete would be "HKEY_LOCAL_MACHINE\Software\Wow6432Node\Sample". This is a Microsoft way of reflecting a different registry node on 64bit operating systems.

The sample project includes a set of interop functions and makes use of the native Win32 registry API to disable registry reflection so that the 32 bit built application can access the 64 bit registry keys.

Background

While developing a custom application, I ran into situations to delete 64 bit Registry entries. The application had tight constraints: The target platform had to be "X86" built and the .NET Framework is 3.5 version. I am sure many of you are aware that it is not possible to delete a 64 bit Registry entry from an application built as 32 bit application type (for more info on registry redirection, read this MSDN article). We have to make use of the native Win32 API Registry methods in order to achieve this. However in .NET 4, there is a straight forward way to achieve this as the Registry class has been extended to support this. The PInvoke support is very good, but they suffice to single methods only and doesn't give a simple but elaborate sample to do this. The sample code is tested on the following Operating Systems: Windows XP 64bit, Windows7 64 bit.

Using the Code

There are two main classes in the sample project:

• RegistryInterop - which has the main Win32 registry interop methods
• X64RegistryKey - class which has methods to open, enumerate, delete and close 64bit registry keys/values. This class is derived from IDisposable so that in the Dispose() method all the native handles can be closed that are opened using the RegistryInterop.

The user has to create an instance of the X64RegistryKey class in order to read, enumerate or delete any 64 bit Registry keys from a 32 bit application.

Note: The logic to determine an application is running on a 64 bit/32 bit OS is not covered here as it doesn't serve the purpose. There are lot of online articles that have discussed this in detail, CodeProject being one of them. The sample project assumes that the code would be executed on a 64 bit machine.

// Delete a subkey (a registry tree) from HKEY_LOCAL_MACHINE
private void DeleteKey(string subkey)
{
    // Open HKEY_LOCAL_MACHINE
    using (X64RegistryKey basekey = 
            new X64RegistryKey(RegistryInterop.HKEY_LOCAL_MACHINE))
    {
        UIntPtr key = UIntPtr.Zero;
        if (X64RegistryKey.SUCCESS == basekey.Open(subkey, out key))
        // open the subkey under HKEY_LOCAL_MACHINE\subkey to delete it
        {
            using (X64RegistryKey regkey = new X64RegistryKey(key))
            {
                // call this method to disable registry reflection,
                // so that the 64bit registry can be deleted
                regkey.DisableReflection();
                regkey.RegDeleteValue(Value);
            }
        }
     }
}

Points of Interest

There is a similar concept for files and folders and this is called the file redirection, wherein a 32bit app will not be able to access specific files and folders 64 bit operating systems. For example, if a 32bit application queries the environment variable %PROGRAMFILES%, the value returned would be "c:\program files <x86>" because this is the program files equivalent folder for 32bit applications running on 64 bit operating system. I will be coming up with another article to showcase how to disable file redirection. For most of the interop functions, I have extensively relied on http://www.pinvoke.net/. This site offers a wide variety of interop methods and has some very good supporting sample code. Also check for registry reflection on MSDN.

History

• First update: 21 July 2012.