作为另一个用户通过 Jenkins 运行构建时出现 SignTool 错误
我有一个 MSBuild，它通过 Jenkins 运行，并在其中一个组件中包含签名代码。
当我以最初构建 Visual Studio 项目的同一用户身份启动 Jenkins 后运行构建时，它运行良好。然而，当我通过另一个本地管理员启动的计划任务以同一用户身份运行项目时，即使进程列表中的用户名相同，构建也会失败。
因此，举例来说，假设该项目作为用户 Admin 构建得很好，无论是在 Visual Studio 中，还是在通过用户启动的 Tomcat 上的 Jenkins 实例启动 MSBuild 时<代码>管理。
当我将用户切换到本地管理员 John.admin 并运行以用户 Admin 身份启动 Tomcat 的计划任务时，它会失败并出现以下 SignTool 错误
VCBUILD: SignTool error : ISignedCode::Sign returned error: 0x80092006
：在进程列表中，Tomcat 以 Admin 用户身份运行，就像 Admin 使用 startup.bat 启动它一样（Tomcat 是一个独立安装）。
我已经尝试了一段时间，但无法弄清楚为什么通过任务启动时构建失败。任何人都可以看到问题吗？机器重新启动并通过另一个本地管理员启动后，Jenkins 构建必须成功。
编辑：我已经复制了Admin用户的所有证书（使用管理单元），所有%PATH%、%CD%、%USERPROFILE% 变量相同，并且任务从同一文件夹运行。我能看到的唯一区别是用户会话 ID 不同。我知道这一点是因为如果我使用 John.admin 启动计划任务，然后以 Admin 身份登录，则 java.exe 不会出现在进程列表中，直到我单击“显示所有用户的进程”，然后显示它以用户 Admin 身份运行。
我几乎没有想法，所以我可以尝试任何事情。
I have an MSBuild that runs through Jenkins with signed code in one of the components.
When I run the build after starting Jenkins as the same user that the visual studio project was built with originally, it works fine. When I run the project as that same user through a scheduled task started by another local admin, however, the build fails, even though the user name in the processes list is the same.
So, for example, say the project was building fine as the user Admin, both in Visual Studio and when launching an MSBuild through a Jenkins instance on Tomcat started by the user Admin.
When I switch the user to John.admin, a local administrator, and run my scheduled task that launches Tomcat as the user Admin, it fails with the following SignTool error:
VCBUILD: SignTool error : ISignedCode::Sign returned error: 0x80092006
In the processes list, it has Tomcat running as the Admin user, same as if Admin had started it with startup.bat (the Tomcat is a standalone install).
I've been trying for a while but can't figure out why the build fails when launched via the task. Can anyone see the problem? It is necessary for Jenkins build to succeed after the machine is restarted and launched via another local admin.
EDIT : I've copied over all certificates for the Admin user (using the snap-in), all %PATH%, %CD%, %USERPROFILE% variables are the same, and the task is being run from the same folder. The ONLY difference I can see is that the user session IDs are different. I know this because if I start the scheduled task with John.admin, and then log in as Admin, the java.exe is not in the process list until I click "show processes from all users", which then shows it running as the user Admin.
I'm pretty much out of ideas, so I'm ok to try anything.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
很难肯定地说，但如果我正确理解了这个问题，我建议您将精力集中在父进程（计划任务）生成子进程时传递的任何环境变量或其他特定于用户的配置上进程（Tomcat）。即使 Tomcat 以管理员身份运行，也可能将
%USERNAME%作为 John.admin 传递给它，或者可能%USERPROFILE%甚至%PATH %传入不正确。另一种可能性：特别是对于计划任务，即使可以找到程序/脚本，我过去也因为没有正确设置“开始于”文件夹而被烧伤。
要排除故障，可以通过临时修改
startup.bat将环境变量的值、当前目录和其他相关配置信息写入日志文件。我对 SignTool 不太熟悉，但这也可能有帮助——
SignTool Error: ISignedCode::Sign returned error: 0x80092006 - 答案讨论私钥的存储位置与搜索位置。
It's hard to say for sure, but if I'm understanding the question correctly, I'd suggest focusing your efforts on any environment variables or other user-specific config that gets passed from the parent process (scheduled task) when it spawns the child process (Tomcat). Even though Tomcat is running as Admin, it's possible that
%USERNAME%is being passed to it as John.admin, or perhaps%USERPROFILE%or even%PATH%is being passed in incorrectly.Another possibility: for scheduled tasks in particular, I've been burned in the past by not setting the "start in" folder properly, even when the program/script can be found.
To troubleshoot, perhaps write the values of your environment variables, current directory, and other relevant config info to a log file by temporarily modifying
startup.bat.I'm not terribly familiar with SignTool, but this might also help --
SignTool Error: ISignedCode::Sign returned error: 0x80092006 -- the answers discuss where the private key is being stored vs. searched for.