使用WinDBG和PowerShell自动分析大量的小型转储文件
当调试代码中的一个讨厌的问题时，你能得到的最有用的东西之一就是一个小型转储。当你的应用程序在崩溃、挂起或内存开始激增时，你得到了一个很大的提示，可以开始你的探索。虽然有很多工具，比如奇妙的prodump，以及调试器自己来创建小转储，但真正的关键时刻是您必须查看这些小型转储。一个或两个很容易做到，但是如果你有200个呢？在我的工作领域，我调试别人的软件问题，我通常会面对来自客户的数百个转储。尽管我很想仔细打开每个小型垃圾场，并且一遍又一遍地输入相同的命令。
我真正需要的是这样一种方式：“这里有一堆.DMP文件；在所有这些文件中运行这些WinDBG命令。”事实证明，当你结合一点WinDBG知识和一点PowerShell魔法时，完成这项基本任务一点都不难。在开始使用脚本之前，我需要谈谈它是如何工作的。这样你就能更好地理解它的用法。
为了编写WinDBG脚本，以便它在一个文件中执行一组命令，使用$$<命令就可以做到这一点。该命令将读入一个文本文件，并依次执行每一行，就像您在命令区域中键入了它一样。您可以在WinDBG帮助中找到$$<的其他变体，它们提供了稍微不同的功能，但是这个命令对于我来说已经足够了。
如果我想运行!analyze并获取已加载模块的列表，下面的调试脚本文本文件名为，BasicAnalysis.txt，显示这些命令。星号被认为是$$<的注释行。
* Run !analyze!analyze v*Get the list of loaded modules
lmv
调试器和版本控制
“托管调试器（如Visual Studio）的哪些版本可以调试哪些版本的CLR？怎么办？”
这是调试器版本控制的基本问题。
以下是从版本控制的角度来看的“调试堆栈”，包括每个层之间的协议和进程边界：
- 用户源代码协议：
由编译器处理的源语言。---编译器/调试对象进程边界---- - 正在调试的用户应用程序。
协议：IL操作码，元数据。这些都在ECMA标准中公开定义。 - 运行应用程序的CLR。(mscorwks.dll)协议：
专用CLR调试通信。---调试对象/调试器进程边界---- - CLR调试API（ICorDebug）(mscordbi.dll)
协议：公共ICorDebug API。这是一个高版本的COM经典API。 - 调试器，如visualstudio或MDbg。
协议：任意调试器扩展接口。也可能暴露ICorDebug。 - 调试器扩展、表达式计算器等。
所以这里可能有6个不同的组件可以被版本化！
加载哪个CLR？
生成一个单独的进程，它将在一个单独的进程中执行。
加载的CLR版本由shim/loader/config策略确定。调试器在这里是不可知的，尽管它确实可以做一些事情来影响这一点，比如在启动应用程序之前放置配置文件。由于托管可执行文件是IL操作码和元数据，这些都是经过很好指定的，因此有一些版本控制选项可用于编译.NET版本X的应用程序，但在.NET版本Y上运行它。例如，为.NET 1.1编译的应用程序可以在.NET 2.0上运行。
加载哪个ICorDebug？
一旦CLR版本(mscorwks.dll)确定后，下一个问题变成：调试器加载哪个mscordbi？
我们选择在ICorDebug而不是专用协议上对调试进行版本设置：
-ICorDebug已经是一个公共的comapi，并且已经通过像QueryInterface这样的东西来进行版本控制。
-这减少了测试组合。允许混合和匹配mscorwks.dll一个武断的mscordbi.dll会产生一个不断增长的测试矩阵。如果mscordbi.dll如果需要能够调试mscorwks的多个版本，它的复杂性将不断增加。
-这使得CLR可以在私有CLR调试协议上自由创新。它的一个优点是，它允许我们调整协议的聊天时间。
结果就是mscordbi.dll必须选择以匹配的版本mscorwks.dll那是装的。这是在第一次通过CreateDebuggingInterfaceFromVersion创建ICorDebug对象时完成的。
ICorDebug
调试器通常需要是最新版本，以便能够理解它在调试对象中看到的内容。例如，在V2中添加了泛型。V1.1调试器很难在V2应用程序中看到泛型。现在，关于是否可以通过“优雅的降级”来缓解这种混乱，通常是通过：
-让调试器忽略它不理解的内容（例如，不要在调用堆栈中显示泛型方法）
-构造一个近似的V2。
有时这些技术可以奏效，但这是一个非常滑的斜坡。
这就是VS2003无法调试.NET2.0应用程序的原因。
为什么托管调试API不公开终结器线程？
这是个公平的问题。部分原因是我们不相信人们能正确地使用它。我们发现人们问的主要原因是：
1） 用户好奇心：
用户只想在调试时知道这些琐事。当调试你认为是单线程应用程序时，你会在VSThreads窗口中看到6个线程，你想知道原因。请参阅Steve关于为调试器命名线程的帖子。不幸的是，CLR没有命名终结器线程。。我认为正确的解决方法是让终结器线程的命名和其他线程命名一样工作（并修复之前出现的任何perf问题）；而不是添加一个特殊的调试器API来识别它。
2） 解决错误：
人们碰到了由终结器线程暴露的线程错误，然后希望能够识别终结器线程，以识别特殊情况下该错误的某些行为。终结器使用与其他线程相同的规则，因此线程错误（无论是在调试器中还是在常规托管应用程序中），发生在终结器线程上的线程错误也很可能发生在其他线程中。
现在根据经验，终结器的行为与主线程不同。在运行终结器之前，终结器实际上不会出现在托管代码中，这可能在任何随机时间发生。这是因为托管调试器在实际运行托管代码之前不会看到线程。由于主线程立即运行托管main（）函数，因此这不是问题。
但是，其他线程的行为可能与终结器相同。通常，本机线程可以随时进入托管代码。在MC++中，线程可以在应用程序的本地部分启动，然后调用C++编译到IL，然后再进行管理。