.loadby sos clr - specified module could not be found

C

3

5

I am trying to get to the bottom of what the CLR exception that is in my dump file but I am having an issue trying to execute:

0:000> .loadby sos clr
The call to LoadLibrary(C:\ProgramData\dbg\sym\clr.dll\5348A1EF9a0000\sos) failed, Win32 error 0n126
    "The specified module could not be found."

I tried to look at what is loaded and I see:

0:000> lm
start             end                 module name
00000000`00190000 00000000`001a4000   MyTest   (deferred)             
00000000`77a00000 00000000`77afa000   user32     (deferred)             
00000000`77b00000 00000000`77c1f000   kernel32   (pdb symbols)          C:\ProgramData\dbg\sym\kernel32.pdb\CEE1211DAF10494CAFDDBE2C4232EAE82\kernel32.pdb
00000000`77c20000 00000000`77dca000   ntdll      (pdb symbols)          C:\ProgramData\dbg\sym\ntdll.pdb\8AAAEEE259C340FCADC53FAF9FEF22E92\ntdll.pdb
000007fe`f8950000 000007fe`f9ef1000   mscorlib_ni   (deferred)             
000007fe`f9f00000 000007fe`f9fd6000   MSVCR120_CLR0400   (deferred)             
000007fe`f9fe0000 000007fe`fa980000   clr        (pdb symbols)          C:\ProgramData\dbg\sym\clr.pdb\E3E0C76A7909454FB3C56B0C2CE5FFEB2\clr.pdb
000007fe`fa980000 000007fe`faa1d000   mscoreei T (pdb symbols)          C:\ProgramData\dbg\sym\mscoreei.pdb\6D65F80ABA3D403D8F6F7214972B9BBF2\mscoreei.pdb
000007fe`faa20000 000007fe`faa8f000   mscoree    (deferred)             
000007fe`fd800000 000007fe`fd80f000   CRYPTBASE   (deferred)             
000007fe`fdbb0000 000007fe`fdc1a000   KERNELBASE   (pdb symbols)          C:\ProgramData\dbg\sym\kernelbase.pdb\D396875654E9416CBA16E51F8B0A8B1E2\kernelbase.pdb
000007fe`fdd60000 000007fe`fde69000   msctf      (deferred)             
000007fe`fde70000 000007fe`fe073000   ole32      (deferred)             
000007fe`fe0b0000 000007fe`fe121000   shlwapi    (deferred)             
000007fe`fe310000 000007fe`fe3da000   usp10      (deferred)             
000007fe`fe3e0000 000007fe`fe47f000   msvcrt     (deferred)             
000007fe`fe480000 000007fe`fe48e000   lpk        (deferred)             
000007fe`fe590000 000007fe`fe5af000   sechost    (deferred)             
000007fe`fe600000 000007fe`fe62e000   imm32      (deferred)             
000007fe`fe630000 000007fe`fe697000   gdi32      (deferred)             
000007fe`fe910000 000007fe`fe9eb000   advapi32   (deferred)             
000007fe`ff800000 000007fe`ff92d000   rpcrt4     (deferred)

Looking more at the clr:

0:000> lmvm clr
Browse full module list
start             end                 module name
000007fe`f9fe0000 000007fe`fa980000   clr        (pdb symbols)          C:\ProgramData\dbg\sym\clr.pdb\E3E0C76A7909454FB3C56B0C2CE5FFEB2\clr.pdb
    Loaded symbol image file: clr.dll
    Mapped memory image file: C:\ProgramData\dbg\sym\clr.dll\5348A1EF9a0000\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:        Fri Apr 11 22:16:15 2014 (5348A1EF)
    CheckSum:         009A762B
    ImageSize:        009A0000
    File version:     4.0.30319.34209
    Product version:  4.0.30319.34209
    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.34209
    FileVersion:      4.0.30319.34209 built by: FX452RTMGDR
    PrivateBuild:     DDBLD104
    FileDescription:  Microsoft .NET Runtime Common Language Runtime - WorkStation
    LegalCopyright:   © Microsoft Corporation.  All rights reserved.
    Comments:         Flavor=Retail

And then as per suggestion from @Thomas Weller:

0:000> lmf m clr
Browse full module list
start             end                 module name
000007fe`f9fe0000 000007fe`fa980000   clr      C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll

The path (C:\Windows\Microsoft.NET\Framework64\v4.0.30319) exists on my PC and there's a SOS.dll inside.

Additional information:

ld clr; .reload /f does not help
I've not used .cordll to modify the CLR loading paths
.load C:\Windows\Microsoft.NET\Framework64\v4.0.30319\SOS.dll works, but it's longer to type

Why is .loadby sos clr not working for me? (I just installed WinDbg from https://developer.microsoft.com/en-us/windows/hardware/windows-driver-kit) by selecting to install "Debugging Tools for Windows" from the installer)

Cramfull answered 10/8, 2016 at 13:23 Comment(2)

I'd not like to put .load as an answer, because it's just a workaround and does not explain why it happens and how to prevent it from happening. – Falcongentle 10/8, 2016 at 14:27

"Mapped memory image file" appears to be the problem. I'd guess that the CLR version on the machine that created the minidump isn't the same one as on your machine. So you got the correct version from somewhere, I can't guess how that ended up in c:\programdata. The sos.dll version need to match the clr.dll version so using .load isn't exactly guaranteed to be a workaround. – Leelah 10/8, 2016 at 16:7

C

5

Figured out the answer using what I learned from @Thomas Weller's questions. So apparently the "Symbol File Path" in File -> Symbol File Path gets cleared every time you close WinDbg and without it .loadby sos clr produces the error that I got. The "Symbol File Path" in File -> Symbol File Path must have an entry in there like: srv*C:\windbg\websymbols (and of course the directory must exist).

When you open a crash dump it should have the following output (Notice the line: Symbol search path is: srv*C:\windbg\websymbols):

Microsoft (R) Windows Debugger Version 10.0.14321.1024 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Users\XXXXXX\Desktop\AppCrash_XXXXXXXXXXXXX_d4c077fd50acba44bd2aceb966fe5424b98f3e_cab_9eb7d2f5\WERC4D4.tmp.hdmp]
User Mini Dump File: Only registers, stack and portions of memory are available


************* Symbol Path validation summary **************
Response                         Time (ms)     Location
Deferred                                       srv*C:\windbg\websymbols
Symbol search path is: srv*C:\windbg\websymbols
Executable search path is: 
Windows 7 Version 7601 (Service Pack 1) MP (4 procs) Free x64
Product: Server, suite: TerminalServer SingleUserTS
Machine Name:
Debug session time: Tue Aug  9 02:05:43.000 2016 (UTC - 4:00)
System Uptime: 79 days 17:08:17.121
Process Uptime: 0 days 0:00:06.000

On the other hand, this is what I had previously and this means you forgot to set the "Symbol File Path" (Notice the line Symbol search path is: srv*)

Microsoft (R) Windows Debugger Version 10.0.14321.1024 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Users\XXXXXX\Desktop\AppCrash_XXXXXXXXXXXXX_d4c077fd50acba44bd2aceb966fe5424b98f3e_cab_9eb7d2f5\WERC4D4.tmp.hdmp]
User Mini Dump File: Only registers, stack and portions of memory are available

Symbol search path is: srv*
Executable search path is: 
Windows 7 Version 7601 (Service Pack 1) MP (4 procs) Free x64
Product: Server, suite: TerminalServer SingleUserTS
Machine Name:
Debug session time: Tue Aug  9 02:05:43.000 2016 (UTC - 4:00)
System Uptime: 79 days 17:08:17.121
Process Uptime: 0 days 0:00:06.000

Cramfull answered 10/8, 2016 at 15:29 Comment(5)

Isn't there some way to save the "Symbol File Path" setting? I know I'm going to hit this again in a few months when I have to use WinDbg again... – Cramfull 10/8, 2016 at 15:37

Perhaps you can set the _NT_SYMBOL_PATH env. variable as explained here. But IIRC, WinDbg should ask you if you want to save settings to the default workspace? – Nalor 10/8, 2016 at 15:44

Are you sure that the symbol path is the cause? I wonder why .loadby would work with the symbol path, because it should use the path of the module (the DLL) and not the symbols (PDB file) – Falcongentle 10/8, 2016 at 16:11

@Groo: using _NT_SYMBOL_PATH may have side effects, e.g. on Process Explorer and Visual Studio, which one might want to avoid. Using a workspace is certainly a good approach or using a link calling WinDbg with the -y option. – Falcongentle 10/8, 2016 at 16:12

@ThomasWeller, I am not sure why it works but it definitely fixed the problem. Also seems that if you create a Workspace in WinDbg and name it "Default" it automatically loads when you open WinDbg so that'll work. – Cramfull 10/8, 2016 at 17:38

C

15

As mentioned by @Thomas Weller this workaround works for now:

.load C:\Windows\Microsoft.NET\Framework64\v4.0.30319\SOS.dll

Cramfull answered 10/8, 2016 at 14:36 Comment(0)

C

5

Figured out the answer using what I learned from @Thomas Weller's questions. So apparently the "Symbol File Path" in File -> Symbol File Path gets cleared every time you close WinDbg and without it .loadby sos clr produces the error that I got. The "Symbol File Path" in File -> Symbol File Path must have an entry in there like: srv*C:\windbg\websymbols (and of course the directory must exist).

When you open a crash dump it should have the following output (Notice the line: Symbol search path is: srv*C:\windbg\websymbols):

Microsoft (R) Windows Debugger Version 10.0.14321.1024 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Users\XXXXXX\Desktop\AppCrash_XXXXXXXXXXXXX_d4c077fd50acba44bd2aceb966fe5424b98f3e_cab_9eb7d2f5\WERC4D4.tmp.hdmp]
User Mini Dump File: Only registers, stack and portions of memory are available


************* Symbol Path validation summary **************
Response                         Time (ms)     Location
Deferred                                       srv*C:\windbg\websymbols
Symbol search path is: srv*C:\windbg\websymbols
Executable search path is: 
Windows 7 Version 7601 (Service Pack 1) MP (4 procs) Free x64
Product: Server, suite: TerminalServer SingleUserTS
Machine Name:
Debug session time: Tue Aug  9 02:05:43.000 2016 (UTC - 4:00)
System Uptime: 79 days 17:08:17.121
Process Uptime: 0 days 0:00:06.000

On the other hand, this is what I had previously and this means you forgot to set the "Symbol File Path" (Notice the line Symbol search path is: srv*)

Microsoft (R) Windows Debugger Version 10.0.14321.1024 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Users\XXXXXX\Desktop\AppCrash_XXXXXXXXXXXXX_d4c077fd50acba44bd2aceb966fe5424b98f3e_cab_9eb7d2f5\WERC4D4.tmp.hdmp]
User Mini Dump File: Only registers, stack and portions of memory are available

Symbol search path is: srv*
Executable search path is: 
Windows 7 Version 7601 (Service Pack 1) MP (4 procs) Free x64
Product: Server, suite: TerminalServer SingleUserTS
Machine Name:
Debug session time: Tue Aug  9 02:05:43.000 2016 (UTC - 4:00)
System Uptime: 79 days 17:08:17.121
Process Uptime: 0 days 0:00:06.000

Cramfull answered 10/8, 2016 at 15:29 Comment(5)

Isn't there some way to save the "Symbol File Path" setting? I know I'm going to hit this again in a few months when I have to use WinDbg again... – Cramfull 10/8, 2016 at 15:37

Perhaps you can set the _NT_SYMBOL_PATH env. variable as explained here. But IIRC, WinDbg should ask you if you want to save settings to the default workspace? – Nalor 10/8, 2016 at 15:44

Are you sure that the symbol path is the cause? I wonder why .loadby would work with the symbol path, because it should use the path of the module (the DLL) and not the symbols (PDB file) – Falcongentle 10/8, 2016 at 16:11

@Groo: using _NT_SYMBOL_PATH may have side effects, e.g. on Process Explorer and Visual Studio, which one might want to avoid. Using a workspace is certainly a good approach or using a link calling WinDbg with the -y option. – Falcongentle 10/8, 2016 at 16:12

@ThomasWeller, I am not sure why it works but it definitely fixed the problem. Also seems that if you create a Workspace in WinDbg and name it "Default" it automatically loads when you open WinDbg so that'll work. – Cramfull 10/8, 2016 at 17:38

L

1

WER generated 2 files in my case: triagedump.dmp (2 MiB) and memory.hdmp (400 MiB).

triagedump.dmp contains only exception info, SOS does not work with it.

memory.hdmp is minidump, SOS loaded CLR successfully.

Localize answered 16/2, 2017 at 21:29 Comment(0)

Recommended topics

Hot tags