Why RegOpenKey() returning error 2 on 64 bit Win7

Question

I've read this Question which appears to be duplicate of what I'm asking however I am actually asking WHY I'm seeing different Wow6432Node behavior on two different Win7 64 bit computers

My VB6 32 bit application is trying to read a registry entry at

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\SigToolESI.SigToolESIDevice2016 HideCaptureWindow = N

using the call RegOpenKey(). This registry key is put there by the applications 32 bit installer built with Wise InstallBuilder 8.12. On my 64 bit Win7 development system it works fine. On a client's 64 bit Win7 computer the app is getting an error 2 "Not Found". The client has also installed on a 32 bit computer running XP and it works fine there. I understand that what must be happening is the app is requesting to read from non-Wow6432Node and not finding the key there because the key is being redirected to Wow6432Node

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\SigToolESI.SigToolESIDevice2016 HideCaptureWindow =

Because when the client looks with Regedit at the non-Wow6432Node registry entry they find the expected key but they don't find it at the Wow6432Node location. What I don't understand is if both the application and the installer are 32 bit programs why didn't they both write and read from the Wow6432Node? And why is it behaving one way on my development computer and differently on the clients if we both ran the same installer and both have 64 bit Windows installed?

I've read this link but what I read doesn't seem to match up with what I am observing of redirection of 32 bit applications. From what I read in the link it seems like both the 32 bit installer and my 32 bit app should be reading and writing their registry entries to Wow6432Node. But what I'm observing is that on my 64 bit Win7 development system the installer writes to non-Wow6432Node and app reads from non-Wow6432Node (success) On client's 64 bit Win7 system the 32 bit installer writes to non-Wow6432Node but 32 bit application reads from Wow6432Node and fails.

Here is the view from Regedit of Classes in Wow6432Node and Non-Wow sections on my Win7 development system

SOFTWARE\Wow6432Node\Classes

SOFTWARE\Classes

Update 8-4-2017 I had the client manually create an entry for the key in Wow6432Node section with regedit to try and confirm that it is a Wow6432Node issue.

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\SigToolESI.SigToolESIDevice2016 HideCaptureWindow = N

The result was he got the same error. So perhaps my premise is somehow off that the clients system is trying to read the Wow3264Node section. What else could be causing error 2? It certainly seems suspicious that it fails on his 64 bit Win7 system but not on 32 bit XP.

Here is the VB code that is failing. Note that the error occurs when trying to open the SigToolESIDevice2016 key before even specifying the value name HideCaptureWindow. The SigToolESIDevice2016 key is created by registering the ActiveX VB component and not as I earlier stated when the installer adds HideCaptureWindow value:

Called with strPath="SOFTWARE\\Classes\\SigToolESI.SigToolESIDevice2016"
            strValue="HideCaptureWindow"

    Private Function RegKeyGetString(hBaseKey As Long, strPath As String, strValue As String)
        Dim hKey
        Dim status As Long

        'Open the key
        status = RegOpenKey(hBaseKey, strPath, hKey)

        If status <> 0 Then
            MsgBox ("RegOpenKey(" & hBaseKey & ", """ & strPath & """, """ & strValue _
            & """) = " & status)
            RegKeyGetString = ""
            Exit Function
        End If

        'Get the key's content
        RegKeyGetString = RegQueryStringValue(hKey, strValue)

        'Close the key
        RegCloseKey hKey
    End Function

Note that this is more complicated than you realize. On Windows 7 and later, the Classes key is shared, i.e., there are no separate 32-bit and 64-bit views. On earlier version it is [reflected](https://msdn.microsoft.com/en-us/library/windows/desktop/aa384235(v=vs.85).aspx). See also [Registry Keys Affected by WOW64](https://msdn.microsoft.com/en-us/library/windows/desktop/aa384253(v=vs.85).aspx). So your machine is behaving as expected, but the client's machine is not. — Harry Johnston, Aug 04 '17 at 02:01
Process Monitor, available from the MS web site, might be useful as a troubleshooting tool if you are able to reproduce the problem or to do troubleshooting on the client's machine. My first guess is that this has something to do with the fact that it is a VB6 application, e.g., Windows might have decided to apply some compatibility fix that is breaking things. (Or perhaps the compatibility fix is in place on your development machine and is the only reason it works at all.) — Harry Johnston, Aug 04 '17 at 02:10
Try using RegQueryReflectionKey() to determine if there is a difference in reflection on the two different machines. — thx1138v2, Aug 04 '17 at 11:13
Unfortunately I don't have easy access to the client's Win7 system. Looking at my Win7 development system I see that there are about 20 entries under HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\ and about 10,000 entries in LOCAL_MACHINE\SOFTWARE\Classes\. And my specific class SigToolESIDevice2016 is not in the Wow6432Node\Classes. If Classes key is shared why am I seeing SOFTWARE\Wow6432Node\Classes with a different list of Classes than SOFTWARE\Classes? See screen captures of WOW and non-WOW views from Regedit added to original question– JonN — JonN, Aug 04 '17 at 17:22
See also [registry virtualization](https://msdn.microsoft.com/en-us/library/windows/desktop/aa965884(v=vs.85).aspx). I don't think that can be your problem, but it may be worth knowing. My best guess as to why some keys exist in Wow6432Node\Classes is backwards compatibility, e.g., perhaps there is some program or software library originally written for Windows Vista that reads those particular entries directly from Wow6432Node and breaks if they're not found. — Harry Johnston, Aug 04 '17 at 21:01
It might be worth checking to see whether you can open the key using `HKEY_CLASSES_ROOT\SigToolESI.SigToolESIDevice2016`. It shouldn't make any difference, though, so it's a long shot. — Harry Johnston, Aug 04 '17 at 21:06

score 2 · Accepted Answer · answered Sep 14 '17 at 00:04

It turns out this was not related to WOW64 at all but was caused by the particular client not having write access to the registry key and the code requesting "Full Access" when trying to read the key. The non-extended RegOpenKey() assumes full access instead of READ_ONLY Here was the code change.

-    'Open the key
-10  status = RegOpenKey(hBaseKey, strPath, hKey)

+    ' Open the key for READ ONLY accesss Some clients were getting
+    ' access error on this call when RegOpenKey() was used which
+    ' requests full access instead of RegOpenKeyEx() with READ ONLY
+    ' access.
+10  status = RegOpenKeyEx(hBaseKey, strPath, 0, KEY_READ, hKey)

Why RegOpenKey() returning error 2 on 64 bit Win7

1 Answers1