VS2010中断点处冻结所有线程
我正在使用 VS2010 Beta 2 来调试一些多线程代码。喜欢并行堆栈等。
不过，我有一个问题：我在一个可能由多个线程调用的方法中设置了断点。一旦到达断点，我真的想将注意力集中在触发该断点的线程上。然而，当我点击“step”时，VS 经常切换到另一个线程（假设我在线程 1 上停止，但与此同时，线程 2 遇到了我的断点）。
我知道我可以手动冻结线程窗口中的线程。有没有一种方法可以自动执行此操作 - 基本上，一旦我遇到断点，就冻结除当前线程之外的所有线程，直到我遇到 F-5？
I'm using VS2010 Beta 2 to debug some multi-threaded code. Love parallel stacks, etc.
I have a question, though: I have a breakpoint set in a method that may be called by multiple threads. Once I hit the breakpoint, I really want to keep the focus on the thread that triggered the that breakpoint. However, when I hit "step", VS often switches to another thread (say I'm stopped on thread 1, but in the meanwhile, thread 2 hits my breakpoint).
I know that I can manually freeze threads in the thread window. Is there a way to do it automatically -- basically, once I hit a breakpoint, freeze all threads except the current one until I hit F-5?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我刚刚发布了一个 Visual Studio 2010 扩展，它完全可以满足您的需求。
而且它是免费的:)。
请访问此处的图库、官方页面或Codeplex 存储库。
I have just released a Visual Studio 2010 extension that does exactly what you are looking for.
And it's free :).
Check it out here on the Gallery, on the official page or the Codeplex repository.
如果您从“调试”->“Windows”->“线程”加载“线程”窗口。一旦遇到断点，您可以选择所有线程并单击“冻结线程”，然后您可以恢复活动线程，选择它并选择“解冻线程”。
这将只允许当前线程在调试器中执行。
If you load the Threads window from Debug->Windows->Threads.. Once you hit a break point, you can select all the threads and click "Freeze Threads" then you can resume the active thread, selecting it and choosing "Thaw threads".
This will allow only the current thread to execute in the debugger.
据我所知，但是您可以在单步执行时禁用断点。
当我担心混淆许多线程时，我倾向于保持线程窗口打开并记下线程 ID。
Not that I'm aware of, however you could disable your breakpoint while you are stepping through.
When I'm worried about confusing many threads I tend to just keep the threads window open and keep a note of the thread id's.
有一篇 博客文章作者：John Robbins，介绍如何使用 Visual Studio 宏实现此目的。
There is a blog post by John Robbins on how to do this with a Visual Studio macro.