.NET / Rotor源码分析4 - 修改Rotor使其发送CLR Notification

<iframe align="top" marginwidth="0" marginheight="0" src="http://www.zealware.com/46860.html" frameborder="0" width="468" scrolling="no" height="60"></iframe>

在使用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。在命令行下面输入：

D:\usr\src\sscli20>findstr /s "IsDebuggerPresent" *.c *.cpp *.h

binaries.x86dbg.rotor\sdk\pal\inc\rotor_palrt.h:#define IsDebuggerPresent() FALSE

clr\src\debug\ee\debugger.cpp: if (IsDebuggerPresent() && !g_pRCThread->G

etDCB(iWhich)->m_rightSideIsWin32Debugger)

clr\src\utilcode\debug.cpp: t_pDbgPres pFcn = (t_pDbgPres) GetProcAdd

ress(hKrnl32, "IsDebuggerPresent");

clr\src\vm\eeconfig.h: if (IsDebuggerPresent()) DebugBreak();

\

clr\src\vm\i386\gmsx86.cpp: if (IsDebuggerPresent())

clr\src\vm\pefile.cpp: BOOL fOutputToDebugger = (level == LL_ERROR && IsDebug

gerPresent());

clr\src\vm\stubmgr.cpp: if (IsDebuggerPresent())

clr\src\vm\util.cpp: if (IsDebuggerPresent() && !CORDebuggerAttached())

palrt\inc\rotor_palrt.h:#define IsDebuggerPresent() FALSE

发现果然IsDebuggerPresent被定义为FALSE，看来是Rotor将其禁止掉了。因为我们这里目的是对.NET / Rotor进行研究，不太在意程序的性能，因此这里只需要将这里的IsDebuggerPresent定义成TRUE重新编译即可。

修改之后重新编译，启动Windbg调试clix，运行一个托管代码程序，可以在调试器中发现类似下面的输出：

(1464.c88): CLR notification exception - code e0444143 (first chance)

First chance exceptions are reported before any exception handling.

This exception may be expected and handled.

可以看到CLR Notification已经被Windbg接收到了，之后，如果想当每一个CLR Notifcation到来的时候让调试器中断，只需输入：

sxe clrn

Clrn代表CLR Notification所对应的Exception Code，预定义在WinDbg内部。

OK，至此我们的准备工作完成，下一篇文章我们将正式使用WinDbg+SOS来调试一个托管程序在CLR中的运行过程。

作者: 张羿/ATField
Blog: http://blog.csdn.net/atfield
转载请注明出处

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1618535