• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2090
  • Last Modified:

Why Wow6432Node registry branch is not accessible?!

Hi.

We are using InstallShield 11 for our install packages.
Recently we have faced a problem - a script in the InstallShield  project is not able to access the [HKLM\Software\Wow6432Node\*] registry branch.

And the very strange thing - our external DLL which is also allow to read registry is not able to access that registry branch too! :-(

It looks like access is blocked in someway...

The question is - how to make [HKLM\Software\Wow6432Node\*] registry branch readable?
We are ok with 2 options:
1) use API in InstallShield 11
2) use external DLL (anyway we already using it as kind of "API-extender")

Please also see enclosed log file - it is a log generated by mentioned above DLL.
As you can see - it is reading common registry without any problems but fail to read only [HKLM\Software\Wow6432Node\*] registry branch.

And also - there is enclosed source code of InstallShield script function which is reading registry.


Regards,
Dmitry.

PS. InstallShield version is 11. Is not ok to upgrade to newer versions, need to use exactly this version!
But actually I'm ok with information if such issue is resolvable in newer IS versions.
InstUtil-api.log
is-func.txt
0
Dmitry_Bond
Asked:
Dmitry_Bond
  • 13
  • 12
1 Solution
 
ingriTCommented:
Might be a dumb question, but is your Windows an x64 installation?
0
 
Dmitry_BondAuthor Commented:
Yes. Of course is Windows 2008 R2 x64.
0
 
ingriTCommented:
Maybe something is wrong in your script, your logfile has these lines;

092540.150 [P5436|INFO] RegistryRead("{access:x64,x86}[HKLM\\SOFTWARE\IBM\DB2\CurrentVersion]\Version", boolPrt=0x04D1EF84)
092540.150 [P5436|INFO]  * RegistryRead: use adjusted access flags: 0x000F033F /diff=0x00000300
092540.150 [P5436|INFO]  * RegistryRead: path="[HKLM\\SOFTWARE\IBM\DB2\CurrentVersion]", name="Version"
092540.150 [P5436|INFO]  * RegistryRead: set RootKey (HKLM/#2) = 0x80000002
092540.150 [P5436|INFO]  * RegistryRead: Opening key( \SOFTWARE\IBM\DB2\CurrentVersion )...
092540.150 [P5436|INFO]  * RegistryRead: key is NotFound!, value is NotFound!. Value is ""

Open in new window


The first line reads; HKLM\\SOFTWARE\IBM\DB2\CurrentVersion]\Version key and the two last lines can't open and read the same key.
Is it because of the missing [HKLM\\ in that part?
0
Cloud Class® Course: CompTIA Healthcare IT Tech

This course will help prep you to earn the CompTIA Healthcare IT Technician certification showing that you have the knowledge and skills needed to succeed in installing, managing, and troubleshooting IT systems in medical and clinical settings.

 
Dmitry_BondAuthor Commented:
Please do not look for syntax errors. Because there are no such errors!

Please keep in mind - it perfectly works on 32-bit platforms. So, if I would create manually Wow6432Node registry branch on 32-bit Windows - it will work fine.

If you confused by a log file content here is explanations: the specified string "{access:xxx}[HKLM\\SOFTWARE\IBM\DB2\CurrentVersion]\Version" is parsed and split to 4 parts:

1) access flags = {access:xxx}
2) registry root key = HKLM
3) registry branch path = \SOFTWARE\IBM\DB2\CurrentVersion
4) registry item name to read = Version

Later in a log file you can see how it selects a RootKey (set RootKey (HKLM/#2) = 0x80000002), then - which registry path is finally opened (\SOFTWARE\IBM\DB2\CurrentVersion). Only missing a value name it is trying to read but that is not a problem - that part of code perfectly works, so I even not thought to log anything about it...
0
 
ingriTCommented:
I'm not looking for syntax errors, I only noticed that that the error you get on the Wow6432Node is the same error you get above there, but on a totally different node. So maybe the problem is not the specific Wow6432 node, but something else on a x64 system that will not let you read the registry like this.
0
 
Dmitry_BondAuthor Commented:
Ya. Sorry, then I did not understand your thought.

But anyway, you mistaken.
Please look on IS script enclosed, as you can see there - it is trying to open registry key using IS API, if fail - is trying to read the same key using external DLL API. Then switch registry key to Wow6432Node path and do the same - try IS API, try external DLL API.

On the test computer 1st 2 attempts expect to fail because it is 64bit DB2 on 64bis OS, so it registry key is located in a Wow6432Node "container".

But above - the 1st record in a log you can see the successful read of registry. So, the registry itself is readable but something wrong only with Wow6432Node.

The only question - what could be wrong with Wow6432Node registry branch?!

Just for a case - I have added a bit more logging. See a new log file enclosed.
InstUtil2.log
0
 
ingriTCommented:
I don't know of anything that could be different about the specific node. You are sure that the complete node path does exist on the server within the Wow6432Node key?

I haven't had any different problems with reading this specific node yet.
0
 
Dmitry_BondAuthor Commented:
Hm... I just looked into registry once again and found:

The [HKEY_LOCAL_MACHINE\SOFTWARE\IBM\DB2\CurrentVersion] key is exists!
The [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\IBM\DB2\CurrentVersion] key is not exists!

But there is [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\IBM\DB2] key with different structure.

I have tried to read [HKEY_LOCAL_MACHINE\SOFTWARE\IBM\DB2\CurrentVersion] but it fail by unknown reasons.

I see - there is another key on the same level - [HKEY_LOCAL_MACHINE\SOFTWARE\IBM\DB2\GLOBAL_PROFILE] which is readable, so I can read it without any problems.

So, it looks like that one particular key configured or created in a special way, so it is not readable. BUT WHY?!... :-\

Checked permissions for both keys in RegEdit - them are 100% identical... It is becaming mysterious... :-\
0
 
ingriTCommented:
Do both keys have values? And are the values of the same type? Maybe something is going wrong there...
0
 
Dmitry_BondAuthor Commented:
I just exported 3 keys to REG file. Only 1st one is not readable. Others - are ok. :-\
But why?! I do not see any reasons for that...
hklm-db2.reg
0
 
ingriTCommented:
I don't see anything different about these either. Maybe the software using these registry keys has some control over it?

Have you tried watching with Process Monitor (http://technet.microsoft.com/en-us/sysinternals/bb896645) to see if anything is blocked?
0
 
Dmitry_BondAuthor Commented:
I have tried to load mentioned DLL by a simple test application and run a simple tests accessing mentioned registry keys.

I see the same problem - that particular key ([HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\IBM\DB2\CurrentVersion]) is no readable. :-(

So, it seems it is not related to installer. It is common problem for the OS/platform.
But only cannot understand - why that may happens?
Could it map that key? Or could it mark key as "64-bit-app-accessible-only"?
0
 
ingriTCommented:
Try the process monitor i mentioned, to see if the key is blocked when you try to access it with your test application.
0
 
Dmitry_BondAuthor Commented:
Ok...
I made tests.
install-Logfile-2.xlsx
0
 
ingriTCommented:
So, does the name exist there? In the export you uploaded earlier, this key is not available.
0
 
Dmitry_BondAuthor Commented:
seems I screwed up my test env... need to uninstall Db2, install newer version and re-do tests. sorry.
0
 
Dmitry_BondAuthor Commented:
Ok... seems things became a bit clear. But still do not see a solution.

Please see on a row with time="17:00:12.1487455" - there is a piece from application log which is showing which registry key it was tried to access.

And the same for time="17:00:56.1743192" - there is a piece from application log file.
As you can see when my application (which is 32bit) is trying to access [HKLM\SOFTWARE\IBM\DB2\CurrentVersion] key the system redirects it to [HKLM\SOFTWARE\Wow6432Node\IBM\DB2\CurrentVersion]! :-(
win2008reg-access.xlsx
0
 
ingriTCommented:
Both logs on the row are clear; there is no such key.
0
 
Dmitry_BondAuthor Commented:
NO! From log you can clearly see that when my application is trying to read the [HKLM\SOFTWARE\IBM\DB2\CurrentVersion] the system redirects it to reading the [HKLM\SOFTWARE\Wow6432Node\IBM\DB2\CurrentVersion] which is not exists!

So, the question is - how to read exactly the registry key I need to read but not the key system redirected me to?!

Because the [HKLM\SOFTWARE\IBM\DB2\CurrentVersion] key - is exists.
But the [HKLM\SOFTWARE\Wow6432Node\IBM\DB2\CurrentVersion] - is not exists.
0
 
ingriTCommented:
Are you running 32bit software? There is no other reason to redirect you to the other key otherwise.
0
 
Dmitry_BondAuthor Commented:
Yes, of course. I already mentioned it - it is a 32bit application trying to read registry.
The registry key was created by 64bit application. But however I need to read that registry key.

Sorry, seems I did wrongly understand a problem (I mean - the original question description). I did think - system is blocking me to read the [HKLM\SOFTWARE\Wow6432Node\IBM\DB2\CurrentVersion] key but as now discovered it is redirecting me to that key in [HKLM\SOFTWARE\Wow6432Node\*] which is not exists!

But I need to read exactly the [HKLM\SOFTWARE\IBM\DB2\CurrentVersion] key.
0
 
ingriTCommented:
Wow, it took me almost a month to figure that out. It did not clearly read that you have a 32-bit application trying to read a 64-bit registry.

In what language are you coding? You need to use a flag when reading the registry, to point to the 64-bit registry. See this url; http://msdn.microsoft.com/en-us/library/windows/desktop/ms724072(v=vs.85).aspx.

I think you need to use the RegOpenKeyEx function instead of the RegDBGetKeyValueEx function to achieve this (see here as well http://msdn.microsoft.com/en-us/library/windows/desktop/ms724897(v=vs.85).aspx)
0
 
Dmitry_BondAuthor Commented:
Using Borland Delphi 5 and 7. There is a class TRegistry.
And as I see it now - I was close. :-) Only a problem - I specified both bit-flags at the same time - KEY_WOW64_64KEY and KEY_WOW64_32KEY and that is why it did not work.
After I changed access flags to only KEY_WOW64_64KEY is started to work fine...
0
 
ingriTCommented:
Does it still work now on 32-bit machines as well? This could be another problem.
0
 
Dmitry_BondAuthor Commented:
Just tested - is working fine on 32bit machines with KEY_WOW64_64KEY flag.
So, should not be any problems anymore. I think.

Thanks for idea with ProcMon - it was really helpful.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Get your problem seen by more experts

Be seen. Boost your question’s priority for more expert views and faster solutions

  • 13
  • 12
Tackle projects and never again get stuck behind a technical roadblock.
Join Now