IIS托管后，ASPX WebService调用VB6 .EXE执行SQL命令失败

这种问题我之前踩过类似的坑，大概率是权限不匹配或者SQL连接配置导致的——毕竟调试时用的是你本地用户的身份，而IIS托管后，整个服务的运行身份完全变了，咱们一步步来排查：

一、先查IIS应用池的运行身份权限（最常见的原因） #

调试的时候，你的VS是用当前登录的本地用户身份运行的，这个用户大概率已经有访问SQL Server的权限；但IIS默认用的是ApplicationPoolIdentity或者Network Service这类内置账户，这些账户的权限非常有限，既可能没权限访问SQL Server，甚至连网络访问的权限都受限制。

• 临时测试方案：先把你的应用池身份改成LocalSystem（注意：这只是临时排查用，不要长期用，因为这个账户权限太高，有安全风险），如果改完后能正常运行，那实锤就是权限问题。
• 长期解决方案：
  1. 创建一个专门的本地用户或者域用户（推荐域用户，如果是域环境）；
  2. 在SQL Server里给这个用户创建登录名，映射到你要操作的数据库，分配必要的读写权限；
  3. 给这个用户分配VB6 .EXE所在目录的读取+执行权限；
  4. 最后把IIS应用池的运行身份改成这个专门的用户。

二、检查VB6 .EXE里的SQL连接字符串 #

你的VB6程序里的连接字符串可能在调试环境下没问题，但到了IIS的运行身份下就失效了：

• 如果用的是Windows身份验证（比如连接字符串里有Trusted_Connection=Yes），那必须确保应用池的运行身份有SQL Server的登录权限（就是上面第一步要做的）；
• 如果用的是SQL Server身份验证，要确认：
  • 连接字符串里的用户名、密码有没有写错；
  • SQL Server是否启用了混合模式身份验证（默认可能只开了Windows身份验证）；
  • 这个SQL账户有没有被禁用，有没有访问目标数据库的权限；
• 另外，连接字符串里的SQL Server实例名要写对：调试时你可能用localhost或者.\SQLEXPRESS，但IIS的内置账户有时候解析localhost会有问题，换成你的机器全名+实例名（比如DESKTOP-XXX\SQLEXPRESS）试试，同时要确保SQL Server允许远程连接（如果是本地SQL，也要确认TCP/IP协议是启用的）。

三、补全你的ASPX代码，捕获VB6程序的错误输出 #

你现在的代码里虽然开启了RedirectStandardError，但没读取错误内容，这会错过很多关键信息。可以修改代码，把VB6程序抛出的错误完整记录下来，方便排查：

using (System.Diagnostics.Process process = System.Diagnostics.Process.Start(ASN_GRN))
{
    // 读取错误输出和标准输出
    string errorMsg = process.StandardError.ReadToEnd();
    string outputMsg = process.StandardOutput.ReadToEnd();
    // 等待程序执行完成
    process.WaitForExit();
    
    // 把错误信息记录到日志（比如Event Log或者本地日志文件）
    if (!string.IsNullOrEmpty(errorMsg))
    {
        // 这里可以写日志逻辑，比如System.Diagnostics.EventLog.WriteEntry("WebService调用VB6", errorMsg);
    }
}

四、额外检查：VB6 .EXE所在目录的权限 #

虽然你的错误是SQL连接失败，但也要确保应用池的运行身份有读取和执行这个EXE的权限：右键EXE所在文件夹 → 属性 → 安全 → 添加应用池身份（格式是IIS AppPool\你的应用池名称），给它分配读取和执行的权限。

五、SQL Server的基础配置检查 #

如果前面的步骤都没问题，再检查SQL Server本身的配置：

• 打开SQL Server配置管理器，确认SQL Server网络配置里的TCP/IP协议是启用的；
• 检查防火墙是否开放了SQL Server的默认端口（1433），允许应用池的运行身份访问这个端口；
• 确认SQL Server服务是正常运行的，实例名没有写错。

先从应用池权限和连接字符串这两点入手排查，大概率能解决问题，毕竟我之前就是这么搞定类似问题的😉

内容来源于stack exchange