“从服务器返回了一个参照”：一次 Windows 程序启动失败排查
文中厂商、程序名称及安装路径已匿名化，被启动的目标程序统一记为
target.exe，验签和文件对比均围绕该程序展开。命令中的路径为示例，执行时请替换为实际路径。配图用于说明相应的签名错误和证书字段，已裁剪并遮盖身份信息，保留区域未重绘。
概述
本次排查起于用户反馈：本应由守护机制启动的 target.exe 未正常运行。排查从进程状态和目标程序的运行日志入手，再沿启动链路向上追踪，查找未能正常运行的原因。本文按这一过程，记录各阶段的检查方法、结果与判断，以及后续的修复措施。
1. 问题描述
2026 年 9 月某日，有用户反馈：在公司生产销售的某设备上，公司自主开发、由守护机制负责启动的 target.exe 未正常运行。
预期状态是目标程序按守护启动机制运行，实际观察到的表象则是 target.exe 未运行。此时尚不清楚程序是未能启动、启动后退出，还是启动链路中的其他环节出现了问题，需要通过后续检查确定原因。
2. 运行环境
这套程序运行于 Windows，涉及守护进程、启动器 Launcher 和目标程序 target.exe。以下为排查中确认的运行关系与配置，作为后续分析的背景：
| 对象 | 已知条件 |
|---|---|
| 守护进程 | 负责守护目标程序，通过 Launcher 发起启动 |
| 启动器 Launcher.exe | 通过 Process.Start 请求启动 target.exe，并记录启动异常 |
| 目标程序 target.exe | 声明 uiAccess="true" |
target.exe 由守护进程通过 Launcher 启动，链路如下：
守护进程
→ Launcher.exe
→ target.exe
后文涉及目标文件的命令统一使用以下示例路径：
C:\Program Files\ExampleApp\target.exe
两台电脑的 Windows 具体版本与补丁水平未纳入本文，后文的跨电脑对照仅据验签结果作判断。
3. 初步排查与问题推断
3.1 进程与运行日志检查
首先检查进程列表，未发现 target.exe 的实例进程。随后查看目标程序自身的运行日志，也未发现近期的运行记录。
这两项结果确认了检查时目标程序未在运行，且其日志中没有近期运行的迹象。但仅凭进程不存在和缺少运行日志，还不足以区分程序未能启动与启动后很快退出。
根据第 2 节的启动链路，接下来上溯检查负责发起目标进程启动请求的 Launcher 日志。后续文件检查也需以 Launcher 实际传入的 ProcessStartInfo.FileName 为准，确保进程检查、日志检查和验签针对同一个目标程序。
3.2 Launcher 日志与调用堆栈分析
上溯检查 Launcher 日志后，发现以下异常记录：
错误描述：从服务器返回了一个参照。
异常：System.ComponentModel.Win32Exception (0x80004005)
System.Diagnostics.Process.StartWithShellExecuteEx(ProcessStartInfo startInfo)
ExampleApp.AppLauncher.ProcessHelper.StartProcess(String processPath, String args)
ExampleApp.AppLauncher.AppLauncher.StartProcess(String startupPath, String args)
ExampleApp.AppLauncher.AppLauncher.Run(String[] args, Boolean useCache)
Launcher.Program.Main(String[] args)
Process.StartWithShellExecuteEx 表明，异常出现在 Launcher 通过 Windows Shell 请求启动 target.exe 的过程中。到这里，排查才取得了指向启动请求失败的明确证据，检查范围进一步缩小到目标程序的启动条件。
日志中的 0x80004005 是 HRESULT E_FAIL，表示未指定的错误，单靠这个值无法进一步定位。这份日志没有记录 NativeErrorCode，也无法据此取得更具体的本机错误码。[1]
启动请求失败的阶段得到定位后，接下来将日志中的错误描述与已知的 UIAccess 配置结合，判断具体检查方向。
3.3 错误提示与 UIAccess 配置分析
注意到日志中出现了“从服务器返回了一个参照”的提示。结合 target.exe 已声明 uiAccess="true" 的配置，初步考虑启动失败可能与签名验证有关，因此将下一步检查重点放在该程序的数字签名状态上。
这一关联需要放在 Windows 进程启动场景下理解。UIAccess 允许特定辅助功能程序在受控条件下与更高权限程序的界面交互，申请这一能力的程序必须满足 Windows 的签名与信任要求：目标文件应具有数字签名，且签名所需的证书链能够获得本机信任。微软还区分了签名检查与安全安装位置检查；改变后者的策略状态，并不会取消前者的要求。[2]
这条错误提示与上述要求的联系，也有同类问题记录支持：PyInstaller 项目维护者曾针对相同的启动报错指出，使用 UIAccess 需要对程序签名。因此，在已知目标程序申请 UIAccess 的情况下，出现“从服务器返回了一个参照”，应将目标文件的签名及信任验证列为优先检查项。[3]
这条提示也可能对应其他原因，因此上述推断仍需通过实际验签结果确认；此时尚不能认定文件损坏、证书过期或证书链缺失。接下来直接检查 target.exe 的签名状态。
4. 数字签名验证
4.1 文件属性检查
在问题电脑上检查 target.exe，打开“属性 → 数字签名 → 详细信息”，界面显示以下错误：
一个副署无效。文件可能已更改。
图1：副署错误的界面示例。厂商名称已遮盖，签名时间和错误文字保留。
继续进入证书窗口后，提示进一步指向时间戳：
时间戳签名和/或证书无法验证或已损坏。
图2：时间戳验证错误的界面示例，保留了颁发者和有效期信息。
上述提示将问题进一步指向 target.exe 的签名验证。不过，“文件可能已更改”仍然只是一条错误提示，是否存在文件内容变化，还需要另外验证。
4.2 PowerShell 验证
随后使用 Get-AuthenticodeSignature 获取便于记录和比较的验证结果。该命令可以返回文件的 Authenticode 签名状态，以及签名者和时间戳证书信息。[4]
$exePath = 'C:\Program Files\ExampleApp\target.exe'
Get-AuthenticodeSignature -LiteralPath $exePath |
Format-List Path, Status, StatusMessage,
SignerCertificate, TimeStamperCertificate
输出中的关键状态如下：
Status : UnknownError
StatusMessage : 时间戳签名和/或证书无法验证或已损坏。
图形界面与命令状态指向同一个结果：问题电脑无法完成 target.exe 的时间戳验证。 对声明了 uiAccess="true" 的目标程序而言，签名验证失败会影响其满足启动要求。由此可以继续沿目标程序的签名和证书链排查，具体失败原因仍需进一步确认。
5. 异常原因分析
5.1 文件一致性对比
针对“文件可能已更改”的提示，将问题设备上的 target.exe 与其他设备上同版本、签名验证正常的 target.exe 进行 MD5 对比，结果显示两者的 MD5 一致。
这一对比未发现问题文件与正常对照文件存在内容差异的迹象，但两份文件在各自设备上的签名验证结果不同。哈希比较的是文件内容，签名验证还涉及证书及其信任关系，因此接下来进一步检查设备验证环境是否影响结果。
复用这一步时，可以分别记录两份文件的路径、大小和 SHA-256，确保对比对象一致。本次已有的文件对比依据是 MD5。
5.2 跨电脑验签对比
为进一步验证，将问题设备上的 target.exe 复制到另一台电脑（下称“对照电脑”），直接检查这份复制文件的数字签名，结果显示正常。
| 对比项 | 问题电脑 | 对照电脑 |
|---|---|---|
| 检查对象 | target.exe | 从问题电脑复制的同一 target.exe |
| 数字签名 | 文件属性显示无效，PowerShell 报时间戳验证异常 | 文件属性显示正常 |
同一个文件在两台电脑上的验签结果不同，为进一步缩小原因范围提供了依据。 文件内容本身不足以解释这一差异，排查重点由此转向问题电脑的验证环境。
数字签名验证除了文件内容，还依赖证书链、根信任、用途限制、吊销信息和系统时间。因此，文件没有变化，验签结果仍然可能因电脑环境不同而变化。此时还需要继续区分这些因素。
5.3 证书有效期核对
继续检查 target.exe 的签名者证书，发现其已经到期。为判断它与本次故障的关系，进一步对照文件显示的签名时间、签名者证书有效期和时间戳证书有效期：
| 项目 | 检查结果 |
|---|---|
| 签名者 | 某软件厂商（已脱敏） |
| 文件显示的签名时间 | 2025-06-10 10:06:57 |
| 签名者证书有效期 | 2022-10-27 至 2025-10-29 |
| 签名者证书颁发者 | DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1 |
| 时间戳证书 | DigiCert Timestamp 2024 |
| 时间戳证书有效期 | 2024-09-26 至 2035-11-26 |
| 时间戳证书颁发者 | DigiCert Trusted G4 RSA4096 SHA256 TimeStamping CA |
以上日期采用检查时电脑显示的本地时间。
故障发生在 2026 年，签名者证书确实已于 2025 年到期；但文件显示的签名时间是 2025 年 6 月，处于该证书的有效期内。有效且受信任的时间戳，可以支持在签名者证书到期后继续验证旧签名，最终是否通过仍取决于完整的验证条件。[5]
另外，时间戳证书自身到 2035 年才到期。结合对照电脑验签正常的结果，仅凭签名者证书当前已到期，还不足以解释本次故障。后续仍需检查问题电脑无法验证时间戳的具体原因。
5.4 阶段性判断
上述检查结果及其对判断的作用如下：
| 检查结果 | 对判断的作用 |
|---|---|
| 问题设备上的 target.exe 与其他设备上同版本、签名验证正常的文件 MD5 一致 | 未发现问题文件与正常对照文件存在内容差异的迹象 |
| target.exe 属性与 PowerShell 均显示时间戳验证异常 | 确认目标文件在问题电脑上验签失败 |
| 同一 target.exe 在对照电脑上验签正常 | 支持继续检查两台电脑的验证环境差异 |
| 显示的签名时间处于签名者证书有效期内，时间戳证书尚未到期 | 不能仅用签名者证书当前已到期解释故障 |
综合这些结果，排查重点进一步收敛到问题电脑的证书验证环境。 此时还不能确定具体缺少哪张证书，但时间戳错误已给出方向，下一步从其证书路径和本机证书存储继续检查。
6. 修复过程与验证
6.1 证书路径检查与初次修复
从 target.exe 的数字签名详情进入时间戳证书，打开“证书路径”页面，选中 DigiCert Timestamp 2024，证书状态显示：
此证书对于所选的目的似乎无效。
图3：时间戳证书路径与用途无效提示的界面示例。背景程序标题已裁去。
“所选的目的似乎无效”将检查方向指向证书用途和上级证书。查阅 DigiCert 的问题说明后发现，早期的一版 G4 交叉证书，其增强密钥用法（EKU）仅允许时间戳用途；当它同时用于构建代码签名证书链时，会因用途限制导致验证失败。DigiCert 后来提供了修正版交叉中间证书。[6]
这一同类问题提供了尝试方向，因此先安装修正版交叉中间证书，检查能否解决当前的验证错误。
安装后，问题仍然存在。 这次尝试针对交叉证书的用途兼容性，而验证路径还需要连接到本机受信任的根证书。因此继续检查本机已安装的证书，以及它们能否组成受信任的验证路径。
6.2 本机证书存储检查
使用下面的命令，枚举当前用户和本地计算机的根证书、中间证书存储，筛选 DigiCert 相关条目：
Get-ChildItem Cert:\LocalMachine\Root, Cert:\LocalMachine\CA,
Cert:\CurrentUser\Root, Cert:\CurrentUser\CA |
Where-Object {
$_.Subject -like '*DigiCert*' -or
$_.FriendlyName -like '*DigiCert*'
} |
Select-Object PSParentPath, Subject, Issuer, SerialNumber,
Thumbprint, NotAfter, EnhancedKeyUsageList |
Format-List
结果中已经有 DigiCert Trusted Root G4，但进一步查看它的颁发者和存储位置，得到的是：
Subject : DigiCert Trusted Root G4
Issuer : DigiCert Assured ID Root CA
Thumbprint : A99D5B79E9F1CDA59CDAB6373169D5353F5874C6
位置 : LocalMachine\CA
这张证书的颁发者是 DigiCert Assured ID Root CA，它是交叉中间证书，不能仅因为名称里有 Root，就认为本机已具备对应的自签名根证书。
为区分两个同名版本，进一步核对它们的颁发者、指纹和应放置的存储：
| 项目 | 已安装的交叉中间证书 | 对应的自签名根证书 |
|---|---|---|
| Subject | DigiCert Trusted Root G4 | DigiCert Trusted Root G4 |
| Issuer | DigiCert Assured ID Root CA | DigiCert Trusted Root G4 |
| 安装位置 | 中间证书颁发机构，CA | 受信任的根证书颁发机构，Root |
对应的 SHA-1 证书指纹如下：
交叉中间证书（CA）
A99D5B79E9F1CDA59CDAB6373169D5353F5874C6
自签名根证书（Root）
DDFB16CD4931C973A2037D3FC83A4D7D775D05E4
根证书列表中未发现交叉证书的上级 DigiCert Assured ID Root CA，也未发现自签名的 DigiCert Trusted Root G4。列表中虽有 Assured ID Root G2、G3，但它们是其他证书，不能互相替代。
对应的时间戳中间证书也没有出现在枚举结果中。这一项仍需谨慎理解：验签还可能使用文件内嵌证书或缓存，因此存储列表中没有，不等于验证时一定无法取得。
此外，输出中的 EnhancedKeyUsageList : {} 不能直接解释为“禁止所有用途”。用途判断还涉及证书扩展和本地属性，不能只凭这个空列表下结论。[7]
证书存储检查进一步发现，本机存储中未见支撑这条验证路径的对应受信任根。 据此，修复方案调整为补齐相关证书。
6.3 修复方案调整
调整后的方案是补入自签名 G4 根证书和对应的时间戳中间证书，为验证提供下面这条路径：
DigiCert Timestamp 2024
→ DigiCert Trusted G4 RSA4096 SHA256 TimeStamping CA
→ DigiCert Trusted Root G4（自签名、受信任根）
自签名 G4 根证书提供本机信任锚，时间戳中间证书负责将末端时间戳证书连接到这个根。这个方案针对的是前面检查到的信任链问题，是否生效还需要导入后复测。
所需的两张证书均可从 DigiCert 官方下载：
这两个官方 DER 格式文件的 SHA-256 如下，可与 DigiCert 官方证书列表对照。[8]
DigiCertTrustedRootG4.crt
552F7BDCF1A7AF9E6CE672017F4F12ABF77240C78E761AC203D1D9D20AC89988
DigiCertTrustedG4RSA4096SHA256TimeStampingCA.crt
281734D4592D1291D27190709CB510B07E22C405D5E0D6119B70E73589F98ACF
下载后，将两个文件放到同一目录，可以使用以下命令核对文件哈希：
Get-FileHash -Algorithm SHA256 -LiteralPath `
'.\DigiCertTrustedRootG4.crt', `
'.\DigiCertTrustedG4RSA4096SHA256TimeStampingCA.crt' |
Format-List Path, Hash
6.4 证书导入
这次修复将自签名根证书加入问题电脑的“本地计算机 → 受信任的根证书颁发机构”，将时间戳中间证书加入“本地计算机 → 中间证书颁发机构”。
以下管理员 PowerShell 命令可以完成对应的导入操作，执行前需切换到证书文件所在目录：
certutil -addstore Root ".\DigiCertTrustedRootG4.crt"
certutil -addstore CA ".\DigiCertTrustedG4RSA4096SHA256TimeStampingCA.crt"
第一条命令导入根存储，第二条导入中间证书存储。certutil -addstore 的参数说明见参考文献。[9]
如果通过图形界面导入，也应先选择“本地计算机”，再指定各自的存储位置。此前指纹为 A99D5B79… 的交叉证书属于 CA 存储，应与这次导入的自签名根证书区分。
6.5 复测方法与修复结果
证书导入后，可按以下方法复测：先验证目标文件的签名，再检查“守护进程 → Launcher → target.exe”的原有启动链路。
验签时，先关闭已打开的文件属性、数字签名和证书窗口，再重新检查 target.exe。通常不需要重启整台电脑，可以先重新打开验证窗口、重新启动相关进程。
以下是复测命令示例，路径应与 Launcher 实际启动的目标文件一致：
$exePath = 'C:\Program Files\ExampleApp\target.exe'
Get-AuthenticodeSignature -LiteralPath $exePath |
Format-List Path, Status, StatusMessage
验签的预期结果是 Status 为 Valid。随后按原有守护机制触发启动，检查守护进程能否经 Launcher 启动 target.exe，目标进程是否出现、运行日志是否恢复更新，以确认最初“被守护程序未运行”的问题是否解决。
本次现场反馈确认，补齐 DigiCert 自签名 G4 根证书和时间戳中间证书后，target.exe 恢复正常运行，原先的启动故障得到解决。
7. 总结
本次故障与问题电脑的证书信任链不完整有关。target.exe 申请 UIAccess，需要满足 Windows 对目标程序的签名与信任要求。检查发现，本机无法完成其时间戳验证，证书存储中也未见对应的受信任根。补齐 DigiCert 自签名 G4 根证书和时间戳中间证书后，目标程序恢复正常运行。
这次排查中，文件对比、有效期核对和跨电脑验签分别回答了不同的问题：文件是否一致、签名时间是否处于证书有效期内，以及同一文件的验证结果是否受本机环境影响。文件哈希一致，并不意味着在所有电脑上都能通过验签；签名者证书当前已到期，也不能单独解释带时间戳的签名为何失效。 将这些因素分开检查，有助于逐步缩小原因范围。
排查类似故障时，建议将实际目标文件、修复前后验签结果和启动复测结果一并记录。启动器日志还可以增加 HResult、NativeErrorCode、Message，以及 ProcessStartInfo 的 FileName、Verb、UseShellExecute，便于将异常与具体启动请求对应。[10]
附录：参考文献
- Microsoft：E_FAIL：说明 0x80004005 的含义。
- Microsoft：UIAccess 签名与信任要求：说明签名检查与安全安装位置检查的关系。
- PyInstaller 项目维护者答复：同类启动报错与 UIAccess 签名要求的实例。
- Microsoft：获取文件的 Authenticode 签名信息：Get-AuthenticodeSignature 命令说明。
- Microsoft：Authenticode 时间戳机制：说明时间戳与签名者证书到期后的验证。
- DigiCert：时间戳交叉证书导致验签失败的问题说明：用于检查交叉证书的用途兼容性。
- Microsoft：证书增强密钥用法的读取规则：说明用途扩展与证书本地属性的关系。
- DigiCert：官方根证书与中间证书列表：用于核对证书来源及指纹。
- Microsoft：certutil 命令：证书存储与 addstore 参数说明。
- Microsoft：Win32Exception 的本机错误码属性：说明 NativeErrorCode 的作用。
浙公网安备 33010602011771号