使用 Windbg 时，mscorjit 与 mscoree 重叠
加载转储文件 [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' 符号搜索路径为：srvE:\symbolshttp://msdl.microsoft .com/download/symbols 可执行搜索路径为：
Windows Server 2003 Version 3790 (Service Pack 2) MP (2 procs) Free x64 产品：服务器，套件：Enterprise 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
为什么会发生这种情况？
Loading Dump File [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]
User Mini Dump File with Full Memory: Only application data is available
Comment: '1st_chance_Process_Shut_Down_exception_in_CCNET.EXE_running_on_TEST218'
Symbol search path is: srvE:\symbolshttp://msdl.microsoft.com/download/symbols
Executable search path is:
Windows Server 2003 Version 3790 (Service Pack 2) MP (2 procs) Free x64
Product: Server, suite: Enterprise TerminalServer SingleUserTS
Machine Name:
Debug session time: Sun Dec 6 00:33:14.000 2009 (GMT+8)
System Uptime: 32 days 12:43:52.414
Process Uptime: 0 days 8:44:37.000
..........................WARNING: mscorjit overlaps mscoree
..............................WARNING: wldap32 overlaps dnsapi
..........WARNING: rasapi32 overlaps dnsapi
...WARNING: tapi32 overlaps rasapi32
.WARNING: rtutils overlaps rasman
..............WARNING: setupapi overlaps winsta
....wow64cpu!CpupSyscallStub+0x9:
00000000`78b842d9 c3 ret
why this happen?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
与 CLR 无关，而是 32-on-64，如此处所述 http://www.dumpanalysis.org/blog/index.php/2007/09/11/crash-dump-analysis-patterns-part-26/——简而言之，使用如下：
有了这些，
kb和!analyze -v将给出更好的结果。Not related to CLR, instead it's 32-on-64 as described here http://www.dumpanalysis.org/blog/index.php/2007/09/11/crash-dump-analysis-patterns-part-26/ -- in short use the following:
With those,
kband!analyze -vwill give better results.我最近也看到过同样的事情，我不确定，但这可能是一些 WOW64 工件，或者可能是由于一些更激进的反利用技术。至少在 Win32 上，即使 DLL 的加载地址有时可能不同，如果进程启动时 DLL 被映射到另一个进程（如 ntdll/kernel32），如果它也静态链接这些 DLL，它总是会加载在相同的地址，直到下次重新启动。
似乎更新的 CLR exe 能够重新映射各个模块的每次执行，我知道这是 MSVC10 和 Windows7 但也许它已被移植到 CLR 应用程序的其他平台。
I hadve seen the same thing latly, I do not know for sure but it's probably some WOW64 artifact or possibly due to some more aggressive anti-exploitation techniques. At leat on Win32, even though the load address of a DLL may be different on occasion, if a DLL is mapped in antother process (like ntdll/kernel32) when your process start's if it is statically linking these DLL's also, it would always load at the same address until the next reboot.
It seems probable that more recent CLR exe's are able to remap various module's per-execution, I know that this is an issue on MSVC10 and Windows7 but perhaps it's been ported to additonal platforms for CLR applications.