既然是使用LoadLibrary来加载，那么就可能根本与.Net没有关系了，即使有关系，也可以使用WinDBG将其当作本地程序来调试。记得我跟踪过更新IAT的过程，在有符号的情况下，比较好理解，所以还是建议使用调试器来找根源。或者先写个本地的小程序来Load这个特殊的EXE看有没有问题。

根据描述，涉及两个进程是吧？无论是哪个进程发生AV，都可以使用JIT调试方法在发生AV后以JIT方式附加调试器。如果是本地程序发生AV，那么WinDBG.exe -I将WinDBG设置为JIT调试器。如果是.Net程序发生AV，那么需要产生一个netapp.exe.config文件放在同一目录中，并保有如下内容： <configuration>    <system.windows.forms jitDebugging=''true'' /></configuration> 如果确实需要调试.Net进程，那么使用WinDBG+SOS扩展模块可以很好的按照需要做本地调试和观察.Net的世界。    

可以使用Process Status API（实现在PSAPI.DLL中），其中的EnumDeviceDrivers用来获取驱动程序列表和每个驱动程序的基地址。Undocumented Windows 2000 Secrets中有详细的介绍。    

多谢，这里的确是错误，2.11节在缩减篇幅时去掉了。

调试引擎中的目标信息类（TargetInfo《软件调试》29.5 P887）实现了GetSelDescriptor方法，WinDBG的dg命令便使用了这个方法。 021f5d20 dbgeng!TargetInfo::GetSelDescriptor 020c7d40 dbgeng!LiveUserTargetInfo::GetSelDescriptor 020c68c0 dbgeng!LiveKernelTargetInfo::GetSelDescriptor 但是公开的接口和文档中并没有包含这个方法。 所以一种方法就是通过寄存器信息取到GDT的基地址，算出偏移，然后读取其中的信息，有个ProtMode扩展模块，应该就是这么做的。

不认为WinDBG会做这样的改动，你可以用另一个WinDBG做跟踪或者Ctrl+Alt+D观察WinDBG和KD之间的通信来确认。

这个问题是与CPU型号相关的。应该先通过IA32_MCG_CAP寄存器（图6-3）来检查是否实现了IA32_MCG_CTL寄存器（CTLP位），如果有才可以写。 因为修改IA32_MCG_CTL寄存器意味着可能通过异常报告硬件错误，如果软件没有很好的处理这个异常，那么可能有意外发生。这是建议软件不要轻易改变这个寄存器的初衷。这里的软件应该是指BIOS和操作系统之外的一般软件。

 better0332 wrote: 还有一问： 《在内核调试会话中设置用户态断点》 内核调试器不能捕获用户态中的异常，那它怎么能去调试用户态中的程序呢？？ 系统在分发用户态异常时会判断是否需要发给内核调试器（《软件调试》11.3.3，P287），如果需要，那么还是会发给内核调试器的。而且这是可以配置的。 配置有多种方法，比如启动参数中的/noumex，也可以使用WinDBG工具包中的kdbgctrl小程序： C:\windbg>kdbgctrlUsage: kdbgctrl <options>Options:  -c          - ...

AFAIK，目前的堆实现还不能直接支持这个特征，但是可以使用如下方法： 1）先定位到是哪个指针有这种问题。 2）在释放这个指针的地方设置一个断点。 3）断点命中，释放后，设置一个监视写操作的数据监视断点。 这样但再有代码视图写这个缓冲区时就会中断到调试器。

如果你有了基本的汇编基础，那么遇到不懂的指令，查IA-32手册的卷2（A或B）通常就够了。