启用c++异常中断需手动勾选ctrl+alt+e中的c++ exceptions选项，否则throw无法触发断点；子线程异常需外层try/catch捕获并确保符号加载；条件断点可按线程id过滤；诊断工具“事件”选项卡可记录静默异常。
启用 C++ 异常中断必须勾选
VS 默认不会在 throw 发生时中断，尤其对自定义异常类型或未显式声明在异常设置列表里的类型——这导致你看到“程序崩溃退出”，却找不到 throw 那一行。打开 Ctrl + Alt + E，展开 C++ Exceptions，**必须手动勾选 **，否则哪怕抛的是 std::runtime_error 的子类，也可能直接跳过断点。
常见错误现象：断点设在 catch 块里，但程序仍一闪而过；或者只在主线程中断，子线程抛异常后静默终止。
- 勾选
std::exception不够，它不覆盖派生类的动态类型识别 - 如果项目混用 SEH（如
__try/__except），还需额外勾选Win32 Exceptions中的C0000005等代码 - 多线程下，该设置对所有线程生效，无需逐个启用
异常发生在子线程？检查调用堆栈是否被截断
即使启用了异常中断，有时仍停在系统 DLL（如 ucrtbase.dll!raise）或空白帧，而不是你的 throw 行。这是因为线程栈未加载符号，或异常在分离线程（std::thread 未 join/未捕获）中传播时被系统回收。
实操建议：
- 确保子线程函数最外层包一层
try/catch(...)，至少输出std::current_exception()类型名，确认是否真的抛出了 - 在调试前，右键解决方案 → “属性” → “配置属性” → “C/C++” → “常规” → 将
调试信息格式设为程序数据库 (/Zi) - 启动调试后，打开“模块”窗口（
Ctrl + Alt + U），确认所有 .exe/.dll 的“符号状态”是“已加载”，否则调用堆栈无法回溯到源码
用条件断点锁定特定线程中的异常抛出点
当多个线程并发运行，且只关心某一线程（比如 ID 为 0x1a2b）抛异常时，普通断点会干扰其他线程执行节奏，甚至掩盖死锁。这时要用断点筛选器。
操作步骤：
- 在疑似
throw行左侧边距点击设断点 - 右键断点 → “断点设置” → 勾选“条件”，输入：
GetCurrentThreadId() == 0x1a2b - 注意：不能用
std::this_thread::get_id()，它返回的是std::thread::id对象，无法在断点条件中求值 - 若需更灵活匹配（如线程名），可在创建线程前调用
SetThreadDescription(GetCurrentThread(), L"Worker")，再用GetThreadDescription配合条件断点（需 Windows 10 1607+）
诊断工具窗口里的“事件”选项卡能暴露静默异常
有些异常被全局 catch 捕获后吞掉，没触发中断，但实际已影响逻辑。这类“软异常”在“诊断工具”窗口（Ctrl + Alt + F2）→ “事件”选项卡中会以 ExceptionThrown 事件形式记录，带完整线程 ID、时间戳和异常对象地址。
关键细节：
- 该事件不依赖断点设置，只要异常对象构造完成就会记录
- 双击事件可跳转到抛出位置——前提是符号已加载且 PDB 可访问
- 若看到大量
ExceptionThrown但无对应ExceptionHandled，说明有异常未被捕获，最终会触发进程终止 - 配合“并行堆栈”窗口（
Ctrl + Shift + D, H），能一眼看出哪个线程在反复抛同一类异常
throw 的是局部对象，又在子线程中未及时 catch，其析构可能发生在栈回退途中，此时调试器显示的“异常地址”可能指向已失效内存——务必优先确认异常是否被及时捕获并重抛（throw;），而非依赖事后分析。C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
