mscorjit overlaps mscoree when using windbg

Question

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: srv*E:\symbols*http://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?

Answer 1

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.