使用 windbg 时 mscorjit 与 mscoree 重叠答案

【问题标题】：mscorjit overlaps mscoree when using windbg使用 windbg 时 mscorjit 与 mscoree 重叠
【发布时间】：2009-12-07 02:30:39
【问题描述】：

加载转储文件 [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 版本 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 重叠

.WARNING: rtutils 与 rasman 重叠

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

....wow64cpu!CpupSyscallStub+0x9:

00000000`78b842d9 c3 ret

为什么会这样？

【问题讨论】：

标签： windbg

【解决方案1】：

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

.load wow64exts
.effmach x86

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

【讨论】：

我也遇到过类似的问题，也和32-on-64有关。看起来标准的 64 位任务管理器总是创建 64 位内存转储，即使进程是 32 位的。对我来说，当我从 Windows\SysWOW64 开始使用任务管理器时，问题（例如重叠）消失了。

【解决方案2】：

我最近也看到过同样的东西，我不确定，但它可能是一些 WOW64 神器，或者可能是由于一些更激进的反剥削技术。至少在 Win32 上，即使 DLL 的加载地址有时可能不同，如果 DLL 在您的进程启动时映射到另一个进程（如 ntdll/kernel32），如果它也静态链接这些 DLL，它总是会加载在下一次重启之前一直在同一个地址。

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

【讨论】：