VS调试器默认在未处理异常时中断，需手动启用“Thrown”选项才能在throw处暂停；多线程下必须将try/catch置于线程函数最外层，否则抛出异常会直接调用std::terminate()。
VS调试器默认不中断在throw处，必须手动启用“Thrown”
VS默认只在未处理异常（Unhanded）时中断，也就是异常逃逸出线程入口函数后才停——这等于等程序已经崩溃了才提醒你。真正想定位问题，得让它在throw那一行就暂停。
操作路径：调试 → Windows → 异常设置（快捷键 Ctrl+Alt+E），展开 C++ Exceptions，勾选 Thrown 复选框（不只是 Unhanded）。
- 勾选
Thrown后，哪怕你写了完整的try/catch，VS 也会先中断在throw行，方便确认异常源头 - 多线程下该设置对每个线程都生效，但若异常发生在 DLL 中且 PDB 未加载，可能显示为“Unknown exception”
- 如果项目混用 C 和 C++，注意
C++ Exceptions不捕获 C 风格的longjmp或结构化异常（SEH），需单独勾选Win32 Exceptions
std::thread里加try/catch无效？因为没写在线程最顶层
常见现象：你在 std::thread 构造的 lambda 里包了一段逻辑加 try/catch，结果一抛异常还是闪退、根本进不去 catch 块。
根本原因不是语法错，而是 std::thread 的线程函数一旦抛出未被捕获的异常，会直接调用 std::terminate()——此时栈已开始销毁，catch 彻底失效。
Visual Studio 18.8.1 官方固定版本安装引导程序，当前条目使用微软发布历史中的 Professional Web Installer，适合旧项目兼容、环境回退、复现特定构建链和排查版本差异等场景。
- 必须把
try/catch写在线程函数的**最外层作用域**，不能只包住部分逻辑 - 不能依赖外层函数（比如主线程的
main）去捕获子线程异常 - 正确写法示例：
std::thread t([]{ try { risky_work(); } catch (const std::exception& e) { std::cerr << "Thread caught: " << e.what() << "\n"; } catch (...) { std::cerr << "Thread caught unknown exception\n"; } });
线程窗口冻结 + 断点过滤，避免单步时“光标乱跳”
调试多线程时按 F10/F11，光标突然跳到另一个线程的代码行——这不是 bug，是 VS 在所有中断线程间同步调试状态。要稳住焦点，得主动控制线程行为。
- 打开
调试 → 窗口 → 线程（Ctrl+Alt+H），右键当前线程选Freeze all but this，其他线程暂停执行 - 给断点加线程过滤：右键断点 →
设置 → 筛选(Filter)，填ThreadId==1234或ThreadName=="WorkerA"（线程名需提前用SetThreadDescription设置） - 配合
Ctrl+F10（运行到光标），可精准控制只在当前线程单步，不触发跨线程跳转
Parallel Stacks窗口比“调用堆栈”更能暴露死锁和阻塞
单看某个线程的调用堆栈，容易漏掉线程间的等待关系。比如一个线程卡在 WaitForSingleObject，另一个卡在 EnterCriticalSection，单开“调用堆栈”窗口看不出关联。
Parallel Stacks 窗口会把相同调用路径的线程自动分组，并用颜色/连线标出阻塞关系：
- 红色叉号表示线程被阻塞；虚线箭头指向它正在等待的线程或同步对象
- 点击任意线程块，下方“调用堆栈”窗口会立刻切换到该线程上下文
- 若看到多个线程长时间停在
std::mutex::lock或WaitForMultipleObjects，大概率是死锁或资源争抢
线程命名不是可选项——没名字的线程在 Parallel Stacks 里只显示为 Thread 1234，排查时根本分不清谁是谁。用 SetThreadDescription(GetCurrentThread(), L"SensorReader") 提前命名，能省掉一半理解成本。
