在windbg时要注意sos.dll的版本

前段时间项目遇到一些问题，抓了一个dump后拿回家里的机器上分析。按着方法一步一步走，走到!clrstack的时候，问题出现了——看不到托管环境下的method name。我觉得这这!clrstack看不到method name可真没什么作用了。随后请教了几个朋友，都说没碰到过着情况。

第二天去了公司先打开windbg，open这个dump，载入sos后先来一个~*e!clrstack。邪门，method name都出来了。

从操作系统，windbg版本，symbols等几个方面都下手分析了一下，未果。问人吧，问了一圈都没有解决。问了熊力大哥，他说他可以看到，说明问题肯定不奇怪，而且肯定是某个细节的问题。挂虚拟机，测之，问题依旧，大悦，终于出问题了。

后来我把我公司机器上的sos和家里机器的sos拿过来比较，大小不一样，用!eeversion来看，版本号确实不一样。问题解决——选用合适的版本！

 

--the not work one--
0:000> .load c:\windows\microsoft.net\framework\v2.0.50727\sos.dll
0:000> !eeversion
2.0.50727.1433 retail
Workstation mode
SOS Version: 2.0.50727.3031 retail build

 

--the work one--
0:000> .load ../sos.dll
0:000> !eeversion
2.0.50727.1433 retail
Workstation mode
SOS Version: 2.0.50727.1433 retail build

 

--not work one result--
0:000> ~*e!clrstack
OS Thread Id: 0x11cc (0)
ESP       EIP    
0012f440 7c9585ec [NDirectMethodFrameStandalone: 0012f440]
0012f450 67a241d2
0012f47c 00c100a7
0012f69c 79e7c74b [GCFrame: 0012f69c]
OS Thread Id: 0x139c (1)
Unable to walk the managed stack. The current thread is likely not a
managed thread. You can run !threads to get a list of managed threads in
the process
OS Thread Id: 0x994 (2)
Failed to start stack walk: 80004005
OS Thread Id: 0xaec (3)
Failed to start stack walk: 80004005
OS Thread Id: 0xc14 (4)
Unable to walk the managed stack. The current thread is likely not a
managed thread. You can run !threads to get a list of managed threads in
the process
OS Thread Id: 0x9bc (5)
Unable to walk the managed stack. The current thread is likely not a
managed thread. You can run !threads to get a list of managed threads in
the process
OS Thread Id: 0xe3c (6)
Unable to walk the managed stack. The current thread is likely not a
managed thread. You can run !threads to get a list of managed threads in
the process
OS Thread Id: 0x11b0 (7)
ESP       EIP    
0421f654 7c9585ec [HelperMethodFrame: 0421f654]
0421f6a8 00c13f48
0421f6c4 7964a312
0421f6cc 79373ecd
0421f6e4 7940647a
0421f90c 79e7c74b [GCFrame: 0421f90c]

 

--work one result--
0:000> ~*e!clrstack
OS Thread Id: 0x11cc (0)
ESP       EIP    
0012f440 7c9585ec [NDirectMethodFrameStandalone: 0012f440] System.ServiceProcess.NativeMethods.StartServiceCtrlDispatcher(IntPtr)
0012f450 67a241d2 System.ServiceProcess.ServiceBase.Run(System.ServiceProcess.ServiceBase[])
0012f47c 00c100a7 CSDN.IM.JobTimeWindowsServices.Program.Main()
0012f69c 79e7c74b [GCFrame: 0012f69c]
OS Thread Id: 0x139c (1)
Unable to walk the managed stack. The current thread is likely not a
managed thread. You can run !threads to get a list of managed threads in
the process
OS Thread Id: 0x994 (2)
Failed to start stack walk: 80004005
OS Thread Id: 0xaec (3)
Failed to start stack walk: 80004005
OS Thread Id: 0xc14 (4)
Unable to walk the managed stack. The current thread is likely not a
managed thread. You can run !threads to get a list of managed threads in
the process
OS Thread Id: 0x9bc (5)
Unable to walk the managed stack. The current thread is likely not a
managed thread. You can run !threads to get a list of managed threads in
the process
OS Thread Id: 0xe3c (6)
Unable to walk the managed stack. The current thread is likely not a
managed thread. You can run !threads to get a list of managed threads in
the process
OS Thread Id: 0x11b0 (7)
ESP       EIP    
0421f654 7c9585ec [HelperMethodFrame: 0421f654] System.Threading.Thread.SleepInternal(Int32)
0421f6a8 00c13f48 Microsoft.Practices.EnterpriseLibrary.Common.Configuration.Storage.ConfigurationChangeWatcher.Poller(System.Object)
0421f6c4 7964a312 System.Threading.ThreadHelper.ThreadStart_Context(System.Object)
0421f6cc 79373ecd System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
0421f6e4 7940647a System.Threading.ThreadHelper.ThreadStart(System.Object)
0421f90c 79e7c74b [GCFrame: 0421f90c]

 

remember: 选用匹配的版本

 

-----------

后来为了弄清楚问题,发邮件问了Tom,他给给的回复是：

So the problem here is that we do not guarantee that newer versions of SOS will be able to debug older versions of CLR.  You must match the version of SOS to the version of the runtime (unless we are explicitly giving them private bits for SOS to fix a bug in it).  From the output below, !eeversion is telling you that the one that won’t walk the stack does not match the runtime’s version.  This is why it won’t walk the stack.
We always try to make SOS backwards compatible, but it’s not something we guarantee.

 

 

转载于:https://www.cnblogs.com/fanweixiao/archive/2008/08/06/1261577.html