ASP.NET MVC 5在IIS中调用Process.Start生成PDF突然失败求助

核心排查方向 #

既然本地CMD、LINQPad能正常生成PDF，仅IIS环境失效，且已开放Everyone完全控制权限，问题必然出在IIS运行环境与本地桌面环境的差异上，以下是针对性排查和解决步骤：

1. 捕获Chrome进程的错误输出 #

当前代码未捕获进程执行的错误信息，这是排查的关键第一步。修改代码，记录Chrome的标准输出和错误日志：

var psi = new ProcessStartInfo
{
    FileName = "cmd.exe",
    Arguments = "/C \"\"C:/Program Files/Google/Chrome/Application/chrome.exe\" --headless --disable-gpu --no-sandbox --run-all-compositor-stages-before-draw --no-margins --no-pdf-header-footer --print-to-pdf=E:\\Chrome-Print-to-PDF\\test.pdf E:\\Chrome-Print-to-PDF\\test.html\"",
    RedirectStandardOutput = true,
    RedirectStandardError = true,
    UseShellExecute = false,
    CreateNoWindow = true,
    WorkingDirectory = Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData)
};

using (var process = Process.Start(psi))
{
    string output = process.StandardOutput.ReadToEnd();
    string error = process.StandardError.ReadToEnd();
    process.WaitForExit(30000); // 超时30秒
    
    // 写入日志文件
    File.WriteAllText(@"E:\Chrome-Print-to-PDF\chrome-debug.log", $"Exit Code: {process.ExitCode}\nOutput:\n{output}\nError:\n{error}");
}

查看日志即可定位具体错误（如沙箱权限不足、路径找不到等）。

2. 添加--no-sandbox参数 #

Chrome自动更新后，新版本无头模式默认启用沙箱，但IIS应用池运行的用户（如IIS AppPool\YourAppPoolName）没有创建沙箱的权限，这是最常见的突然失效原因。直接在Chrome参数中加入--no-sandbox即可绕过。

3. 检查应用池配置 #

• 32位/64位兼容性：如果应用池启用了启用32位应用程序，而Chrome是64位安装版，会导致找不到Chrome路径。进入应用池高级设置，将该选项设为False。
• 应用池身份权限：虽然给了Everyone权限，建议直接给应用池身份（如IIS AppPool\YourAppPoolName）授予Chrome安装目录（C:\Program Files\Google\Chrome\Application）和PDF输出目录的完全控制权限，避免权限继承问题。
• 快速失败保护：如果应用池因多次异常被暂停，会导致无法启动进程。进入应用池高级设置，暂时关闭快速失败保护，或调整失败次数阈值。

4. 验证Chrome版本兼容性 #

Chrome自动更新可能引入参数变更或兼容性问题：

• 回退到之前能正常工作的Chrome版本（可下载旧版MSI安装包，关闭自动更新）。
• 替换为Chromium稳定分支，或使用专门的无头PDF生成工具（如Puppeteer Sharp，需注意.NET Framework兼容性）。

5. 检查Windows事件日志 #

打开事件查看器，查看Windows日志 -> 应用程序和系统日志，寻找Chrome启动失败、进程异常退出的相关事件，获取系统层面的错误提示。

内容的提问来源于stack exchange，提问作者Gup3rSuR4c