windbg exception in sos.threads on first run
Asked Answered
P

1

12

When I load a crash dump in windbg (x64), version 6.3.9600.16384, and load the sos extension for .net, the first time I run the !threads command I get this error:

c0000005 Exception in C:\Windows\Microsoft.NET\Framework64\v4.0.30319\sos.threads debugger extension.
      PC: 00007ffa`8fe6c7e3  VA: 00000000`00000000  R/W: 0  Parameter: 00000000`00000000

Subsequent times the command runs fine. Full transcript:

Loading Dump File [C:\Users\celdredge\AppData\Local\Temp\w3wp (2).DMP]
User Mini Dump File with Full Memory: Only application data is available


************* Symbol Path validation summary **************
Response                         Time (ms)     Location
Deferred                                       srv*

************* Symbol Path validation summary **************
Response                         Time (ms)     Location
Deferred                                       srv*
OK                                             c:\projects\dumps\symbols
Symbol search path is: srv*;c:\projects\dumps\symbols
Executable search path is: srv*
Windows 8 Version 9600 MP (4 procs) Free x64
Product: WinNt, suite: SingleUserTS
Built by: 6.3.9600.16384 (winblue_rtm.130821-1623)
Machine Name:
Debug session time: Tue Dec 17 23:03:00.000 2013 (UTC - 5:00)
System Uptime: 0 days 9:56:04.777
Process Uptime: 0 days 0:01:41.000
................................................................
................................................................
......................................................
ntdll!NtWaitForSingleObject+0xa:
00007ffa`a1d265ba c3              ret
0:000> .loadby sos clr
0:000> !threads
c0000005 Exception in C:\Windows\Microsoft.NET\Framework64\v4.0.30319\sos.threads debugger extension.
      PC: 00007ffa`8fe6c7e3  VA: 00000000`00000000  R/W: 0  Parameter: 00000000`00000000

CLR version:

0:000> lm v mclr
start             end                 module name
00007ffa`84450000 00007ffa`84de8000   clr        (pdb symbols)              C:\ProgramData\dbg\sym\clr.pdb\252574218A084BE3AFEFF8921ADADB6F2\clr.pdb
    Loaded symbol image file: clr.dll
    Image path: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
    Image name: clr.dll
    Browse all global symbols  functions  data
    Timestamp:        Tue Sep 10 02:54:48 2013 (522EC238)
    CheckSum:         00994334
    ImageSize:        00998000
    File version:     4.0.30319.34003
    Product version:  4.0.30319.34003

SOS version:

0:000> .chain
Extension DLL search Path:
    <snip/>
Extension DLL chain:
    C:\Windows\Microsoft.NET\Framework64\v4.0.30319\SOS.dll: image 4.0.30319.34003, API 1.0.0, built Tue Sep 10 02:44:16 2013
        [path: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\sos.dll]
    C:\Windows\Microsoft.NET\Framework64\v4.0.30319\sos: image 4.0.30319.34003, API 1.0.0, built Tue Sep 10 02:44:16 2013
        [path: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\sos.dll]
Plenty answered 18/12, 2013 at 15:10 Comment(1)
I wonder why there are two entries for SOS in the .chain output. I tried to repeat it with the same WinDbg version and CLR version but only see one entry in the output.Rabush
P
7

This seems to be a weird issue caused by saving an explicit workspace which remembers which extensions are loaded. If I .loadby sos clr and save the workspace, next time I open the workspace it will have sos loaded twice. However if I do .load c:\path\to\sos.dll and save the workspace, it only gets loaded once when I reopen it.

In summary, workspaces in windbg are confusing.

Plenty answered 20/12, 2013 at 16:28 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.