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 Professional 18.8.1

Visual Studio 18.8.1 官方固定版本安装引导程序，当前条目使用微软发布历史中的 Professional Web Installer，适合旧项目兼容、环境回退、复现特定构建链和排查版本差异等场景。

下载

• 必须把 try/catch 写在线程函数的**最外层作用域**，不能只包住部分逻辑
• 不能依赖外层函数（比如主线程的 main）去捕获子线程异常
• 正确写法示例：

  std::thread t([]{
      try {
          risky_work();
      } catch (const std::exception& e) {
          std::cerr 

线程窗口冻结 + 断点过滤，避免单步时“光标乱跳”

调试多线程时按 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") 提前命名，能省掉一半理解成本。