当前位置：编程学习 > C#/ASP.NET >>
答案：在上一节中简单介绍了 CLR 调试器的框架结构，其中提到 CLR 调试环境同时支持 Native 和 Managed 两种模式的调试事件。这一节将从整体上对调试事件做一个概括性的介绍。
首先看看 CLR 通过 ICorDebugManagedCallback 回调接口提供的 Managed 调试事件。这部分的调试事件可以大致分为被动调试事件和主动调试事件：前者由 CLR 在调试程序时自动引发被动调试事件，如创建一个新的线程；后者由调试器通过 CLR 的其他调试接口，控制 CLR 调试环境完成某种调试任务，并在适当的时候引发主动调试事件，如断点和表达式计算。
就被动调试事件来说，基本上对应于 CLR 载入运行程序的若干个步骤
首先是动态环境的建立，分为进程、AppDomain和线程三级，并分别有对应的建立和退出调试事件：
以下为引用：
interface ICorDebugManagedCallback : IUnknown
{
//...
HRESULT CreateProcess([in] ICorDebugProcess *pProcess);
HRESULT ExitProcess([in] ICorDebugProcess *pProcess);
HRESULT CreateAppDomain([in] ICorDebugProcess *pProcess,
[in] ICorDebugAppDomain *pAppDomain);
HRESULT ExitAppDomain([in] ICorDebugProcess *pProcess,
[in] ICorDebugAppDomain *pAppDomain);
HRESULT CreateThread([in] ICorDebugAppDomain *pAppDomain,
[in] ICorDebugThread *thread);
HRESULT ExitThread([in] ICorDebugAppDomain *pAppDomain,
[in] ICorDebugThread *thread);
HRESULT NameChange([in] ICorDebugAppDomain *pAppDomain,
[in] ICorDebugThread *pThread);
//...
};
在 CLR 的实现上，实际上是存在有物理上的 Native Thread 和逻辑上的 Managed Thread 两个概念的。进程和 Native Thread 对应着操作系统提供的相关概念，而 AppDomain 和 Managed Thread 则对应着 CLR 内部的相关抽象。上面的线程相关调试事件，实际上是 Native Thread 第一次以 Managed Thread 身份执行 Managed Code 的时候被引发的。更完整的控制需要借助后面要提及的 Native Thread 的调试事件。
此外 AppDomain 和 Managed Thread 在创建并开始运行后，都会根据情况改名，并调用 NameChange 调试事件，让调试器有机会更新界面显示上的相关信息。
其次是静态 Metadata 的载入和解析工作，也分为Assembly, Module和Class三级，并分别有对应的建立和退出调试事件：
以下为引用：
interface ICorDebugManagedCallback : IUnknown
{
//...
HRESULT LoadAssembly([in] ICorDebugAppDomain *pAppDomain,
[in] ICorDebugAssembly *pAssembly);
HRESULT UnloadAssembly([in] ICorDebugAppDomain *pAppDomain,
[in] ICorDebugAssembly *pAssembly);
HRESULT LoadModule([in] ICorDebugAppDomain *pAppDomain,
[in] ICorDebugModule *pModule);
HRESULT UnloadModule([in] ICorDebugAppDomain *pAppDomain,
[in] ICorDebugModule *pModule);
HRESULT LoadClass([in] ICorDebugAppDomain *pAppDomain,
[in] ICorDebugClass *c);
HRESULT UnloadClass([in] ICorDebugAppDomain *pAppDomain,
[in] ICorDebugClass *c);
//...
};
在 CLR 中，Assembly 很大程度上是一个逻辑上的聚合体，真正落实到实现上的更多的是其 Module。一个 Assembly 在载入时，可以只是保护相关 Manifest 和 Metadata，真正的代码和数据完全可以存放在不同地点的多个 Module 中。因此，在 Managed 调试事件中，明确分离了 Assembly 和 Module 的生命周期。
然后就是对 IL 代码中特殊指令和功能的支持用调试事件：
以下为引用：
interface ICorDebugManagedCallback : IUnknown
{
//...
HRESULT Break([in] ICorDebugAppDomain *pAppDomain,
[in] ICorDebugThread *thread);
HRESULT Exception([in] ICorDebugAppDomain *pAppDomain,
[in] ICorDebugThread *pThread,
[in] BOOL unhandled);
HRESULT DebuggerError([in] ICorDebugProcess *pProcess,
[in] HRESULT errorHR,
[in] DWORD errorCode);
HRESULT LogMessage([in] ICorDebugAppDomain *pAppDomain,
[in] ICorDebugThread *pThread,
[in] LONG lLevel,
[in] WCHAR *pLogSwitchName,
[in] WCHAR *pMessage);
HRESULT LogSwitch([in] ICorDebugAppDomain *pAppDomain,
[in] ICorDebugThread *pThread,
[in] LONG lLevel,
[in] ULONG ulReason,
[in] WCHAR *pLogSwitchName,
[in] WCHAR *pParentName);
HRESULT ControlCTrap([in] ICorDebugProcess *pProcess);
HRESULT UpdateModuleSymbols([in] ICorDebugAppDomain *pAppDomain,
[in] ICorDebugModule *pModule,
[in] IStream *pSymbolStream);
//...
};
Break 事件在执行 IL 指令 Break 时被引发，可被用于实现特殊的断点等功能；
Exception 事件在代码抛出异常时，以及异常未被处理时被引发，类似于 Win32 Debug API 中的异常事件。后面介绍调试器中对异常的处理方法时再详细介绍；
DebuggerError 事件则是在调试系统处理 Win32 调试事件发生错误时被引发；
LogMessage 和 LogSwitch 事件分别用于处理内部类 System.Diagnostics.Log 的相关功能，类似于 Win32 API 下 OutputDebugString 函数的功能，等有机会再单独写篇文章介绍相关内容；
ControlCTrap 事件响应用户使用 Ctrl+C 热键直接中断程序，等同于 Win32 API 下 SetConsoleCtrlHandler 函数的功能；
UpdateModuleSymbols 事件在系统更新某个模块调试符号库的时候被引发，使调试器有机会同步状态。
最后还省下几个主动调试事件，在调试器调用 CLR 调试接口相关功能被完成或异常时引发：
以下为引用：
interface ICorDebugManagedCallback : IUnknown
{
//...
HRESULT Breakpoint([in] ICorDebugAppDomain *pAppDomain,
[in] ICorDebugThread *pThread,
[in] ICorDebugBreakpoint *pBreakpoint);
HRESULT BreakpointSetError([in] ICorDebugAppDomain *pAppDomain,
[in] ICorDebugThread *pThread,
[in] ICorDebugBreakpoint *pBreakpoint,
[in] DWORD dwError);
HRESULT StepComplete([in] ICorDebugAppDomain *pAppDomain,
[in] ICorDebugThread *pThread,
[in] ICorDebugStepper *pStepper,
[in] CorDebugStepReason reason);
HRESULT EvalComplete([in] ICorDebugAppDomain *pAppDomain,
[in] ICorDebugThread *pThread,
[in] ICorDebugEval *pEval);
HRESULT EvalException([in] ICorDebugAppDomain *pAppDomain,
[in] ICorDebugThread *pThread,
[in] ICorDebugEval *pEval);
HRESULT EditAndContinueRemap([in] ICorDebugAppDomain *pAppDomain,
[in] ICorDebugThread *pThread,
[in] ICorDebugFunction *pFunction,
[in] BOOL fAccurate);
//...
};
Breakpoint 和 BreakpointSetError 在断点被触发或设置断点失败时被调用，下一节介绍断点的实现时再详细讨论；
StepComplete 则在调试环境因为某种原因完成了一次代码步进(step)时被调用，以后介绍单步跟踪等功能实现时再详细讨论；
EvalComplete 和 EvalException 在表达式求值完成或失败时被调用，以后介绍调试环境当前信息获取时再详细讨论；
EditAndContinueRemap 则用于实现调试时代码编辑功能，暂不涉及。
下面是一个比较直观的实例，显示一个简单的 CLR 调试环境在运行一个普通 CLR 程序除非相关调试事件的顺序
以下为引用：
ManagedEventHandler.CreateProcess(3636)
ManagedEventHandler.CreateAppDomain(DefaultDomain @ 3636)
ManagedEventHandler.LoadAssembly(e:windowsmicrosoft.net rameworkv1.1.4322mscorlib.dll @ DefaultDomain)
ManagedEventHandler.LoadModule(e:windowsmicrosoft.net rameworkv1.1.4322mscorlib.dll @ DefaultDomain)
ManagedEventHandler.NameChange(AppDomain=cordbg)
ManagedEventHandler.CreateThread(3944 @ cordbg)
ManagedEventHandler.LoadAssemb
上一个：Borland Eyeing the Chasm Between Java and .NET
下一个：CLR 调试接口的架构与应用 2 调试框架
