在使用WinDbg + SOS正式跟踪Rotor的源代码研究.NET的实现之前，还有个问题需要解决：Rotor缺省并不会发出CLR Notification。CLR Notification是指CLR在运行的时候发出的一些通知，比如加载模块，代码被编译等等，这些通知对于调试Rotor / .NET以及SOS都非常重要。例如你可以设置调试器为一遇到CLR Notification便中断，在某些情况下非常有用。还有就是SOS的部分命令如BPMD等依赖于CLR notification实现其部分功能。因此这个问题必须得解决。
CLR Notifcation本质上其实就是一个SEH (Structured Exception Handling)异常。同时VC的异常以及CLR本身的托管异常也是SEH异常，只是他们的Exception Code不同和参数不同而已。CLR通过调用RaiseException函数产生Exception Code = CLR Notification的异常，这个异常并不会导致程序非正常退出，而是仅仅对调试器起到一个通知作用，CLR本身在异常处理代码中会自动处理掉这个异常。
Rotor通过间接调用DACNotificationHelper来产生CLR Notification，如下：
| void DACNotifyExceptionHelper(TADDR *args,UINT argCount) { PAL_TRY { if (IsDebuggerPresent() && !CORDebuggerAttached()) { RaiseException(CLRDATA_NOTIFY_EXCEPTION, 0, argCount, (ULONG_PTR *) args); } } PAL_EXCEPT(EXCEPTION_EXECUTE_HANDLER) { } PAL_ENDTRY } |
可以看到Rotor调用RaiseException产生代码为CLRDATA_NOTIFICATION_EXCEPTION的SEH异常，也就是CLR Notification，这个异常将被后面的PAL_EXCEPT块（类似__except）处理，不作任何事情，直接“吞掉”异常。启动调试器跟踪一下发现在if语句时候并没有对IsDebuggerPresent() API进行调用，这个函数的作用是检查进程是否被正在被调试器所调试，只有在调试器挂接上此进程并且CLR调试器没有挂接上的时候才会发生此种Notification。进一步观察汇编：
| xor eax, eax test eax,eax je mscorwks!DACNotifyExceptionHelper+0x89发现这里没有调用API而直接对eax赋值为0，然后加以判断，提示IsDebuggerPresent可能被定义成FALSE。在命令行下面输入：
发现果然IsDebuggerPresent被定义为FALSE，看来是Rotor将其禁止掉了。因为我们这里目的是对.NET / Rotor进行研究，不太在意程序的性能，因此这里只需要将这里的IsDebuggerPresent定义成TRUE重新编译即可。 修改之后重新编译，启动Windbg调试clix，运行一个托管代码程序，可以在调试器中发现类似下面的输出：
可以看到CLR Notification已经被Windbg接收到了，之后，如果想当每一个CLR Notifcation到来的时候让调试器中断，只需输入：
Clrn代表CLR Notification所对应的Exception Code，预定义在WinDbg内部。 OK，至此我们的准备工作完成，下一篇文章我们将正式使用WinDbg+SOS来调试一个托管程序在CLR中的运行过程。
作者: 张羿/ATField |
