您的位置:首页 > 其它

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

2008-04-09 23:25 459 查看
在使用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
转载请注明出处

 
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: