A linear system doesn’t fit into a round world

I´d suggest you to see this video…

 

Sustainability

 Equity

Green Chemistry

 Zero Waste

Closed Loop Production

 Renewable Energy

Local Living Economies

 

No more words are necessary.

Fixing the “nVidia Control Panel gone”, the “System has not been modified” issue, and other nVidia drivers installation problems

Today, coming from nowhere, my nVidia control panel stopped working. It is not the first time that happens to me, so I did not worry so much. Things got worse when I rebooted the machine, and saw that my Windows lost the entire nVidia Display Driver. The strange thing was that it didn´t switch back to the VGA adapter. Instead, in the adapter settings you could just read: “Plug&Play monitor in “ and a very scaring whitespace behind. Things got even worse when I saw that, no matter which version I tried, the nVidia display drivers refused to re-install again.

Honestly, I saw myself re-installling windows (something I haven´t done in a long time, I must admit), but as one grows older, accumulates more and more “essential” applications that would take ages to re-install. And now I simply didn´t have the time, so I started investigating. It has taken me the whole afternoon and evening, so hope it helps someone else as well…

Things I tried

Reading forums and forums, I think I tried everything:

• Change the regional settings before trying to install, as it seems some drivers presented issues with non-U.S. regional settings
• Uninstall all nVidia drivers, reboot in safe mode, and install the new ones there
• Use driver cleaner applications, like Driver Sweeper (from Guru3D) or Driver Cleaner Pro, to check if I had wrong, partial installations which refused to remove. Be careful with this kind of applications however. It´s pretty easy that they screw up your PC.
• I tried switching back to the most recent Restoring Point, but the effects appeared again.
• And many others…

All of them with no luck.

What was finally the cause of all evil

In one of the previous steps trying, I noticed that one of the nVidia applications installed (the nVidia PhysX Plugin for MAX), refused to un-install using the standard method. Luckily, it gave a bit more of information: “Access denied trying to access the key HKLM\Software\NVIDIA Corporation\PhysXPluginsForMax”. That caught my attention, as it was obvious that there was a problem with the registry.

Opening Regedit.exe, and navigating to that key, I realized that was not the only nVidia registry key with “Denied Access” problems. You just couldn´t read or modify the contents of keys like: “Global”, “Installers”, or “PhysXPluginsForMax” itself. The only thing you could do with those keys was seeing their security permissions.

The funny thing was that when selecting “Permissions”, you could see a message like the following:

Translation: “You don’t have permissions to read the actual permissions of key “XXX”, but you can make changes in the permissions”. Apart from the fact that seems a tongue twister, it seems a joke. You cannot read your permissions but you can write them? May be it’s a translation bug in the Spanish version of Windows Vista, because you actually can see the permissions, but cannot change them (much more logical).

After opening the window, you will find something like this:

The main problem here is that the box with the label “Names of groups or users” is empty. It means that no-one can actually access this key, and that´s why the Control Panel and the Display Drivers installers are failing.

Note: If this also happens to you, you would worry about what is happening in your system, as having that keys this way is a serious security problem, as any user could get control of them. Please read the conclusions chapter, about what can lead to this situation

Other Symptoms that could lead to the same cause

• nVidia control panel gone
• nVidia display driver gone
• Some nVidia applications refused to un-install
• nVidia display drivers refusing to install
• Some nVidia applications refusing to install
• nVidia display drivers showing the message: “The system was not modified”
• Others.

How to fix it

Obviously, the way to fix it is just re-assign users permissions to those keys. But how to do that if you don´t have permissions to change the permissions?

Thankfully, one day God thought it was a good idea to create Mark Russinovich and David A. Solomon, the two genius behind SysInternals. Mark also created PS Tools, a suite of tools that help managing Windows. One of the small apps distributed with PSTools is PsExec, which can run processes remotely, and is able to run them inside the SYSTEM account, instead of the current user. And that’s the key to be able to change the registry in this circumstances.

So:

1. Download PSTools
2. Run the Command Prompt in Administrator mode (Start->Programs->Accesories->Command Prompt with the right button->Run as Administrator)
3. Navigate to the folder where you downloaded PSTools
4. Run the RegEdit process from the SYSTEM account, and allowing it interact with the windows desktop, typing:

“psexec –s –i regedit.exe”

Regedit will open, but this time from the SYSTEM account, where you should be able to change those keys permissions. Now:

1. Go to each key you want to change (do this at least for all nVidia keys), adding where necessary the usual users or groups to each key: your own user, SYSTEM itself, Administrators, etc.
2. Grant to those users permissions to read and write in those keys
3. Close RegEdit.

Now, you should be able to un-install and re-install everything again, and your drivers won´t complain anymore.

 

Conclusions

 

As I mentioned, having those keys with no users is a serious security problem. But, who is responsible for leaving them like that? A virus? I honestly don´t know, and I´m going to investigate it.

 

In my case, I think it is more due to a too dirty computer than a virus. But who knows! If anyone of you can give me a hand with this, it would be much appreciated.

 

Cheers!

Jaaaaa ja ja ja jaaa ja ja jaaaa….. Los conversores se van al diablo, buey!

Dios mío de mi vida, lo que hay que oír… Me duele partirme tanto la caja a costa ajena, sobre todo con alguien que ha intentado compartir sus conocimientos, algo que aplaudo efusivamente. Pero es que… la cosa da para mucho. Os explico: resulta que buscando ayuda en google acerca de un temilla con WinRar, me he encontrado con una página cuyo contenido no podía creer mientras la leía. Más concretamente es ésta.

Me llamó la atención porque la entrada en google decía algo así como…: “Como utilizar WinRar para convertir cualquier archivo a CUALQUIER formato”. No se por qué, me llamó la atención la tontería y me puse a leer…

El avispado autor de este “truco”, explicado paso a paso con pelos y señales a modo de tutorial, incluso con pantallazos, afirma lo siguiente… y cito:

“Bueno, al fin despídanse de conversores de videos, imágenes, música y cualquier otra cosa, con este truco los conversores se irán al diablo!”

Dios mío, mi curiosidad iba in crescendo… Seguimos:

“Que necesitas: -El archivo que quieres cambiar -Winrar PASO 1 Tenemos nuestro archivo preferiblemente en una carpeta sola”

Aquí la inquietud me desborda… ¿Por qué en una sola carpeta?

PASO 2 Lo comprimimos en Winrar PASO 3 Abrimos el winrar del archivo

Y aquí viene el truco mágico, el cual posibilita que cualquier formato pueda ser convertido en cualquier otro.

<<OJO LO ABRIMOS PERO NO LO EXTRAEMOS>> ahora podrán ver q sale el nombre del archivo y su extensión por ejemplo: PASO 4 Le damos Click derecho al archivo y luego renombrar PASO 5 Cambiamos la extension a la extension del archivo que queramos, por ejemplo yo puse .avi y listo ya convirtieron el mald**to archivo.

Lo mejor son las contestaciones. Algunas de ellas:

• “Gracias, gracias, gracias, gracias, gracias, estube usando el truco para bajar los videos de youtube y cuando me quise bajar el conversor de videos rapidshare me decia que espere como 70 años, ahora pruebo el truco”
• “Gracias Man Necesitaba Cambiar Unos Archivos A .XML Thank`s”

Y la respuesta del autor:

• “Jejeje Gracias por q les haya gustado este truco tambien puede servir para convertir MP3 a MID algo q no puede hacer ningun conversor O_O”

Curioso invento, esto del WinRar. Parece que al fin se demuestra que esto de los codecs, los bitrates y todas las hostias son un invento de las grandes corporaciones para que nos rasquemos el bolsillo.

Creo que voy a coger el mío y lo voy a usar para convertir los calcetines que me regalaron en navidad en una XBox360…

¡Ah no, espera! Que el WinRar no hace falta para nada, solo tengo que renombrar

• RegaloDeReyes.Calcetines_De_Los_Cojones

por

• RegaloDeReyes.Xbox360

Juas!

Pd: Cuánto daño ha hecho la configuración por defecto de Windows, que oculta las extensiones para los tipos de archivos conocidos…

Pd2: Ánimo chaval. No te deprimas por estos comentarios y continúa compartiendo lo que sabes. Estés equivocado o no, es mucho más de lo que la inmensa mayoría hace.

Moyea PowerPoint to Video converter. An amazing, essential tool

Have you ever tried to add a simple logo at the beginning of a video, with just a fade-in, fade-out effect? What software would you use for such a task? Adobe Premiere? Combustion? May be, but for such a simple task, there is a much better (and cheaper) solution: Moyea ppt to video converter.

This small application takes a Power Point presentation and converts it into a video (avi, divx, xvid, dvd, and many others), in two simple steps, keeping all the ppt animations, videos inside, etc. I have tried it today and have worked flawlessly with a Power Point 2007 (pptx) presentation.

I find it specially useful for (among many other things): easy credits making, logo animations, fast video joining, etc. It´s also very useful the “Save as VOB” feature, allowing you to create DVDs with no need for additional authoring software. You can try the TRIAL version (adds a watermark to the video) and buy it if you like it (it´s less than 50 US$).

I love this kind of tiny, but extremely useful applications, which cost a few money but can save you a lot of time.

Cheers!

Cómo desactivar el molesto lector de SMS en modo conversación en tu Samsung Omnia

Desde que lo compré, estoy bastante contento con mi Samsung Omnia, aunque siempre me molestó algo que traía configurado de serie: el lector de SMS en modo conversación.

Lo que hace este modo es guardar relaciones entre SMS, de forma que el teléfono identifica (más o menos) conversaciones enteras. Así, cuando abres un SMS, no solo muestra éste, sino que muestra también los anteriores y sus posibles respuestas.

La idea no es mala, pero lo cierto es que en cuanto tu número de SMS crece un poquito, la cosa se ralentiza mucho. Y si ya de por sí el Omnia (o su relación con Windows Mobile) es lento (no entiendo cómo puede serlo con semejante pepino de procesador), con este modo abrir un SMS podía llegar a costar unos interminables 2 o 3 segundos. No obstante, he de reconocer que hasta ahora nunca había borrado mis SMS, y ya acumulaba más de 800 (entre enviados y recibidos).

En fin, a lo que vamos: cómo desactivar este modo, y leer los mensajes como toda la vida.

Aunque he encontrado más de un método (algunos de ellos editando el registro), parece ser que con algunos de ellos aparece algún efecto colateral, como la pérdida del aviso sonoro en la recepción de un SMS. Así que de entre los métodos encontrados, me he quedado con el siguiente (a mi me ha funcionado a la perfección).

1. Descárgate la aplicación: SK Tools. Aunque es un magnífico producto que te recomiendo compres para mantener al día tu móvil, con la versión TRIAL te bastará para lo que vamos a hacer hoy. En esta página tienes los links de descarga. Escoge la opción para WM5 o WM6, en el formato que prefieras (Zip o CAB).
2. Instálala en tu Omnia (te recomiendo resolución VGA) y lanzala
3. Ve a la sección “Tune Up” en el menú principal
4. Una vez allí, navega con las pestañas de la parte inferior, moviéndote hacia la derecha hasta que encuentres la opción llamada: PIM
5. De entre todas las opciones, en la parte baja encontrarás una llamada: “Disable threaded conversation view (SMS)”
6. Pulsa sobre ella para cambiar su valor (en la parte superior aparecerá un combo de selección). Pon el valor YES.
7. Resetea tu Omnia

Et voilá, threaded conversation is off.

MysticThumbs, a good thumbnail generator for your explorer

Are you (like me) one of those that extensively use pictures and textures, in several formats? Then you are interested in this product…

I used to have installed the nVidia DDS Thumbnail viewer to be able to see thumbnails of my DDS textures in the explorer. Also used to have another application for TGA files, etc. Apart from the fact that I was still missing some formats, like Photoshop PSD, one day, without notice, my TGA and DDS viewers starting to collide. I could only make one of them working.

Struggling with that problem, I found the MysticThumbs viewer: an application that combines viewing of all the usual formats, including PSD. In addition to that, it has versions for both x86 and x64, something not too frequent in this kind of viewers.

I have tried it for a couple of days, and seems to work pretty well. I´d suggest you to give it a try.

Link:

http://mysticcoder.net/mysticthumbs/

Cheers!

.Net Compilation, registry accessing and application deployment for both x86 and x64 environments

What a long title, isn’t it?
That’s because, in some cases, there are a bunch of things related to make your .Net applications ready to work in both x86 and x64 environments. Specially if you need to use some unmanaged code or access the registry.
Let´s start!

Compiling and running assemblies

Native code (C++, etc) is compiled into platform-specify binary. That´s why you need to specify the target platform to be x86 or x64…
In .Net, things are a bit different. As you probably know, your VB or C# code will not be compiled into binary, but into MSIL. It´s the JIT Compiler (Just-in-time) who translates this intermediate code into binary, at load time. During this process, it can decide to compile it into 32 bits code or into 64 bits code, to adapt it to the underlying O.S., basing on it’s bitness.
That´s the reason why, in .Net, you can choose not to specify the target platform of your assembly, by choosing the option “Any CPU”. The following picture is a snapshot of VisualStudio project’s properties page, where you select the target platform.

Then, why would I want to specify a target platform? Isn’t “Any CPU” the best option always?
Most of the times, yes, as developers usually build pure .Net applications, with no dependency on unmanaged code and no further optimizations, so “Any CPU” would be the best option, letting the JIT compiler decide.
But in there are some situations where you will want to specify the target platform. Some examples:

• If you use any unmanaged code (which is platform-specific). You will have be careful with this, as your application could fail to load if the JIT compiler decides to put it into a mode not compatible with your unmanaged assemblies.
• If you want to optimize your assembly for an specific platform. For instance, if you need an application to access huge amounts of RAM memory, you will probably want to make it 64 bits only.

Also, there are other issues related to the target platform that you should be aware of, like registry accessing. We will talk about this later.
This blog post explains target platforms a bit further.

Platforms compatibility

• If my assembly is compiled as Any CPU:
  • Will it run in a x86 environment –> Yes (JIT compiles it into x86 binary)
  • Will it run in a x64 environment –> Yes (JIT compiles it into x64 binary)
• If my assembly is compiled as x64 only:
  • Will it run in a x86 environment –> No
  • Will it run in a x64 environment –> Yes
• If my assembly is compiled as x86 only:
  • Will it run in a x86 environment –> Yes
  • Will it run in a x64 environment –> Yes (In WOW64 Mode)

WOW64 Mode

As backwards compatibility is good for selling licenses, Windows 64 bits offer a compatibility mode for 32bit applications. It´s the so called WOW Mode (Windows on Windows).
Have you played videogames on your PC with a machine emulator, like MAME or a Spectrum emulator? Well, this is something similar. WOW64 is a 32bit emulator that runs on 64bits machines, allowing 32bit applications to run in such environments.
Although we will talk about some issues regarding WOW64 later, you can find more details about WOW mode here.

Detecting the bitness of a “Any CPU” process

What happens if you compiled your assembly to “Any CPU”?
If you know that it will always run in a (modern) x86 environment, you have no doubt about this. Your process is 32 bits.
But what´s its bitness if it can run in both x86 and x64 environments? Even further, if it´s in a x64 O.S., what bitness mode will the JIT compiler decide for it? Normally x64, but… better make sure. How to do this? Extremely easy:

                if (IntPtr.Size == 4)

                    return eArchitecture.x86;

                else if (IntPtr.Size == 8)

                    return eArchitecture.x64;

System.IntPtr is designed to hold a memory address, right? And in .Net, it has a very convenient property that tells us its size. So, if this size is 8 bytes, then we have 64 bits addresses, if it´s 4 bytes, we are in a 32 bits environment. Easy as that.

Please note: If your assembly was compiled as x86, its bitness will always be 32 bits, as even when running in 64-bit environments, it will do in WOW64 mode (emulated 32 bits), and its bitness will remain 32.

Windows 64-bit infrastructure

As mentioned above, Windows 64 bits offers the WOW64 mode, to allow running x86 applications.
Microsoft engineers decided not to mix up 32bits and 64bits applications inside your hard disk, so x64 applications are installed by default in the “Program Files” folder, as usual, and x86 applications are by default installed in a new “Program Files (x86)” folder.

The Windows x64 registry

In Windows x64, WOW64 mode offers separate logical view of the registry for 32-bit and 64-bit applications. It´s like if they were accessing to two separate registries. This is something important to take into account when developing for x64 and when deploying applications, as x86-targeted Setup Projects will also access differently to the registry.
Basically, this works in the following way: Windows intercepts registry calls made by assemblies and applications, and redirects them to the appropriate logical view of the registry, being this completely transparent to the application. More info about registry redirection here.
Although this naming convention is not 100% correct, we will call this two separate logical views as “the 32-bit registry” and “the 64-bit registry”.

Application deployment with Visual Studio setup projects

If you, like many other people, use Visual Studio setup projects and Windows Installer to deploy your applications, there are several things that you need to take care of, if your software needs to be both x86 and x64 compatible.

Target platform in VisualStudio Setup Projects

Just like normal assemblies, setup projects also have a target platform property. You can see it in the properties tab, when you select your project in the solution explorer.

Unfortunately, we don´t have the “Any CPU” option here, so we will have to choose the platform manually. This platform selection affects the following aspects (among others):

• The default installation folder for your application: “Program Files”, or “Program Files (x86)”
• If the setup project modifies the registry, it will affect the so-called-by-us “64-bit registry”, or the redirected “32-bits registry” for WOW64 processes. This is something important to keep in mind if you are using registry keys in your setup project.

So, which platform should I choose for the Setup Project?

It depends on how well your application is prepared for x64, and on how it is compiled:

• If your application is compiled as x86: choose x86
• If your application is compiled as x64: choose x64
• If your application is compiled as “Any CPU”:
  • If you know it is prepared to be run as x64 (i.e. registry accessing code is aware of WOW64 mode): choose x64
  • If you cannot assure that your application will deal fine with x64 infrastructure: choose x86

Dude, where are my registry keys?

As mentioned above, if your Setup Project is compiled as x86, it won´t modify the “64-bit registry”, but the 32-bit, redirected version, provided by the WOW64 mode. So, if you open regedit.exe normally (which shows you the “64-bit” version of the registry), you won´t find anything.
Instead, you need to open the special version of RegEdit which shows you the “32-bit registry”, using:

[Windows Installation path]\SysWOW64\regedit.exe

Please note: Windows Installation Path is normally “C:\Windows”.

Accessing the registry from C#

Now that you understand how Windows x64 infrastructure is designed, and how your applications will be installed by Setup Projects, you will probably need to learn how to deal with both versions of the Windows x64 Registry. Specially if your application will be compiled as x86, and therefore run in WOW64 mode.

The usual, .Net way to access the registry

Imagine you want to read a certain key inside the “LOCAL_MACHINE\Software” node of the registry. In .Net, you normally do that by using a code similar to the following (using namespace: Microsoft.Win32):

RegistryKey key = Registry.LocalMachine.OpenSubKey("Software\\[Your Key Here]");

 

Doing so in a Windows x64 machine will only access the “64-bit” version of the registry, even if your process is running in WOW64 mode. So, if our application was installed with a x86 Setup Project, the keys we are looking for won´t be there. We need to access the “32-bit registry” instead, provided by the WOW64.

Accessing the 32-bit, WOW64 registry from C#

Unfortunately (and by now) there is no way in .Net to specify that we wont to access the “32-bit”, WOW64, version of the registry. To do so, we will have to deal with native API calls, dll-importing “advapi32.dll” and using the RegOpenKeyEx.
This function has a parameter called samDesired, which can be a combination of flags specifying access options for the key. One of those possible options, is specifying we want to open the WOW64 view of the registry.

Table of flags for samDesired

Value	Meaning
KEY_ALL_ACCESS (0xF003F)	Combines the STANDARD_RIGHTS_REQUIRED, KEY_QUERY_VALUE, KEY_SET_VALUE, KEY_CREATE_SUB_KEY, KEY_ENUMERATE_SUB_KEYS, KEY_NOTIFY, and KEY_CREATE_LINK access rights.
KEY_CREATE_LINK (0x0020)	Reserved for system use.
KEY_CREATE_SUB_KEY (0x0004)	Required to create a subkey of a registry key.
KEY_ENUMERATE_SUB_KEYS (0x0008)	Required to enumerate the subkeys of a registry key.
KEY_EXECUTE (0x20019)	Equivalent to KEY_READ.
KEY_NOTIFY (0x0010)	Required to request change notifications for a registry key or for subkeys of a registry key.
KEY_QUERY_VALUE (0x0001)	Required to query the values of a registry key.
KEY_READ (0x20019)	Combines the STANDARD_RIGHTS_READ, KEY_QUERY_VALUE, KEY_ENUMERATE_SUB_KEYS, and KEY_NOTIFY values.
KEY_SET_VALUE (0x0002)	Required to create, delete, or set a registry value.
KEY_WOW64_32KEY (0x0200)	Indicates that an application on 64-bit Windows should operate on the 32-bit registry view. For more information, see Accessing an Alternate Registry View. This flag must be combined using the OR operator with the other flags in this table that either query or access registry values. Windows 2000: This flag is not supported.
KEY_WOW64_64KEY (0x0100)	Indicates that an application on 64-bit Windows should operate on the 64-bit registry view. For more information, see Accessing an Alternate Registry View. This flag must be combined using the OR operator with the other flags in this table that either query or access registry values. Windows 2000: This flag is not supported.
KEY_WRITE (0x20006)	Combines the STANDARD_RIGHTS_WRITE, KEY_SET_VALUE, and KEY_CREATE_SUB_KEY access rights.

The code

The next code is a personal translation to C# of several pieces of code I found, mostly from here:

[DllImport("advapi32.dll", CharSet = CharSet.Unicode, EntryPoint = "RegOpenKeyEx")]

static extern int RegOpenKeyEx(IntPtr hKey, string subKey, uint options, int sam, out IntPtr phkResult);

 

[Flags]

public enum eRegWow64Options : int

{

    None =              0x0000,

    KEY_WOW64_64KEY =   0x0100,

    KEY_WOW64_32KEY =   0x0200,

    // Add here any others needed, from the table of the previous chapter

}

 

[Flags]

public enum eRegistryRights : int

{

    ReadKey =  131097,

    WriteKey = 131078,

}

 

public static RegistryKey OpenSubKey(RegistryKey pParentKey, string pSubKeyName, bool pWriteable,

                                     eRegWow64Options pOptions)

{

    if (pParentKey == null || GetRegistryKeyHandle(pParentKey).Equals(System.IntPtr.Zero))

        throw new System.Exception("OpenSubKey: Parent key is not open");

 

    eRegistryRights Rights = eRegistryRights.ReadKey;

    if (pWriteable)

        Rights = eRegistryRights.WriteKey;

 

    System.IntPtr SubKeyHandle;

    System.Int32 Result = RegOpenKeyEx(GetRegistryKeyHandle(pParentKey), pSubKeyName, 0,

                                      (int)Rights | (int)pOptions, out SubKeyHandle);

    if (Result != 0)

    {

        System.ComponentModel.Win32Exception W32ex = new System.ComponentModel.Win32Exception();

        throw new System.Exception("OpenSubKey: Exception encountered opening key", W32ex);

    }

 

    return PointerToRegistryKey(SubKeyHandle, pWriteable, false);

}

 

private static System.IntPtr GetRegistryKeyHandle(RegistryKey pRegisteryKey)

{

    Type Type = Type.GetType("Microsoft.Win32.RegistryKey");

    FieldInfo Info = Type.GetField("hkey", BindingFlags.NonPublic | BindingFlags.Instance);

 

    SafeHandle Handle = (SafeHandle)Info.GetValue(pRegisteryKey);

    IntPtr RealHandle = Handle.DangerousGetHandle();

 

    return Handle.DangerousGetHandle();

}

 

private static RegistryKey PointerToRegistryKey(IntPtr hKey, bool pWritable, bool pOwnsHandle)

{

    // Create a SafeHandles.SafeRegistryHandle from this pointer - this is a private class

    BindingFlags privateConstructors = BindingFlags.Instance | BindingFlags.NonPublic;

    Type safeRegistryHandleType = typeof(SafeHandleZeroOrMinusOneIsInvalid).Assembly.GetType(

                                             "Microsoft.Win32.SafeHandles.SafeRegistryHandle");

 

    Type[] safeRegistryHandleConstructorTypes = new Type[] { typeof(System.IntPtr), typeof(System.Boolean) };

    ConstructorInfo safeRegistryHandleConstructor = safeRegistryHandleType.GetConstructor(privateConstructors,

                                                               null, safeRegistryHandleConstructorTypes, null);

    Object safeHandle = safeRegistryHandleConstructor.Invoke(new Object[] { hKey, pOwnsHandle });

 

    // Create a new Registry key using the private constructor using the safeHandle - this should then behave like

    // a .NET natively opened handle and disposed of correctly

    Type registryKeyType = typeof(Microsoft.Win32.RegistryKey);

    Type[] registryKeyConstructorTypes = new Type[] { safeRegistryHandleType, typeof(Boolean) };

    ConstructorInfo registryKeyConstructor = registryKeyType.GetConstructor(privateConstructors, null,

                                                                    registryKeyConstructorTypes, null);

    RegistryKey result = (RegistryKey)registryKeyConstructor.Invoke(new Object[] { safeHandle, pWritable });

    return result;

}

How to use the code

The OpenSubKey will return the searched key, allowing you to specify reading from the normal registry, or from the alternative 32-bit, WOW64 registry. The following example reads from the 32-bit WOW64 registry:

try

{

    RegistryKey key = OpenSubKey(Registry.LocalMachine,"Software\\[Key]",false,eRegWow64Options.KEY_WOW64_32KEY);

}

catch

{

    // Parent key not open, exception found at opening (probably related to security permissions requested)

}

You just need to place your key name where “[Key]” is.

How to make your application a bulletproof registry reader

Now that your have a way to read both versions of the registry in x64 environments, I´d suggest you to proceed the following way:

1. Try to find your key in the usual, standard, .Net way, using the build-in “Registry.LocalMachine.OpenSubKey”. This case will cover your application running in a 32-bit Windows, or running in a 64-bit Windows, but not in WOW64 mode.
2. If key not found, proceeding in one of the following paths:
1. Check Windows version
1. 32 bits: Exception, key not found
2. 64 bits: Try to find the key in the WOW64 registry with the above code, and launch exception if not found.
2. Try to read the WOW64 registry directly, enclosing your code in try-catch statement, if any exception is caught, or if key not found, launch exception

In a next article, I´ll talk about detecting which version of Windows your software is running in, and many other things.
Stay tuned!