By troubleshooting the situation from the command line, Tod was able to narrow the problem down to a problem when reading from the registry. Specifically:
regedit /e F:\test1.reg “HKEY_LOCAL_MACHINE\Software\
Broadcom\ BACS” run outside AlwaysUp produces a file containing the registry export.
regedit /e F:\test2.reg “HKEY_LOCAL_MACHINE\Software\
Broadcom\ BACS” run inside an AlwaysUp CMD session does not produce a file.
Both commands were run in the same user account, so why the different results?
The discrepancy is due to the different views of the registry presented to 32-bit and 64-bit applications.
Most modern versions of Windows are 64-bit. All the major applications and supporting DLLs distributed with the OS are 64-bit. To ensure that older 32-bit applications continue to run fine on these new operating systems, Microsoft engages in some “creative trickery”:
32-bit applications see a 32-bit version of the System32 Folder
Even though the Windows System32 folder (typically, C:\Windows\System32) is stocked with 64-bit applications, a 32-bit application has that folder “mapped” to a counterpart (C:\Windows\System32\Wow64) filled with 32-bit versions instead. So when a 32-bit application runs the “DIR” or “REGEDIT” commands, it is actually invoking the 32-bit version in the Wow64 folder. This silent mapping ensures compatibility when a 32-bit application invokes one of those standard Windows utilities.
AlwaysUp is a 32-bit application and is constrained by this behavior. When we’re troubleshooting, the command prompt is launching the 32-bit version of regedit.
64-bit applications work with a (slightly) different view of the Registry
In the 64-bit operating systems, some registry keys actually have a 32-bit version and a 64-bit version! One such key is HKLM\Software. 32-bit applications can write to this key normally, however the changes show up under HKLM\Software\Wow64 instead. A 64-bit application can see both versions of the keys and can choose which version to access.
Now Tod is using Windows Server 2012 R2 which is 64-bit. Our “a-ha” moment came when we noticed that this key exists:
but the corresponding 32-bit key does not:
WOW6432Node\ Broadcom\ BACS
This discrepancy means that 64-bit applications can access HKEY_LOCAL_MACHINE\Software\Broadcom\BACS while 32-bit applications cannot see a registry entry with that same name.
Tod was able to start the 64-bit version of regedit from AlwaysUp by exploiting another bit of Microsoft trickery — the Sysnative folder. This is the full path that enabled regedit to find the Broadcom key:
C:\Windows\Sysnative\regedit /e F:\test1.reg “HKEY_LOCAL_MACHINE\
Software\ Broadcom\ BACS”
Ultimately he was able to launch the 64-bit version of CSCRIPT from the same path and his application is now functioning as expected as a Windows Service!