Visual Studio Debugger

Visual Studio Debugger 
Just-In-Time Debugging 

 

This topic applies to:

Visual Studio Edition

Visual Basic

C#

C++

J#

Express

No

No

No

No

Standard

Yes

Yes

Yes

Yes

Pro/Team

Yes

Yes

Yes

Yes

Just-In-Time debugging is a feature that launches the Visual Studio debugger automatically when a program, running outside Visual Studio, encounters a fatal error. Just-In-Time debugging allows you to examine the error before the application is terminated by the operating system. The Visual Studio debugger does not need to be running when the error occurs.

If an error occurs while Just-In-Time debugging is enabled, a dialog box opens, asking if you want to debug the program and which debugger you want to use.

If a program running as another user hits a fatal error, a security warning dialog box appears before the debugger starts. For more information, see Security Warning: Attaching to an Untrusted Process Can Be Dangerous.

You can enable Just-In-Time debugging from the Options dialog box. For more information, see How to: Enable/Disable Just-In-Time Debugging.

For Windows forms, you must also enable Just-In-Time debugging in the machine.config or application.exe.config file. For more information, see How to: Enable Just-In-Time Debugging for Windows Forms.

After Visual Studio is installed on a server, the default behavior when an unhandled exception occurs is to show an Exception dialog that requires user intervention to either start Just-In-Time debugging or ignore the exception. This may be undesirable for unattended operation. To configure the server to no longer show a dialog when an unhandled exception occurs (the default behavior prior to installing Visual Studio), use the registry editor to delete the following registry keys:

  • HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows NT/CurrentVersion/AeDebug/Debugger

  • HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/.NETFramework/DbgManagedDebugger

On a 64-bit operating system also delete the following registry keys:

  • HKEY_LOCAL_MACHINE/SOFTWARE/Wow6432Node/Microsoft/Windows NT/CurrentVersion/AeDebug/Debugger

  • HKEY_LOCAL_MACHINE/SOFTWARE/Wow6432Node/Microsoft/.NETFramework/DbgManagedDebugger

NoteNote

Just-In-Time debugging will not work for managed code hosted in a native application, such as Visualizers.

NoteNote

After installing the .NET Framework on Windows Server 2003 or on Windows 2000 SP3 (or later), Just-In-Time debugging will not work on a process running in a limited user account in a Terminal Services session until the computer has been rebooted.

See Also

<think>好的,用户现在想了解如何使用Visual Studio Debugger来诊断System.ExecutionEngineException异常。首先,我需要回忆之前关于这个异常的回答,确保这次的信息不重复但补充详细的操作步骤。 用户之前的问题是关于这个异常的原因和解决方案,现在转向具体的诊断工具使用。我需要确保回答结构清晰,分步骤说明,同时结合之前的引用点,比如内存损坏、第三方库冲突等可能原因,并指导如何用调试工具定位。 首先,要介绍启用调试符号和异常捕获设置,因为这是使用Visual Studio Debugger的基础。需要提到符号服务器的配置,确保能加载正确的PDB文件。然后,设置调试器在异常发生时中断,特别是对于非托管代码异常的处理。 接下来,内存诊断工具是关键,比如检查堆破坏和内存泄漏。这里可能需要使用到Visual Studio的Diagnostic Tools窗口,以及启用页堆或应用验证器。这些工具能帮助识别内存访问越界等问题,这些可能是导致ExecutionEngineException的原因。 然后是调用堆栈分析,用户需要知道如何查看崩溃时的堆栈,特别是非托管代码部分。需要说明如何切换托管和非托管堆栈视图,以及如何检查第三方库的版本兼容性。此外,转储文件的生成和分析也是重要的一环,用户可能需要在生产环境中捕获转储文件以便后续分析。 还要考虑代码审查和简化测试环境,比如建议用户注释代码块逐步排查,或者创建最小化测试用例。这部分可以帮助用户隔离问题,确定是否是特定代码段或依赖库导致的问题。 最后,需要补充注意事项,比如更新Visual Studio和.NET框架,检查硬件问题,以及建议使用WinDbg进行高级分析。这些点能帮助用户全面覆盖可能的故障源。 在生成相关问题的时候,要确保问题与当前主题相关,比如如何配置符号服务器,使用WinDbg分析转储文件,或者内存诊断工具的使用方法。这些问题能引导用户进一步学习相关工具和技术。 现在需要检查是否所有步骤都覆盖了可能的诊断方法,是否引用了之前的要点(如内存损坏、第三方库冲突),以及是否提供了具体的操作指导,比如菜单路径或命令行工具。同时,确保语言简洁,步骤明确,用户能按图索骥进行操作。</think>### 使用 Visual Studio Debugger 诊断 `System.ExecutionEngineException` 的详细步骤 `System.ExecutionEngineException` 通常由底层运行时(CLR/JIT)的致命错误引发,且难以通过常规代码捕获。以下是使用 Visual Studio Debugger 进行诊断的完整流程: --- #### 1. **启用调试符号与异常捕获** - **步骤 1:配置符号服务器** 在 Visual Studio 中,依次打开 `工具 > 选项 > 调试 > 符号`,勾选 `Microsoft 符号服务器` 和 `NuGet.org 符号服务器`,确保加载核心系统库的调试符号(PDB 文件)[^1]。 *作用:帮助调试器定位非托管代码(如 CLR 内部代码)的崩溃位置。* - **步骤 2:设置异常捕获** 打开 `调试 > 窗口 > 异常设置`,勾选 `Common Language Runtime Exceptions` 的 `引发时中断`。 *注意:由于 `ExecutionEngineException` 可能无法被捕获,需同时启用非托管代码调试(项目属性 > 调试 > 启用本机代码调试)[^2]。* --- #### 2. **内存诊断工具** - **步骤 3:启用内存诊断** 在调试时打开 `诊断工具` 窗口(`调试 > 窗口 > 显示诊断工具`),勾选 `内存使用量` 和 `托管内存`。 *作用:检测堆破坏(Heap Corruption)或内存泄漏,常见于非法指针操作或跨托管/非托管边界错误[^3]。* - **步骤 4:使用页堆(PageHeap)** 通过命令行工具 `gflags.exe`(Windows SDK 自带)启用页堆检测: ```bash gflags /p /enable YourApp.exe /full ``` *作用:标记内存页的访问权限,捕捉越界写入或释放已释放内存的操作[^4]。* --- #### 3. **崩溃时的堆栈分析** - **步骤 5:捕获崩溃现场** 当异常触发时,调试器会暂停执行。在 `调用堆栈` 窗口中: - 切换至 `混合模式` 视图(托管 + 非托管堆栈)。 - 查找包含 `clr.dll`、`mscorwks.dll` 或第三方非托管库的帧(Frame)。 *示例:若堆栈显示 `clr!JIT_New`,可能涉及对象分配时的内存损坏[^5]。* - **步骤 6:检查内存转储文件** 在异常发生后,通过 `调试 > 保存转储文件` 生成 `.dmp` 文件。使用 WinDbg 加载转储文件并运行以下命令: ```bash !analyze -v # 自动分析崩溃原因 !clrstack # 查看托管堆栈 !dumpheap -stat # 统计托管堆对象 ``` *作用:定位崩溃时的线程状态和内存异常[^6]。* --- #### 4. **代码审查与简化测试环境** - **步骤 7:逐步注释代码块** 如果崩溃难以复现,逐步注释代码区域(尤其是涉及非托管交互的代码,如 `DllImport` 或 `unsafe` 块),缩小问题范围。 - **步骤 8:最小化测试用例** 创建一个仅包含核心逻辑的新项目,排除第三方库干扰。若问题消失,逐步添加依赖项以定位冲突源[^7]。 --- #### 5. **补充工具与注意事项** - **启用应用验证器(Application Verifier)** 针对非托管代码,使用 Application Verifier 检测内存违规行为(如无效句柄使用)。 - **更新 Visual Studio 和 .NET 框架** 确保使用最新稳定版本的开发工具,修复已知运行时缺陷。 - **硬件检查** 若崩溃随机发生且无明确模式,运行内存诊断工具(如 Windows 内存诊断)排除硬件故障[^8]。 --- ```csharp // 示例:可能导致内存损坏的 unsafe 代码 unsafe { int* ptr = stackalloc int[10]; ptr[15] = 42; // 越界写入,可能触发堆破坏 } ``` --- ### 相关问题 1. 如何配置 Visual Studio 的符号服务器以调试 .NET Framework 内部代码? 2. WinDbg 中常用的命令有哪些用于分析 .NET 内存转储文件? 3. 如何通过 Application Verifier 检测非托管代码的内存错误? 4. 在多线程环境下,如何通过调试器捕捉竞态条件导致的崩溃? --- 通过上述方法,可系统性地定位 `System.ExecutionEngineException` 的根源。若问题仍无法解决,建议提交最小化复现代码至 .NET 运行时仓库(dotnet/runtime)寻求官方支持[^9]。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值