如果一个程序跑10000次只失败一次，你会怎么调试？

CLR小组中存在着大量的回归测试，这些回归测试会定期执行来发现CLR中的Bug，Developer在Checkin之前，也需要执行这些测试的一部分（大概是10小时左右，如果全部跑的话估计要好几天）。这些测试对于保证CLR的质量是至关重要的。有时候，这些测试会偶尔失败，比如跑100次失败大概一到两次，有些极端的例子甚至是10000次才失败一次。像这种问题通常是很难调试的。在前面调试Bug的神兵利器：通过WinDbg条件断点收集Log这篇文章中，我讲到了如何通过条件断点收集各种信息来判断Bug究竟出在哪里。但是，这个方法还是不太管用，因为它不能够反复执行某个程序。下面我要讲一种技巧可以用来调试类似这样的问题，这种技巧主要适用于下面几种情况：

1. 在程序出错的时候，某些信息、状态已经丢失，无法通过当前出错时候的状态推断出之前的状态。说的稍微具体一点就是，比如某个变量变成了NULL导致Access Violation，但是很难直接推断出为什么这个变量变成了NULL
2. 程序运行时间较长，很难直接单步调试
3. 程序较难修改加入打印代码（比如加入新代码并编译非常花时间，或者该程序没有源代码
4. 该程序运行次数较多的时候才能发现问题，也就是说问题不是每次都出现

#2和#4决定了一步步调试基本上是不可能的。#1和#3则意味着我们必须得使用条件断点来收集信息来判断代码的错误，因为直接调试出错的位置是不可行的。下面了我来讲一下如何用CDB（其实就是WinDbg的无UI版本，WinDbg=CDB+UI）来做到：

1. 反复执行程序
2. 当程序出错的时候自动暂停
3. 通过条件断点收集信息，只保留出错时候的那一次Log

我们先假设我们需要调试的程序叫做Hello.exe，每次出问题的现象是，调用某个函数Hello!Func()的时候，其参数arg为NULL。Arg这个变量是由某个全局变量g_arg传入而来。我们可以通过硬件的数据断点来查看