通过WinDbg“启动可执行文件”调试.NET Core控制台程序遇访问违例

问题根源 #

• !bpmd 是依赖.NET CLR的托管断点命令，若在程序早期（模块刚加载但目标托管方法尚未完成JIT编译）执行该命令，断点可能被绑定到未初始化的无效内存地址，触发访问违例。
• Any CPU编译的程序在64位Windows下默认以64位模式运行，若WinDbg调试会话的位数与程序不匹配，也会引发内存访问错误。

修复步骤 #

1. 调整断点设置时机，确保CLR完全初始化 #

修改调试流程，等待.NET Core运行时核心模块加载完成后再设置托管断点：

• 打开WinDbg Preview，通过“启动可执行文件”加载Simplicity01.exe
• 执行命令：sxe ld:coreclr.dll（设置断点，等待coreclr.dll加载）
• 执行命令：g（继续运行，触发coreclr.dll加载断点）
• 执行命令：!loadby sos coreclr（加载SOS调试扩展，用于解析托管代码）
• 执行命令：!bpmd Simplicity01 Simplicity01.Program.TestDebugging01（设置目标方法的托管断点）
• 执行命令：g（继续运行，触发托管方法断点）

2. 匹配WinDbg与程序的运行位数 #

• 若程序以64位模式运行（64位系统下Any CPU默认64位），使用64位WinDbg Preview启动调试；若需强制32位运行程序，切换为32位WinDbg。
• 建议在Visual Studio中明确指定项目目标平台为x64或x86，避免Any CPU带来的位数不确定性。

3. 替代方案：通过SOS命令定位JIT地址后设置原生断点 #

如果!bpmd仍出现异常，可手动定位托管方法的JIT编译地址后设置原生断点：

• 等待coreclr.dll加载完成后，执行!dumpassembly找到Simplicity01.exe对应的程序集地址
• 执行!dumpclass <程序集中Program类的地址>，获取该类的MethodTable
• 执行!dumpmt -md <MethodTable地址>，找到TestDebugging01方法的MethodDesc地址
• 执行!dumpmd <MethodDesc地址>，查看JIT编译后的代码地址（CodeAddr字段）
• 执行bp <CodeAddr>设置原生断点，再执行g触发断点

4. 检查编译配置 #

• 确保程序以Debug模式编译，取消勾选“优化代码”（项目属性→生成→优化代码），避免JIT优化导致断点位置偏移。
• 确保生成完整调试信息（项目属性→生成→高级→调试信息选择“完整”），提升WinDbg对托管代码的解析能力。

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