有时候，当我调试一个问题的时候，我会特意忽略掉某些线程。
这个时候，有人就问了："这些线程是干什么的？你为什么知道要忽略它们？"
我的回答是：我也不清楚这些线程是干啥的，但是无论它的内部工作是什么，这都是正常的。"
博主 Tess Ferrandez 一直在编写关于 CLR 调试的系列文章，这些文章十分有用，但最为重要的一条是在调试 ASP.NET 死锁问题时该如何忽略掉不相关的部分。
在实际项目中，死锁和挂起这类问题十分难以调试，因为出现这类问题时，调试器中并没有输出异常相关的信息。程序突然之间就停止了响应，开发者不得不苦思冥想，到底哪里出错了。
出现此类问题，我们需要先有一个大概的思路，即：我们需要寻找那些"不同寻常"的东西，而为了找到这类东西，我们首先需要知道，哪些东西是正常的。
举个例子，先运行程序一段时间，然后中断到调试器，看看内存数据，线程，加载的模块等相关信息，并将这些信息记录下来。你所记录下的这些信息，就是所谓的"正常"的程序行为，就是说，当程序正常运行的时候，你所记录的就是正常的运行数据。
有了上面的记录，当程序异常的时候，再次对比下运行时数据，就有可能识别出那些不太正常的数据结构了。
当调试一个大型工程的时候，可能程序会启动非常多的线程，你不必知晓每个线程具体的工作细节。例如，当我挂接调试器到一个目标进程后，我经常会看到有一些线程会等待 RPC 对象或者是内核线程池相关的线程，说老实话，我也不清楚这些线程是干啥的，但是因为它们总是在那里悄无声息的运行着，所以，我也不会太关注它们，这些可能就是我上面所说的正常的东西。
总结
随着代码规模越来越大，诊断机制需要进一步完善，单纯通过下断点调试可能不是那么有效了，这个时候，需要结合调试输出和日志来查找问题。
最后
Raymond Chen的《The Old New Thing》是我非常喜欢的博客之一，里面有很多关于Windows的小知识，对于广大Windows平台开发者来说，确实十分有帮助。
本文来自：《Before you can learn to recognize what's wrong, you must learn to recognize what's right》
