我有一步一步的在Visual Studio .NET的多线程应用程序的调试问题2008建议调试多线程应用程序
对于每个阶梯线，Visual Studio中得到慢（它需要更多的和更多时间跳到下一行），并且通常会在几行后挂起（我得到“Visual Studio繁忙”气球提示），并且我需要停止调试。
我怀疑问题是由于应用程序有几个连接的TCP/IP客户端，这意味着每次创建断点时，其网络缓冲区都会被填充，直到我继续我的应用程序。无论何时我使用F10转到下一行代码，Visual Studio都会很快唤醒所有其他线程来处理输入数据。
有没有人有这些问题的经验，并提出如何避免这些问题的建议？
这不是一件容易的事，我相信你明白这一点。 对于由.NET Framework提供的线程和同步机制有一个清楚的了解非常重要。只有这样做后才能启动设计一个线程同步和管理。
我建议为你的线程定义明确的名称，并引入广泛的日志记录，log4net将是一个不错的选择，因为它提供了一个线程安全和强大的日志工具。
的Visual Studio提示：
查看更多在这里：Debugging Multithreaded Applications
编辑：添加更多提示
尝试找出它真正有用的应用程序逻辑状态进行手动调试和使用条件断点，如果有可能这样就可以避免调试器的额外游：
正如acoolaum指出的那样，最好使用定时日志来查看任何异常或崩溃报告。此外，您可以添加条件编译来使用不会导致任何挂断的备用路径。例如，当调试依赖于从TCP/IP获取信息的函数时，使用一个只是返回字符串而不实际执行任何TCP/IP通信的模拟函数。
有创建只为做这种嘲笑的图书馆。你可能想看看其中的一个。
这个建议可能是一个长镜头，但在这里我去了：任何机会，你试图调试的应用程序是一个WinForms应用程序，你有一个观察窗口打开？
过去，在我几乎完全停止使用Watch Windows之前，我还记得体验过慢一点的场景。如果我的断点是在非UI线程的上下文中触发的，并且观察窗口的值轮询包括UI绑定的值，那么我可以重复它，调试器将无声无息地吞噬跨线程异常，并且它会变得更慢，越来越慢，直到它无法使用。
关闭监视窗口完全摆脱了延迟。
可能是好日志会更好吗？或者尝试使用条件进行调试... – acoolaum
我使用日志记录（log4net），我通常使用单元测试来测试应用程序。但是偶尔我需要在某个地方制造一个断点。断点*可以是有条件的（如果这就是你的意思），但这并不改变这样一个事实，即在没有VS挂起的情况下，我很难执行下两行。到目前为止，我会失去自己的脾气，并在整个方法中为日志添加一堆调试，然后从那里开始工作。但是不能正确使用调试器是没有意义的。 – Groo