Kinook Software Forums

Kinook Software Forums (
-   [VBP] General Discussion (
-   -   Read registry (

HippyCraig 02-19-2013 07:34 PM

Read registry
I am seeing some weird behavior reading the registry on one server, other servers seem fine but this one is strange

I am trying to find if a software package is installed and I am searching in
SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstal l\

But the values returned are not from this location but from
SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVers ion\Uninstall

Why is the Wow6432Node being returned and I am not asking for it. The build machine is 2003 x86 server the server I am calling is 2008 R2 x64. Now this works fine on other 2008 R2 x64 servers but for some reason this one is not returning the right node.

I am using the 32 version of VB8 see below
Visual Build Professional 8.1
Registered to: ACE USA - Southbury, CT (1-site license)
Windows Version: 5.2.3790.2.0
Install path: C:\Program Files\VisBuildPro8
HideConsole.exe version
SftPrintPreview_IX86_U_20.dll version 2.04
VisBuildCmd.exe version
VisBuildPro.exe version
VisBuildAct.dll version
VisBuildCore.dll version
VisBuildDotNET.dll version
VisBuildExt.dll version
VisBuildMisc.dll version
VisBuildMS.dll version
VisBuildMS2.dll version
VisBuildNet.dll version
VisBuildSvr.dll version
VisBuildSvr.Interop.dll version
VisBuildVCS.dll version

kinook 02-20-2013 07:14 AM

I'm not sure. I'm guessing there's some Windows configuration setting different on that particular machine?

This articles indicates that with 2003 SP1 and later, the 64-bit view will be always accessed, unless the KEY_WOW64_32KEY flag is used (not possible from 32-bit Visual Build):

Although it's not entirely clear if the Windows 2003 behavior is for 2003 and later or just Win2003. So it could mean that for a Win 2008 remote machine, the first statement applies (If the client is a 32-bit application, it accesses the 32-bit registry view. If the client is a 64-bit application, it accesses the 64-bit registry view).

One thing you might try would be updating the client to 2003 SP1, since the behavior changed with that version (but this wouldn't explain why it works on all remote 2008 boxes except one).

Another option might be to use 64-bit Windows + 64-bit Visual Build on the client.

HippyCraig 02-20-2013 08:46 AM

Sorry my build machine is at SP2, is there something else I can look at?

HippyCraig 02-20-2013 09:00 AM

I just compared one of my other 2008 server that works, the strange is that it must be looking int he same place under SOFTWARE\Wow6432Node\Microsoft\Windows.

The only difference here is that for some reason our msi are installing and storing there uninstall information to the SOFTWARE\Wow6432Node\Microsoft\Windows on the good server but the server that is an issue the MSI is installing and storing the uninstall information under the SOFTWARE\Microsoft\Windows.

Is there reason that an MSI would store its uninstall information in one place or the other?

kinook 02-20-2013 09:33 AM

I believe that an MSI package can be either 32- or 64-bit, and the package type determines the registry view that is used.

Another option might be to use VBScript/WMI:

HippyCraig 02-20-2013 10:43 AM

In the mean time is there a way in the Read Registry action to be specific on where to look for the registry, this way I can check both location for the installer to see if it exists.

kinook 02-20-2013 12:58 PM

See the 64-bit/32-bit registry view options for the action.

From the document previously mentioned, it's unclear what the Windows registry API implementation does for 32-bit clients accessing a remote 64-bit computer. The behavior you're describing is consistent with the first statement at (If the client is a 32-bit application, it accesses the 32-bit registry view). You might try checking the Access 64-bit registry view if not already checked. Otherwise, you may need to use the 64-bit version of Visual Build on 64-bit Windows client to access a remote 64-bit registry view.

HippyCraig 02-20-2013 01:11 PM

The option to select Access 64-bit registry view is grayed out. Is there a reason I cant access this checkbox?

kinook 02-20-2013 01:18 PM

Oh yeah -- that option is disabled on x86 Windows, since it is meaningless for local registry access, and we didn't anticipate the possibility of accessing a remote 64-bit registry view from 32-bit Windows. We'll see about testing and enabling that scenario. For now, you may need to use VBScript/WMI to access a remote 64-bit registry view from Visual Build on 32-bit Windows.

kinook 02-24-2013 03:49 PM

Download, extract and copy the files in to the System folder within your 32-bit Visual Build install path to enable and use the 64-bit option for remote registry access.

HippyCraig 02-25-2013 02:25 PM

Cool I will try it but I have to create a VM in order to test this out, we have 150 apps prepared for the current build server and I dont want to interupt that process.

I will keep you posted on my testing, again thanks for helping with this!

HippyCraig 02-27-2013 09:10 AM

This works Great!!!!! I was able to recreate the issue in some VM's and its working now.

I was reading more into the help file and I was wondering, if I have a x64 build machine, running either 32 or 64 Visual Build will I be able to access either the 32 bit or 64 hive on a remote 64 bit machine? I assume that if I access a 32 bit machine it should just work.

Another thought, if there was a way on the "Step Starting Event" to set some macro's to determine what hive it access that might be helpful as well.

As always I am so impressed with the level of support you provide!

kinook 02-27-2013 10:43 AM

You can access the 32- and 64-bit registry views from the 32- and 64-bit editions of Visual Build. By default, the 32-bit edition accesses the 32-bit registry view, but can access the 64-bit view on 64-bit Windows by checking the Access 64-bit registry view option. And the 64-bit edition accesses the 64-bit view by default, but it can access the 32-bit view by checking the Access 32-bit registry view option.

By "a way on the "Step Starting Event" to set some macro's to determine what hive it access," if you mean that you want to dynamically check the 32-/64-bit options based on a macro, you can use a field override to do that.

HippyCraig 02-27-2013 01:21 PM

Assigning a Macro to a checkbox is exactly what I was looking for, thanks, that's perfect.

Will the new DLL's you provided be put into the main application moving forward? Or will I need to keep these for future releases?

kinook 02-27-2013 03:23 PM

This has been incorporated into the latest build (v8.3).

All times are GMT -5. The time now is 02:37 PM.

Copyright 1999-2019 Kinook Software, Inc.