.NET / Rotor源码分析5 - 开始使用WinDbg+SOS调试，sscoree.dll，加载SOS并设置JIT断点

<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来调试托管代码了。如果你没有看过前两篇文章，那么请先阅读这两篇文章以对WinDbg+SOS有一个大致的了解。这两篇文章的链接在这里：

.NET Rotor源码研究4 – 修改Rotor使其发送CLR Notification：http://blog.csdn.net/ATField/archive/2007/05/21/1618535.aspx

.NET Rotor源码研究3 - 调试Rotor托管代码的利器：WinDbg和SOS：http://blog.csdn.net/ATField/archive/2007/05/12/1606151.aspx

除此之外，还需要准备一个小程序来进行调试，本文所使用的程序如下：(hello.cs)

namespace Hello

{

class Hello

{

public static void Main(string[] args)

{

System.Console.WriteLine("Your name please?");

string s = System.Console.ReadLine();

Welcome(s);

Welcome(s);

}

public static void Welcome(string name)

{

System.Console.WriteLine("Hello " + name);

}

}

}

打开命令提示符，进入sscli20目录，键入：

env dbg

进入Rotor的调试环境，如果你还没有Build出Rotor的一个Debug版本，那么请参照本系列的第一篇文章来设置你的环境并Build出一个调试版本的Rotor。文章的链接在这里：

.NET Rotor源码研究1 – Building Rotor：http://blog.csdn.net/ATField/archive/2006/12/31/1471465.aspx

如果已经Build出来了一个Rotor的x86调试版本，那么可以开始动手编译hello.cs （假定hello.cs位于binaries.x86dbg.rotor目录下）：

cd binaries.x86dbg.rotor

csc hello.cs

编译之后，启动调试器。这里我们不能直接调试hello.exe，否则.NET将会执行hello.exe，这里我们需要使用clix.exe来运行hello.exe，这样才可以让Rotor来运行hello.exe:：

windbg clix hello.exe

请保证WinDbg已经被安装并且在其路径在Path变量中。

程序的加载

启动调试器，我们停在程序加载的位置，Call Stack如下（如果你没有Windows系统DLL所对应的Symbol，那么你看到的会有所不同，这里因为有Symbol，结果更加准确）：

ntdll!DbgBreakPoint

ntdll!LdrpDoDebuggerBreak+0x31

ntdll!LdrpInitializeProcess+0xffc

ntdll!_LdrpInitialize+0xf5

ntdll!LdrInitializeThunk+0x10

在本系列的第二篇文章中曾经提到，用到PAL的程序的main实际是在PAL_startup_main，如果你还没有看到第二篇文章的话，连接在这里：

.NET Rotor源码研究2 - PAL ：http://blog.csdn.net/ATField/archive/2007/01/12/1481538.aspx

在调试器中输入：

bp clix!PAL_startup_main

g

第一条语句的作用是设置断点于clix.exe的PAL_startup_main函数，第二条语句命令WinDbg继续执行。执行g之后WinDbg很快在clix的main函数停下来，这里的main实际上就是PAL_startup_main，被#define过：

int __cdecl main(int argc, char **argv)

{

// 省略…

nExitCode = Launch(pModuleName, pActualCmdLine);

}

DWORD Launch(WCHAR* pFileName, WCHAR* pCmdLine)

{

// 省略…

nExitCode = _CorExeMain2(NULL, 0, pFileName, NULL, pCmdLine);

return nExitCode;

}

这里有不少无关的代码，大部分是分析命令行，直接来到Launch函数调用，Launch函数负责启动ModuleName，也就是hello.exe，启动工作由_CorExeMain2执行。在Windbg中F10和F11仍然可以工作（当然命令行也可以）。一路执行到_CorExeMain2然后F11，会发现来到了sscoree的_CorExeMain2函数，位于sscoree_shims.h之中：

SSCOREE_SHIM_RET (

__int32,

STDMANGLE(_CorExeMain2,20),

( PBYTE pUnmappedPE,

DWORD cUnmappedPE,

LPWSTR pImageNameIn,

LPWSTR pLoadersFileName,

LPWSTR pCmdLine),

( pUnmappedPE,

cUnmappedPE,

pImageNameIn,

pLoadersFileName,

pCmdLine),

-1)

这个函数代码很奇怪，只是一些函数调用。仔细观察一下这个头文件，发现这个文件是很有规律的由下面内容组成：

SSCOREE_LIB_START (mscorwks)

SSCOREE_SHIM_RET (

HRESULT,

STDMANGLE(MetaDataGetDispenser,12),SSCOREE_LIB_END (mscorwks)

…

…

SSCOREE_LIB_END (mscorwks)

SSCOREE_LIB_START (mscorpe)

…

SSCOREE_LIB_END (mscorpe)

SSCOREE_LIB_START (mscordbi)

…

…

这个提示我们SSCOREE.dll会负责将列表中的函数转发到对应的DLL中的对应函数。实际上，这正是sscoree.dll所起到的作用之一，确定Rotor版本，加载对应版本的Rotor，并调用对应版本的Rotor的相应函数，因此sscoree（在.NET中则是mscoree）又被称为Shim。这个SSCOREE_SHIM_RET只是一个宏定义，如下：

#define SSCOREE_SHIM_BODY(FUNC,RET_COMMAND,SIG_RET,SIG_ARGS,ARGS) \

do { \

SSCOREE_SHIM_CUSTOM_INIT \

FARPROC proc_addr = SscoreeShimGetProcAddress ( \

SHIMSYM_ ## FUNC, \

#FUNC); \

_ASSERTE (proc_addr); \

if (proc_addr) { \

RET_COMMAND ((SIG_RET (STDMETHODCALLTYPE *)SIG_ARGS)proc_addr)ARGS; \

} \

} while (0)

#define SSCOREE_SHIM_RET(SIG_RET,FUNC,SIG_ARGS,ARGS,ONERROR) \

extern "C" \

SIG_RET STDMETHODCALLTYPE FUNC SIG_ARGS \

{ \

SSCOREE_SHIM_BODY (FUNC, return, SIG_RET, SIG_ARGS, ARGS); \

return ONERROR; \

}

#define SSCOREE_SHIM_NORET(FUNC,SIG_ARGS,ARGS) \

extern "C" \

void STDMETHODCALLTYPE FUNC SIG_ARGS \

{ \

SSCOREE_SHIM_BODY (FUNC, ; ,void, SIG_ARGS, ARGS); \

}

可以看到在sscoree中每个类似_CorExeMain2的函数大致作的事情都很类似，首先调用SscoreeShimGetProcAddress获得在Rotor核心DLL中的地址，然后调用之。

回到调试器，按下F11，直接进入SscoreeShimGetProcAddress函数：

FARPROC

SscoreeShimGetProcAddress (

ShimmedSym SymIndex,

LPCSTR SymName)

{

FARPROC proc;

#ifdef TRACE_LOADS

printf ("SscoreeShimGetProcAddress: Loading Symbol %d (%s)\n",

SymIndex, g_Syms[SymIndex].Name);

#endif

_ASSERTE (SYM_INDEX_VALID (SymIndex));

_ASSERTE (SymName);

_ASSERTE (g_Syms[SymIndex].Name);

_ASSERTE (!strcmp (g_Syms[SymIndex].Name, SymName));

proc = g_Syms[SymIndex].Proc;

if (proc == NULL) {

proc = SetupProc(SymIndex, SymName);

}

return proc;

}

g_Syms是一个全局的数组，用于保存每个函数的实际地址，如果地址=NULL，说明还没有获得此函数的地址，需要调用SetupProc：

static

FARPROC

SetupProc (

ShimmedSym SymIndex,

LPCSTR SymName)

{

HMODULE lib_handle;

FARPROC proc;

ShimmedLib LibIndex = FindSymbolsLib (SymIndex);

_ASSERTE (LIB_INDEX_VALID (LibIndex));

#ifdef TRACE_LOADS

printf ("SscoreeShimGetProcAddress: Loading library %d (%S)\n",

LibIndex, g_Libs[LibIndex].Name);

#endif

lib_handle = g_Libs[LibIndex].Handle;

if (lib_handle == NULL) {

lib_handle = SetupLib (LibIndex);

if (lib_handle == NULL)

return NULL;

}

_ASSERTE (lib_handle);

proc = g_Syms[SymIndex].Proc;

if (proc == NULL) {

proc = GetProcAddress (lib_handle, SymName);

if (!proc) {

#ifdef _DEBUG

fprintf (stderr,

"SscoreeShimGetProcAddress: GetProcAddress (\"%s\") failed\n",

SymName);

#endif

return proc;

}

g_Syms[SymIndex].Proc = proc;

}

return proc;

}

FindSymbols负责找到函数和DLL之间的对应关系：

ShimmedLib

FindSymbolsLib (

ShimmedSym SymIndex)

{

// some trickery to figure out which library this symbol is in

_ASSERTE (SYM_INDEX_VALID (SymIndex));

#define SSCOREE_LIB_START(LIBNAME) \

if (SymIndex \

return LIB_ ## LIBNAME; \

} \

if (SymIndex == SHIMLIB_ ## LIBNAME) { \

return LIB_ ## MAX_LIB; \

}

#include "sscoree_shims.h"

return LIB_MAX_LIB;

}

这个函数的实现非常有意思，直接定义了两个宏然后include了sscoree_shims.h。实际上这是一个很有意思的技巧，sscoree_shims.h中以宏的形式保存了每个函数和每个DLL，这样，通过定义宏的内容，可以对同样的sscoree_shims.h中的内容转换成不同的代码，比如这里就是把这个文件转换成了一系列的if语句，判断函数Index的范围，返回DLL（这里称之为LIB）的Index，避免了重复代码。

再回到SetupProc函数，这次需要注意的SetupProc在调用FindSymbolsLib之后接着调用了SetupLib函数：

HMODULE

SetupLib (

ShimmedLib LibIndex)

{

HMODULE lib_handle;

WCHAR FullPath[_MAX_PATH];

if (!PAL_GetPALDirectory (FullPath, _MAX_PATH)) {

return NULL;

}

if (wcslen(FullPath) + wcslen(g_Libs[LibIndex].Name) >= _MAX_PATH) {

SetLastError(ERROR_FILENAME_EXCED_RANGE);

return NULL;

}

wcsncat(FullPath, g_Libs[LibIndex].Name, _MAX_PATH);

lib_handle = LoadLibrary (FullPath);

if (lib_handle == NULL) {

#ifdef _DEBUG

fprintf (stderr,

"SscoreeShimGetProcAddress: LoadLibrary (\"%S\") failed\n",

FullPath);

DisplayMessageFromSystem(GetLastError());

#endif

return lib_handle;

}

g_Libs[LibIndex].Handle = lib_handle;

#ifdef _DEBUG

// first time we've hit this library. Run some tests.

SscoreeVerifyLibrary (LibIndex);

#endif

ROTOR_PAL_CTOR_TEST_RUN(SSCOREE_INT);

return lib_handle;

}

这个函数不长，根据PAL所在目录加载对应的DLL从而实现不同版本的Rotor共存的功能，并且返回加载的DLL的Handle。这里我们所需要的DLL是mscorwks.dll，是.NET / Rotor 虚拟机的工作站（WorkStation）版本的核心DLL。

执行到wcsncat语句之后，在调试器中输入：

dv FullPath

这条命令作用是显示FullPath局部变量的值，结果为:

FullPath = wchar_t [260] "D:\usr\src\sscli20\binaries.x86dbg.rotor\mscorwks.dll"

可以看到我们需要运行mscorwks!_CorExeMain。

再度回到SetupProc，这次SetupProc调用GetProcAddress获得对应函数的地址并保存，然后返回。下面的代码就不需要继续执行了。在调试器中输入下面语句：

g mscorwks!_CorExeMain2

这条语句让WinDbg执行程序直到遇见mscorwks!_CorExeMain2函数为止：

//*****************************************************************************

// This entry point is called from the native entry piont of the loaded

// executable image. The command line arguments and other entry point data

// will be gathered here. The entry point for the user image will be found

// and handled accordingly.

//*****************************************************************************

__int32 STDMETHODCALLTYPE _CorExeMain2( // Executable exit code.

PBYTE pUnmappedPE, // -> memory mapped code

DWORD cUnmappedPE, // Size of memory mapped code

__in LPWSTR pImageNameIn, // -> Executable Name

__in LPWSTR pLoadersFileName, // -> Loaders Name

__in LPWSTR pCmdLine) // -> Command Line

{

加载SOS，设置断点

对了，现在我们还需要加载SOS，因为SOS需要mscorwks，因此在这个时候加载SOS正合适。在调试器中输入：

.loadby sos mscorwks

这条语句负责将和mscorwks在同一目录下的sos.dll作为WinDbg的Extension加载。如果你没有看到任何提示信息，那么加载成功了。如果提示出错，请检查在binaries.x86dbg.rotor目录下面确实存在SOS.dll，并且WinDbg已经被修改过或者MSVCR80D.dll在路径中，具体可以参考本系列第3篇文章：

.NET Rotor源码研究3 - 调试Rotor托管代码的利器：WinDbg和SOS：http://blog.csdn.net/ATField/archive/2007/05/12/1606151.aspx

成功加载之后，为了验证之前我们对IsDebuggerPresent的修改确实生效，输入：

!bpmd hello.exe Hello.Hello.Main

g

前一条命令是SOS命令，负责对Hello.Hello.Main函数设置断点，实际上在CLR中设置断点要比一般程序中设置断点要复杂的多，并且需要notification才可以工作，在后面我将会讲到具体的过程。后面的g命令告诉WinDbg继续执行，注意在WinDbg的输出有如下内容：

(11fc.1088): CLR notification exception - code e0444143 (first chance)

CLR notification: module 'sorttbls.nlp' loaded

(11fc.1088): CLR notification exception - code e0444143 (first chance)

(11fc.1088): CLR notification exception - code e0444143 (first chance)

CLR notification: method 'Hello.Hello.Main(System.String[])' code generated

(11fc.1088): CLR notification exception - code e0444143 (first chance)

JITTED hello!Hello.Hello.Main(System.String[])

若干CLR Notification已经发出，最重要的是最后一个notification<span

分享到：

.NET / Rotor源码分析4 - 修改Rotor使其发 ... | Visual Studio中的Class Designer设计工具 ...

• 2007-12-18 23:23
• 浏览 629
• 评论(0)
• 查看更多