Note that a managed dump cannot view the managed call stack.

My friend asked me to help me see a dump. I opened it and found a strange problem.

 

Use the command "~ * E! Clrstack "to view the managed call stacks of all threads, it is said that all threads are not managed threads.

0: 045> ~ * E! Clrstack
OS Thread Id: 0x16d4 (0)
Unable to walk the managed stack. The current thread is likely not
Managed thread. You can run! Threads to get a list of managed threads in
The process
OS Thread Id: 0x260c (1)
Unable to walk the managed stack. The current thread is likely not
Managed thread. You can run! Threads to get a list of managed threads in
The process

 

Use "~ * E k "clearly shows the following call Stack:

Child-SP RetAddr Call Site
00000000 '02baf698 000007fe 'fd2010ac ntdll! NtWaitForSingleObject + 0xa
00000000 '02baf6a0 000007fe 'f4cc9b96 KERNELBASE! WaitForSingleObjectEx + 0x79
00000000 '02baf740 000007fe 'f4cc9a9f mscorwks! CLREventWaitHelper + 0x42 [f: \ dd \ ndp \ clr \ src \ vm \ synch. cpp @ 699]
00000000 '02baf7a0 000007fe 'f4cc97fbMscorwks! CLREvent: WaitEx + 0x63 [f: \ dd \ ndp \ clr \ src \ vm \ synch. cpp @ 798]
00000000 '02baf850 000007fe 'f4cba44a mscorwks! ThreadpoolMgr: SafeWait + 0x7b [f: \ dd \ ndp \ clr \ src \ vm \ win32threadpool. cpp @ 3042]
00000000 '02baf910 000007fe 'f4d1095cMscorwks! ThreadpoolMgr: WorkerThreadStart + 0x11a [f: \ dd \ ndp \ clr \ src \ vm \ win32threadpool. cpp @ 2721]
00000000 '02baf9b0 00000000 '76f8f56d mscorwks! Thread: intermediateThreadProc + 0x78 [f: \ dd \ ndp \ clr \ src \ vm \ threads. cpp @ 3060]
00000000 '02bafb80 00000000 '771c3281 kernel32! BaseThreadInitThunk + 0xd
00000000 '02bafbb0 00000000 '00000000 ntdll! RtlUserThreadStart + 0x1d

 

 

Note that mscorwks is a managed module.

 

After asking a colleague, I got a response: "This is a known question." You can run the "lmvm clr" command to check whether the output result contains information of. net framework 4.0.

0: 045> lmvm clr
Start end module name
000007fe 'f96a0000 000007fe 'fa005000 clr (pdb symbols) d: \ symcache \ clr. pdb \ 0A821B8A573E42899202851DF6A539F12 \ clr. pdb
Loaded symbol image file: clr. dll
Image path: C: \ Windows \ Microsoft. NET \ Framework64 \ v4.0.30319 \ clr. dll
Image name: clr. dll
Timestamp: Thu Mar 18 20:39:07 2010 (4BA21EEB)
CheckSum: 00959DBD
ImageSize: 00965000
File version: 4.0.30319.1
Product version: 4.0.30319.1
File flags: 8 (Mask 3F) Private
File OS: 4 Unknown Win32
File type: 2.0 Dll
File date: 00000000.00000000
Translations: 0409.04b0
CompanyName: Microsoft Corporation
ProductName: Microsoft. NET Framework
InternalName: clr. dll
OriginalFilename: clr. dll
ProductVersion: 4.0.30319.1
FileVersion: 4.0.30319.1 (rtmrel%30319-0100)
PrivateBuild: DDBLD431
FileDescription: Microsoft. NET Runtime Common Language Runtime-WorkStation
LegalCopyright: Microsoft Corporation. All rights reserved.
Comments: Flavor = Retail

 

As shown above, this dump contains. net framework 4.0. What needs to be viewed in this dump is. net 2.0 application problems, therefore, in this dump, contains the 2.0 and 4.0 versions of the framework. so WinDBG is confuse, and I don't know which version of mscordacwks dll to load.

 

Solution

====================

Run the ". cordll-ve-u-I mscorwks-l" command"

0: 045>. cordll-ve-u-I mscorwks-l
CLRDLL: C: \ Windows \ Microsoft. NET \ Framework64 \ v2.0.50727 \ mscordacwks. dll: 2.0.50727.4952 f: 0
Doesn't match desired version 2.0.50727.4927 f: 0
DBGHELP: d: \ symcache \ mscordacwks_amd64_amd64_2.0.50727.1097.dll \ 4A27466F9ae000 \ mscordacwks_amd64_amd64_2.0.50727.20.7.dll-OK
CLRDLL:Loaded DLL d: \ symcache \ mscordacwks_amd64_amd64_2.0.50727.4247.dll\ 4A27466F9ae000 \ mscordacwks_amd64_amd64_2.0.50727.1097.dll
Clr dll status: Loaded DLL d: \ symcache \ mscordacwks_amd64_amd64_2.0.50727.1097.dll \ 4A27466F9ae000 \ mscordacwks_amd64_amd64_2.0.50727.20.7.dll

 

Let's look at the managed call stack in the dump to solve the problem.