Windows Server 2008 64位的7-Zip执行权限

我已经创建了一个自解压缩的7-Zip文件。其中包含一个CMD文件，其中7-Zip在解压缩文件上运行。此cmd读取注册表并执行一些进一步的活动（对此特定问题不重要）。Windows Server 2008 64位的7-Zip执行权限

在Windows Server 2003 32位中，此行为工作得很好。但是，在Windows Server 2008框中进行测试表明，由7-Zip启动的cmd无权读取注册表。更具体地说，它可以读取一些区域（Windows当前版本），而不是其他（其他软件密钥）。

如果我把这个cmd文件自己运行（从7-Zip提取它的临时文件夹运行它），一切运行良好。

使用UAC“以管理员身份运行”会产生相同的问题，禁用UAC似乎没有帮助。

我不知道配置文件的任何7-Zip选项，它告诉它升级权限，或类似的东西。有什么我在这里失踪？在Windows Server 2008或64位版本的操作系统中，注册表访问是否更加锁定？我如何确保我的EXE文件可以将正确的权限传递给它所启动的命令？

来源

2011-12-07 Minus Ex

你有使用'<运行特权/>'安装XML文件中的元素？ [http://izpack.org/documentation/installation-files.htm](http://izpack.org/documentation/installation-files.html） –

由于7-Zip文件是32位可执行文件，因此您的命令脚本在32位上下文中运行。其中一个后果是某些注册表位置被重定向。有关更多详细信息，请参见MSDN。

您可以通过寻找一个环境变量，PROCESSOR_ARCHITEW6432检测WOW64的环境，你可以通过运行在c:\windows\sysnative发现cmd.exe副本返回原生64位环境。

这两条线在您的命令文件的顶部应该做的伎俩：

if defined PROCESSOR_ARCHITEW6432 c:\windows\sysnative\cmd.exe /c %~pf0 %* 
if defined PROCESSOR_ARCHITEW6432 goto :eof

来源

2011-12-07 21:42:21

你先生是个巫师！我从未偶然发现过这个答案，非常感谢！ –

嘿哈利，我发现在win2k3 64位这个伎俩不起作用。是的，我已经看到sysnative不存在那里，我需要交换到system32 \ cmd.exe，但是当我的脚本重新运行时，它仍然检测到PROCESSOR_ARCHITEW6432。当我运行system32 \ cmd.exe时，我自己的工作，但这里的交换似乎失败。任何想法是什么？ –

不，这不起作用，这仍然是32位版本。我现在唯一能想到的解决方案是编写一个64位应用程序来为您重新启动命令文件，并将其包含在程序包中。如果您将此作为新问题发布（“32位cmd.exe如何在Windows 2003 x64中启动64位cmd.exe？”），有人可能会想到一个更明智的答案。 –

Windows Server 2008 64位的7-Zip执行权限

回答

相关问题