Question

I've created a self-extracting 7-Zip file. There is one CMD file contained in it which 7-Zip runs on extract. This cmd reads the registry and performs some further activities (unimportant to this specific question).

In Windows Server 2003 32-bit this behavior works just fine. However, testing on a Windows Server 2008 box shows that the cmd kicked off by 7-Zip doesn't have permissions to read the registry. More specifically it can read some areas (Windows current version), but not others (other software keys).

If I take that cmd file and run it myself (running it from the temporary folder that 7-Zip extracts it to) everything runs fine.

Using UAC "Run as Administrator" produces the same issue, and disabling UAC doesn't seem to help.

I'm not aware of any 7-Zip options for the configuration file that tells it to escalate privileges, or anything like that. Is there something I'm missing here? Has registry access gotten more locked down in Windows Server 2008, or on a 64 bit version of the OS? How can I ensure that my EXE file can pass the right permissions to the command it kicks off?

Was it helpful?

Solution

Because the 7-Zip file is a 32-bit executable, your command script is running in a 32-bit context. One of the consequences is that certain registry locations are redirected. See MSDN for more details.

You can detect a WOW64 environment by looking for an environment variable, PROCESSOR_ARCHITEW6432 and you can return to the native 64-bit environment by running the copy of cmd.exe found in c:\windows\sysnative.

These two lines at the top of your command file should do the trick:

if defined PROCESSOR_ARCHITEW6432 c:\windows\sysnative\cmd.exe /c %~pf0 %*
if defined PROCESSOR_ARCHITEW6432 goto :eof
Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top