无源码C#遗留EXE程序加载后自动关闭及SQL Server连接异常排查问询

大卫你好，针对你遇到的这个无源码C#遗留程序的问题，我整理了几个实用的排查方向，帮你一步步定位根源：

这个问题大概率是程序启动时抛出了未处理的异常导致崩溃，你可以通过以下方式捕获错误信息：

• 查看Windows事件日志：打开「事件查看器」→「Windows日志」→「应用程序」，找带有.NET Runtime或Application Error标签的条目，里面会记录异常类型、调用栈等关键信息，这是最直接的崩溃线索。
• 用调试工具附加进程：打开Visual Studio（即使没有源码），点击「调试」→「附加到进程」，在程序启动瞬间快速选中它（可以先打开程序，然后立刻切到VS点击附加），这样程序崩溃时会触发调试断点，能看到错误详情。另外也可以用*ProcMon（Process Monitor）*跟踪程序的文件、注册表、网络操作，看有没有访问被拒绝、文件找不到之类的异常操作。
• 强制启用控制台输出：如果是WinForms/WPF程序，默认会隐藏控制台窗口，你可以通过两种方式查看输出：一是在cmd窗口里直接运行EXE文件；二是用工具比如CFF Explorer修改EXE的子系统类型为「控制台子系统」，这样启动后窗口不会自动关闭，能看到程序输出的错误提示。

这里核心差异是运行身份不同导致的Windows身份验证权限差异：

• 普通运行时，程序用的是你当前登录用户的Windows身份连接SQL Server，而你用sqlcmd -E测试正常，说明这个用户有SQL访问权限；
• 管理员运行时，程序用的是管理员账户的Windows身份，这个账户大概率没有被授予SQL Server的访问权限。

排查步骤：

• 验证管理员身份的SQL连接：用管理员身份打开cmd，运行sqlcmd -S 你的SQL服务器名 -E，如果无法登录，说明管理员账户确实没有SQL权限；
• 给管理员账户添加SQL权限：在SQL Server Management Studio中，进入「安全性」→「登录名」，检查管理员账户（比如DOMAIN\你的管理员用户名）是否存在，如果不存在就新建登录名，然后给它分配对应数据库的用户权限（比如db_datareader、db_datawriter）。

虽然你用sqlcmd测试正常，但还是可以确认几个点：

• 反编译查看连接字符串：用ILSpy或dnSpy打开EXE文件，找到程序的配置节点（通常在App.config或嵌入的资源里），确认connectionString中的Integrated Security=True是否存在，以及服务器名、数据库名是否正确（比如服务器是否有过迁移、改名）；
• 检查SQL Server身份验证模式：在SQL Server属性的「安全性」选项卡中，确认是否开启了「Windows身份验证模式」（如果改成了仅SQL Server身份验证，那Windows身份验证会失效，但你sqlcmd -E能连，这个可能性不大）。

• 依赖项缺失/版本不匹配：用Dependency Walker或Process Explorer查看程序加载的DLL文件，看有没有缺失的.NET Framework组件或第三方依赖库。普通运行时可能因为依赖缺失崩溃，管理员运行时可能加载了系统路径下的依赖但权限不足；
• UAC虚拟化影响：普通权限运行时，程序可能被UAC虚拟化，配置文件会被写到C:\Users\你的用户名\AppData\Local\VirtualStore目录下，导致读取不到正确的连接字符串；管理员运行时没有虚拟化，读取的是真实路径的配置，但身份权限不对。可以检查这两个目录下的exe.config文件是否存在差异。

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