Registry update in WoW64 mode failsSolved

If that checkbox is checked the updater fails at the registry backup and changes step and a rollback is done.

Can you give me the full error? What systems is it failing on (Windows XP, x64/x86, etc.)? What's the exact registry change that fails?

Unchecked it works fine except that on 64bit systems the wrong registry tree is updated (as expected).

Why do you want to use the WoW64 emulated registry for a value that's used by the system? That is, Windows reads these values when the checkbox is unchecked (whether you're updating an x86 or x64 version of Windows).

Did some more testing and run wyUpdate.exe manually to get the error message on my Windows 7/64bit test system. The 3rd step fails (red cross) and the finish form says: 'Object reference not set to an instance of an object' which is a NullReferenceException.

I have a 32bit application so I need to use the 32bit part of the registry on a 64bit system. It should be also possible to use the 64bit subtree of the registry for all the application information which is being displayed in the control panel/uninstall software overview. But as the 32bit/64bit handling in the NSIS installer is some kind of cumbersome this is the easier way.

My wyUpdate - registry settings you can find here:http://dl.dropbox.com/u/395716/wyBuild-config-registry.png

Yves

I'll try to reproduce this. What version of wyUpdate are you using?

I'm using version 2.6.7.

Update to the latest wyBuild and use wyUpdate.exe 2.6.8 and tell me the error you get.

Okay, a different error message: Failed to get the 'SafeHandle' contructor. Make sure wyUpdate.exe has full trust Code Access Security (CAS).

I've just tested this on my machine (Windows 7, x64) and it works fine. I've seen this error pop-up in a few cases for other users. This is a problem with your computer configuration. I have a few questions:

1. Did this work before, and just recently start failing?
2. Did you change the CAS settings?
3. What security software are you using (Anti-virus, "cleaners", firewalls, etc.)
4. Where did you get your computer? (Second hand, Dell, Gateway, custom built, etc.)

I went through your code where the exception happens. The problem is that you try to get a non-public constructor via reflection which in fact is public (RegChange.32bit.cs, line 252). After changing the BindingFlags to Public everything works fine. I don't understand why you construct Microsoft.Win32.SafeHandles.SafeRegistryHandle via reflection as it's completely public:

http://msdn.microsoft.com/en-us/library/microsoft.win32.safehandles.saferegistryhandle.aspx

Only the constructor you are using for RegistryKey is private.

And similar issue for the RegistryKey construction (line 255). There is no private constructor with 2 arguments only:

typeof (RegistryKey).GetConstructors(BindingFlags.Instance | BindingFlags.NonPublic)

debugger returns

{Void .ctor(Microsoft.Win32.SafeHandles.SafeRegistryHandle, Boolean, Boolean, Boolean, Boolean, Microsoft.Win32.RegistryView)}

and

{Void .ctor(Microsoft.Win32.SafeHandles.SafeRegistryHandle, Boolean, Microsoft.Win32.RegistryView)}

I don't understand why you construct Microsoft.Win32.SafeHandles.SafeRegistryHandle via reflection as it's completely public

You're reading the .NET 4.0 docs. For .NET 2.0-3.5 it's private. You're actually exposing a bug in the .NET 4.0 version of wyUpdate. We have a fix coming for wyUpdate 2.6.10 that uses .NET 4's ability to access the WoW64 registry without using reflection.

Thanks for reporting this.

When do you expect 2.6.10? Or, when do you commit the fix to code.google.com? Thanks for your fast replies. Yves

If you need it right away, use revision 212. Wyatt just made the change. This isn't the "final" 2.6.10, we have more changes coming, but it has the registry fixes.

Thanks Sam and Wyatt 🙂 Just saw it. What about the second reflection? RegistryKeyConstructor is always null as there is no 2-arguments constructor which leads to a NRE later. The .NET source seems to be wrong at his point?! See my previous post to see what the debugger says.

The fix would be:

line 254: Type[] registryKeyConstructorTypes = new[] { safeRegistryHandleType, typeof(Boolean), typeof(RegistryView) };

and

line 265: return (RegistryKey)RegistryKeyConstructor.Invoke(new[] { safeHandle, pWritable, RegistryView.Registry32 });

No, the .NET 4.0 version of wyUpdate doesn't use any of the code in RegChange32bit.cs. It uses the built-in WoW64 support. RegChange32bit.cs is only for .NET 2.0 - .NET 3.5

However, you won't be able to use the "supportedRuntime" hack you mentioned a few months ago.

Okay, I didn't see the #if NET4 in RegChange.Execution.cs. But, I run the updater in a 4.0 Client Profile environment and got this error message coming from RegChange.32bit.cs. And my wyUpdate project settings are .NET 4.0. There is no supportedRuntime config element anymore. Targeting 4.0 now. Is this related to r212?

No, r211 through r213 fix typos. The .NET 4.0 registry bug was fixed in r209.

wyatt reverted the change. r212 seems to definitely fix the issue as the .NET4 symbol was not defined and the RegChange.32bit.cs code was executed in my .NET 4 env. Thanks.

Sorry, got confused. It's already late here in Switzerland 😉 Went through the commits now and saw that the distinction '#if NET4' was not there before. It's bound to work this way. Will do some tests tomorrow. Thanks to both of you for your great support! Very much appreciated.

Your welcome.

We've released wyBuild 2.6.10. The fixed wyUpdate 2.6.10 is included. Thanks for reporting this.