使用windbg时，mscorjit与mscoree重叠

Question

加载转储文件[C：\ Crash_Mode__Date_12-05-2009__Time_15-54-2727 \ PID-4056__CCNET.EXE__1st_chance_Process_Shut_Down__full_13d0_2009-12-06_00-33-14-734_0fd8.dmp] 具有完整内存的用户迷你转储文件：只有应用程序数据可用

评论：'1st_chance_Process_Shut_Down_exception_in_CCNET.EXE_running_on_TEST218' 符号搜索路径为：srv E：\ symbols http://msdl.microsoft.com/download/symbols 可执行搜索路径是：

Windows Server 2003版本3790（Service Pack 2）MP（2 procs）免费x64 产品：服务器，套件：企业TerminalServer SingleUserTS 机器名称：

调试会话时间：Sun Dec 6 00：33：14.000 2009（GMT + 8）

系统正常运行时间：32天12：43：52.414

处理正常运行时间：0天8：44：37.000

..........................警告：mscorjit与mscoree重叠

..............................警告：wldap32重叠dnsapi

..........警告：rasapi32重叠dnsapi

...警告：tapi32重叠rasapi32

。警告：rtutils与rasman重叠

..............警告：setupapi重叠winsta

... wow64cpu CpupSyscallStub + 0x9：

00000000`78b842d9 c3 ret

为什么会这样？

Answer 1

与CLR无关，而是如此处所描述的那样是64-32-http://www.dumpanalysis.org/blog/index.php/2007/09/11/crash-dump-analysis-patterns-part-26/ - 简而言之，请使用以下内容：

.load wow64exts
.effmach x86

有了这些，kb和!analyze -v会带来更好的结果。

Answer 2

我曾经看过同样的东西，我不确定，但它可能是一些WOW64神器或可能是由于一些更积极的反开发技术。在Win32上的leat，即使DLL的加载地址有时可能不同，如果DLL在其他进程中被映射（如ntdll / kernel32），当你的进程启动时，如果它也静态链接这些DLL，它将始终加载在同一地址，直到下次重启。

似乎很可能最近的CLR exe能够重新映射各个模块的执行，我知道这是MSVC10 and Windows7上的一个问题，但也许它被移植到CLR应用程序的附加平台。