花了点时间，总算有了点结果，http://user.qzone.qq.com/31731705/blog/1304480303 第一条指令被替换成了int 3。但看到的是替换后的结果，怎么样才能跟踪到替换的过程呢？ 由这个问题还引出了另一个问题，一个Exe的import table是在加载DLL的时候修改的，那怎么能跟踪这个过程呢。我发现在初始断点的时候我需要跟踪的dll已经被load了，import table里已经填充了正确的值。

第2个问题，正在看UEF的代码，确实是有些特殊处理。 第1个问题奇怪的地方是，代码只有一份，_CRT_DEBUGGER_HOOK检测当前的调试器并且VS下trigger 异常的话，这些代码应该可以被观察到的，但事实上使用windbg看不到这些代码。难道是VS加载程序的时候修改了PE文件？

windbg 自带的帮助文件。

帮助文件里有。 This alias is replaced by the name of the local variable.

看了第22章节，现在的VS中使用security cookie技术来阻止buffer overrun，总是觉得CRT的代码比较奇怪，难以理解，如下： 1. DebuggerWasPresent = IsDebuggerPresent(); 2. _CRT_DEBUGGER_HOOK(_CRT_DEBUGGER_GSFAILURE); 3. 4. SetUnhandledExceptionFilter(NULL); 5. UnhandledExceptionFilter((EXCEPTION_POINTERS *)&GS_ExceptionPointers); 6. if (!DebuggerWasPresent) 7. { 8. ...

总算明白了。内核模式下实际上还是有一份相当于全局的数据结构在起作用。 在用户态下，硬件断点是进程级别的，同时修改了所有线程的上下文。

用户模式下你应该没有问题了吧。因为断点只对当前线程有效的。 关于内核模式，我是这么理解的，内核空间只有一个，不管线程怎么切换，切换的都是用户态代码，至于为什么 “切换了线程后，为什么这个修改后的drx对后面的线程还有效”，我也有点胡涂了。:)

其实我上面解释过了，你还没有明白。 每切换一个线程都会重新加载寄存器(包括drx)，正是如此，这就是线程上下文的作用啊。 内核模式下，也有线程的概念。不过调试器可以直接写DR了，不一定非要写线程上下文了。这取决于调试器的实现。

他的问题就是为什么调试R3，是针对线程的，而R0的程序，就没有线程了。 这2个问题本质都是一样的，因为断点最终会放在DR中去，只不过前者是OS切换线程时做的，因此只对目标线程起作用。而后者可能是调试器直接做的，所以对所有线程起作用。

死锁的症状是什么样的？是CPU 100%，操作没有响应嘛？