WinDbg display CLR (c#) exceptions using SOS [duplicate] - windbg

I have a .NET .86 application. I'm trying to run dumpdomain from cdb but keep getting an error.
There are a lot of questions about this, and I've tried several variations:
C:\Users\d.banks\Documents>cdb DoNothingx86.exe
Microsoft (R) Windows Debugger Version 10.0.17134.12 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
CommandLine: DoNothingx86.exe
************* Path validation summary **************
Response Time (ms) Location
Deferred srv*C:\Symbols\Microsoft
*http://msdl.microsoft.com/download/symbols
Symbol search path is: srv*C:\Symbols\Microsoft
*http://msdl.microsoft.com/download/symbols
Executable search path is:
ModLoad: 00000000`002d0000 00000000`002d8000 image00000000`002d0000
ModLoad: 00007ff8`4f790000 00007ff8`4f960000 ntdll.dll
ModLoad: 00000000`77af0000 00000000`77c73000 ntdll.dll
ModLoad: 00000000`6dda0000 00000000`6ddf2000 C:\WINDOWS\System32\wow64.dll
ModLoad: 00000000`6de10000 00000000`6de87000 C:\WINDOWS\System32\wow64win.dll
(3e64.e4c): Break instruction exception - code 80000003 (first chance)
ntdll!LdrpDoDebuggerBreak+0x30:
00007ff8`4f862cc0 cc int 3
0:000> .loadby sos.dll mscorwks
Unable to find module 'mscorwks'
0:000> .loadby sos mscorwks
Unable to find module 'mscorwks'
0:000> .loadby C:\Windows\Microsoft.NET\Framework\v4.0.30319\SOS.dll mscorwks
Unable to find module 'mscorwks'
0:000> .loadby sos.dll clr
Unable to find module 'clr'
0:000> .loadby sos clr
Unable to find module 'clr'
0:000> .loadby C:\Windows\Microsoft.NET\Framework\v4.0.30319\SOS.dll clr
Unable to find module 'clr'
0:000> .load C:\Windows\Microsoft.NET\Framework\v4.0.30319\SOS.dll
The call to LoadLibrary(C:\Windows\Microsoft.NET\Framework\v4.0.30319\SOS.dll) failed, Win32 error 0n193
"%1 is not a valid Win32 application."
Please check your debugger configuration and/or network access.
0:000> .load C:\Windows\Microsoft.NET\Framework\v4.0.30319\SOS.dll clr
The call to LoadLibrary(C:\Windows\Microsoft.NET\Framework\v4.0.30319\SOS.dll clr) failed, Win32 error 0n126
"The specified module could not be found."
Please check your debugger configuration and/or network access.
I've tried using the x86 debugger:
Microsoft (R) Windows Debugger Version 10.0.17134.12 X86
Copyright (c) Microsoft Corporation. All rights reserved.
CommandLine: DoNothingx86.exe
************* Path validation summary **************
Response Time (ms) Location
Deferred srv*C:\Symbols\Microsoft
*http://msdl.microsoft.com/download/symbols
Symbol search path is: srv*C:\Symbols\Microsoft
*http://msdl.microsoft.com/download/symbols
Executable search path is:
ModLoad: 00930000 00938000 image00930000
ModLoad: 77af0000 77c73000 ntdll.dll
ModLoad: 77900000 779e0000 WOW64_IMAGE_SECTION
ModLoad: 733c0000 73419000 C:\WINDOWS\SysWOW64\MSCOREE.DLL
ModLoad: 77900000 779e0000 C:\WINDOWS\SysWOW64\KERNEL32.dll
ModLoad: 76a00000 76ba2000 C:\WINDOWS\SysWOW64\KERNELBASE.dll
(1e98.2bb0): Break instruction exception - code 80000003 (first chance)
*** ERROR: Symbol file could not be found. Defaulted to export symbols for ntdll.dll -
eax=00000000 ebx=00000000 ecx=327c0000 edx=00000000 esi=00f326e8 edi=00bd7000
eip=77b96d5c esp=00cff2e4 ebp=00cff310 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246
ntdll!LdrInitShimEngineDynamic+0x71c:
77b96d5c cc int 3
0:000> .loadby sos.dll mscorwks
Unable to find module 'mscorwks'
0:000> .loadby sos.dll clr
Unable to find module 'clr'
0:000> .loadby sos mscorwks
Unable to find module 'mscorwks'
0:000> .loadby sos clr
Unable to find module 'clr'

From
ModLoad: 00000000`6dda0000 00000000`6ddf2000 C:\WINDOWS\System32\wow64.dll
we can see that it's a 32 bit process, so you need 32 bit SOS. 32 bit SOS only works with 32 bit WinDbg.
For loading extensions, there are 2 commands. One is .loadby, the other is .load. For .loadby use a relative path, for .load use a full path.
For .loadby, there are 5 options:
.loadby sos mscorsvr
.loadby sos mscorwks
.loadby sos clr
.loadby sos coreclr
.loadby sos <somethingelse>
where mscorsvr is really really old (.NET CLR 1, server version), mscorwks is quite old (.NET CLR 1 and 2, but still around) , clr is common today (.NET CLR 4), coreclr might be increasing (UWP and Silverlight) and <somethingelse> is annoying (look at lm and find something that looks similar but has a number attached).
The main issue is that you're trying to load SOS when the .NET runtime is not loaded yet. Wait until .NET is loaded and then the command will work. It's certainly not possible at the initial breakpoint.
Use
sxe ld clr
sxe ld mscorwks
sxe ld coreclr
g
to let the application run until .NET is available

Related

WinDbg "Failed to load data access DLL"

there is a .NET application that seems to have memory leak in the unmanaged heap. I found a promising blog that explains how to debug the unmanaged heap and trace the heap frames up to the managed functions that caused the memory allocation (https://www.deleaker.com/blog/2021/03/19/unmanaged-memory-leaks-in-dotnet/). As I'm a first time windbg user, I decided to repeat the example shown in the blog. I copypasted the code, downloaded the debug tool package and used the windbg as suggested. Here is whgere I get stuck:
Microsoft (R) Windows Debugger Version 10.0.22000.194 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
*** wait with pending attach
************* Path validation summary **************
Response Time (ms) Location
Deferred srv*
Symbol search path is: srv*
Executable search path is:
ModLoad: 00000000`00120000 00000000`00128000 C:\<MyPath>\WinDbgTest.exe
ModLoad: 00007ffe`c4c10000 00007ffe`c4e05000 C:\WINDOWS\SYSTEM32\ntdll.dll
ModLoad: 00000000`77800000 00000000`779a3000 ntdll.dll
ModLoad: 00007ffe`c3180000 00007ffe`c31d9000 C:\WINDOWS\System32\wow64.dll
ModLoad: 00007ffe`c30d0000 00007ffe`c3153000 C:\WINDOWS\System32\wow64win.dll
ModLoad: 00000000`777f0000 00000000`777fa000 C:\WINDOWS\System32\wow64cpu.dll
ModLoad: 00000000`74890000 00000000`748e2000 mscoree.dll
ModLoad: 00000000`75e50000 00000000`75f40000 KERNEL32.dll
ModLoad: 00000000`76f40000 00000000`77154000 KERNELBASE.dll
ModLoad: 00000000`756b0000 00000000`7572a000 ADVAPI32.dll
ModLoad: 00000000`75730000 00000000`757ef000 msvcrt.dll
ModLoad: 00000000`75be0000 00000000`75c55000 SECHOST.dll
ModLoad: 00000000`76610000 00000000`766d0000 RPCRT4.dll
ModLoad: 00000000`74760000 00000000`747ed000 mscoreei.dll
ModLoad: 00000000`766d0000 00000000`76715000 SHLWAPI.dll
ModLoad: 00000000`74750000 00000000`7475f000 AppCore.dll
ModLoad: 00000000`74e30000 00000000`74e38000 VERSION.dll
ModLoad: 00000000`707a0000 00000000`70f50000 clr.dll
ModLoad: 00000000`75890000 00000000`75a26000 USER32.dll
ModLoad: 00000000`774e0000 00000000`774f8000 win32u.dll
ModLoad: 00000000`705b0000 00000000`7065b000 ucrtbase_clr0400.dll
ModLoad: 00000000`70660000 00000000`70674000 VCRUNTIME140_CLR0400.dll
ModLoad: 00000000`76ec0000 00000000`76ee3000 GDI32.dll
ModLoad: 00000000`75c60000 00000000`75d3c000 gdi32full.dll
ModLoad: 00000000`76810000 00000000`7688b000 msvcp_win.dll
ModLoad: 00000000`75a30000 00000000`75b50000 ucrtbase.dll
ModLoad: 00000000`75f50000 00000000`75f75000 IMM32.dll
ModLoad: 00000000`6f180000 00000000`7058e000 mscorlib.ni.dll
ModLoad: 00000000`76060000 00000000`76143000 ole32.dll
ModLoad: 00000000`77560000 00000000`777e2000 combase.dll
ModLoad: 00000000`76e50000 00000000`76ead000 bcryptPrimitives.dll
ModLoad: 00000000`6f0f0000 00000000`6f17a000 clrjit.dll
ModLoad: 00000000`757f0000 00000000`75886000 OLEAUT32.dll
(745c.6ac0): Break instruction exception - code 80000003 (first chance)
ntdll!DbgBreakPoint:
00007ffe`c4cb0810 cc int 3
0:005> !heap -s
************************************************************************************************************************
NT HEAP STATS BELOW
************************************************************************************************************************
NtGlobalFlag enables following debugging aids for new heaps:
stack back traces
LFH Key : 0xca6fcf0f30c2eb6b
Termination on corruption : ENABLED
Heap Flags Reserv Commit Virt Free List UCR Virt Lock Fast
(k) (k) (k) (k) length blocks cont. heap
-------------------------------------------------------------------------------------
0000000001db0000 08000002 60 32 60 11 5 1 0 0
0000000000150000 08008000 64 4 64 2 1 1 0 0
-------------------------------------------------------------------------------------
0:005> !heap -stat -h 0000000001db0000
heap # 0000000001db0000
group-by: TOTSIZE max-display: 20
size #blocks total ( %) (percent of total busy bytes)
2094 1 - 2094 (48.69)
838 1 - 838 (12.28)
800 1 - 800 (11.96)
120 5 - 5a0 (8.41)
1d8 2 - 3b0 (5.51)
100 3 - 300 (4.48)
238 1 - 238 (3.32)
50 4 - 140 (1.87)
42 3 - c6 (1.16)
3c 2 - 78 (0.70)
62 1 - 62 (0.57)
48 1 - 48 (0.42)
30 1 - 30 (0.28)
28 1 - 28 (0.23)
10 1 - 10 (0.09)
4 1 - 4 (0.02)
0:005> !heap -flt s 2094
_HEAP # 1db0000
HEAP_ENTRY Size Prev Flags UserPtr UserSize - state
0000000001db10c0 020c 0000 [00] 0000000001db10f0 02094 - (busy)
unknown!printable
_HEAP # 150000
0:005> !heap -p -a 0000000001db10f0
address 0000000001db10f0 found in
_HEAP # 1db0000
HEAP_ENTRY Size Prev Flags UserPtr UserSize - state
0000000001db10c0 020c 0000 [00] 0000000001db10f0 02094 - (busy)
unknown!printable
7ffec4c3b49d ntdll!RtlpAllocateHeapInternal+0x0000000000000a7d
7ffec4c5dce1 ntdll!RtlpInitEnvironmentBlock+0x0000000000000049
7ffec4ce27c1 ntdll!LdrpInitializeProcess+0x0000000000000ba1
7ffec4c84ceb ntdll!LdrpInitialize+0x000000000000015f
7ffec4c84b73 ntdll!LdrpInitialize+0x000000000000003b
7ffec4c84b1e ntdll!LdrInitializeThunk+0x000000000000000e
0:005> .load C:\<DllPath>\WinDbgDlls\sos.dll
0:005> !ip2md 7ffec4c84b1e
Failed to load data access DLL, 0x80004005
Verify that 1) you have a recent build of the debugger (6.2.14 or newer)
2) the file mscordacwks.dll that matches your version of clr.dll is
in the version directory or on the symbol path
3) or, if you are debugging a dump file, verify that the file
mscordacwks_<arch>_<arch>_<version>.dll is on your symbol path.
4) you are debugging on supported cross platform architecture as
the dump file. For example, an ARM dump file must be debugged
on an X86 or an ARM machine; an AMD64 dump file must be
debugged on an AMD64 machine.
You can also run the debugger command .cordll to control the debugger's
load of mscordacwks.dll. .cordll -ve -u -l will do a verbose reload.
If that succeeds, the SOS command should work on retry.
If you are debugging a minidump, you need to make sure that your executable
path is pointing to clr.dll as well.
0:005> .cordll -ve -u -l
CLR DLL status: No load attempts
Everything seems to work until I call !ip2md, here comes a "Failed to load data access DLL". Following some google results I have put the clr.dll, SOS.dll and mscordacwks.dll in one folder and made sure that they all have the same bitness and the same version.
How to proceed?
Instead of loading a specific version of SOS located somewhere on your PC, let .NET decide which version to load.
Replace
.load C:\<DllPath>\WinDbgDlls\sos.dll
by
.loadby sos clr
This tells WinDbg to load the SOS extension from whatever place CLR was loaded from. This will make sure that the versions match and the DAC matches as well.
.loadby may depend on the .NET version
.loadby sos mscorwks ; *** .NET 2
.loadby sos clr ; *** .NET 4
.loadby sos coreclr ; *** Silverlight and .NET Core

How to fix “invalid access to memory location” error? - windbg

I am new to using windbg, and I am trying to set a breakpoint inside of the main function of a .net assembly that I am trying to debug, but am getting:
Unable to insert breakpoint 0 at 000001d1`4465384e, Win32 error 0n998 "Invalid access to memory location."
I have tried using bp and bu $exentry to set a break point for the entry to the program, but even that is giving me the same error. I've tried searching other old stackoverflow topics on this issue and through google, but still haven't found a solution.
Any help would be greatly appreciated.
Given a trivial .NET Console application compiled for .NET framework 4.7
using System;
namespace DebugNetMainMethod
{
class Program
{
static void Main()
{
Console.WriteLine("If you can read this, it's too late. You wanted to set a breakpoint earlier.");
Console.ReadLine();
}
}
}
you can use WinDbg Preview to debug it.
Run WinDbg Preview
Choose "Launch Executable" and select the EXE
WinDbg will stop at the initial breakpoint
ntdll!LdrpDoDebuggerBreak+0x2b:
7743ecc2 cc int 3
At this point, you get the problem you described:
0:000> bp $exentry
0:000> bl
0 e Disable Clear 007a27c6 0001 (0001) 0:**** DebugNetMainMethod!COM+_Entry_Point <PERF> (DebugNetMainMethod+0x27c6)
0:000> g
Unable to insert breakpoint 0 at 007a27c6, Win32 error 0n998
"Invalid access to memory location."
0:000> bc 0
0:000> bl
Note: In the future you want to provide exactly the information above, so everyone can reproduce your issue.
WinDbg is not made for .NET but for debugging "native code", i.e. code that was compiled for a specific processor like x86 or AMD64. WinDbg does not work well for Java, Python or .NET. However, for .NET, Microsoft provides an extension called SOS. You would typically load it like this:
0:000> .loadby sos clr
Unable to find module 'clr'
But at this early stage of debugging, not many DLLs have been loaded and the clr is still missing. So let's postpone this:
0:000> sxe ld clrjit
0:000> g
[...]
ModLoad: 72950000 729da000 C:\Windows\Microsoft.NET\Framework\v4.0.30319\clrjit.dll
[...]
0:000> .loadby sos clr
No output means it worked.
0:000> !bpmd DebugNetMainMethod Program.Main
Found 1 methods in module 00914044...
MethodDesc = 00914d5c
Adding pending breakpoints...
0:000> g
[...]
(2658.2e08): CLR notification exception - code e0444143 (first chance)
JITTED DebugNetMainMethod!DebugNetMainMethod.Program.Main()
Setting breakpoint: bp 00BA085F [DebugNetMainMethod.Program.Main()]
Breakpoint 2 hit
0:000> !clrstack
OS Thread Id: 0x2e08 (0)
Child SP IP Call Site
0075eff4 00ba085f DebugNetMainMethod.Program.Main() [C:\...\Program.cs # 8]
0075f170 63dff036 [GCFrame: 0075f170]
0:000> !u eip
Normal JIT generated code
DebugNetMainMethod.Program.Main()
Begin 00ba0848, size 32
[...]

Which version of sos and clr/mscorwks.dll to load?

I have a 32-bit application (targeting .NET 3.5) hosted on a 64-bit machine. I want to analyze the memory dump of this 32-bit application. I captured the memory dump using 32-bit adplus and cdb. I am loading the memory dump into 32-bit windbg. When I load .net 2.0 sos.dll and .net 2.0 mscorwks.dll into windbg and execute !clrstack, I get the following error: "Failed to find runtime DLL (mscorwks.dll), 0x80004005
Extension commands need mscorwks.dll in order to have something to do." What am I doing wrong?
Info as requested in the comments
ADPlus command line:
adplus -hang -quiet -p 2440 -o C:\temp
WinDbg commands:
0:000> .load <fullpathto>\sos.dll
0:000> lmvm mscorwks
start end module name
0:000> .exr -1
ExceptionAddress: 00000000
ExceptionCode: 80000007 (Wake debugger)
ExceptionFlags: 00000000
NumberParameters: 0
The dump indicates that no .NET 2 was loaded. Otherwise the output of lmvm mscorwks should show the details of the .NET runtime, like this:
0:003> lmvm mscorwks
start end module name
61bc0000 6216e000 mscorwks (deferred)
Image path: C:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll
...
File version: 2.0.50727.5485
...
You mentioned that you loaded SOS by full path. If the dump was taken on your machine, you would typically load it using
0:003> .loadby sos mscorwks
In your case, this should already give you the hint that .NET was not loaded:
Unable to find module 'mscorwks'
If you're not so sure about the .NET version, try
.loadby sos clr; *** .NET 4
.loadby sos coreclr; *** Silverlight / Universal Apps
Maybe you had a typo in your AdPlus command line and specified the wrong process ID. If that PID accidentally exists, you got a wrong dump. Use | to check the process name
0:003> |
. 0 id: 1e78 attach name: E:\...\NET2x32.exe
BTW: The -quiet parameter of ADPlus is obsolete, you can omit it.

UDK error, how to examine crash dump

I am working on a game in UDK, and sometimes the game crashes when restarting the level or trying to open a new one.
I cannot find the problem trough the log files, they are just displaying a critical error.
Now I am trying to fix it by examining the crash dump, but I do not have a clue how to do this. Does anyone have an idea how I can further investigate the problem? I tried some things that I found online and this is what I have so far.
*** ERROR: Symbol file could not be found. Defaulted to export symbols for UDK.exe -
eax=00000000 ebx=39280070 ecx=0cdc0f10 edx=ffffffff esi=2a193f40 edi=296f96a0
eip=01c2caf3 esp=007cdf84 ebp=2c0132b0 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010246
UDK!GetStackOwnerClass+0x10a73:
01c2caf3 8b10 mov edx,dword ptr [eax] ds:002b:00000000=????????
0:000> !sym noisy
noisy mode - symbol prompts on
0:000> lmvm ntdll
start end module name
77890000 77a10000 ntdll (export symbols) ntdll.dll
Loaded symbol image file: ntdll.dll
Mapped memory image file: C:\Windows\SysWOW64\ntdll.dll
Image path: C:\Windows\SysWOW64\ntdll.dll
Image name: ntdll.dll
Timestamp: Thu Aug 29 03:50:31 2013 (521EA8E7)
CheckSum: 00140982
ImageSize: 00180000
File version: 6.1.7601.18247
Product version: 6.1.7601.18247
File flags: 0 (Mask 3F)
File OS: 40004 NT Win32
File type: 2.0 Dll
File date: 00000000.00000000
Translations: 0409.04b0
CompanyName: Microsoft Corporation
ProductName: Microsoft® Windows® Operating System
InternalName: ntdll.dll
OriginalFilename: ntdll.dll
ProductVersion: 6.1.7601.18247
FileVersion: 6.1.7601.18247 (win7sp1_gdr.130828-1532)
FileDescription: NT Layer DLL
LegalCopyright: © Microsoft Corporation. All rights reserved.
The most basic analysis in WInDbg is done with
.symfix
.reload
!analyze -v
Since it crashes, there should be an exception somewhere. Try
.ecxr
.exr -1
Also the call stack is potentially interesting. Since this is about UDK (Unreal Engine Development Kit), I assume it's written in C++ and thus we need a native call stack
k

WinDBG: Unable to insert breakpoint 1 at 64b6ea43, Win32 error 0n299

I am trying to make a call to a method of a Windows COM interface from the Go language. I suspect I am doing something wrong in the way I invoke the call and would like to see how the registers change during the invocation.
But I have a hard time getting to it since I can't seem to set a breakpoint in WinDBG. The command "bu 64b6ea43" ends up not working with an error "Only part of a ReadProcessMemory or WriteProcessMemory request was completed". The full message is below.
Microsoft (R) Windows Debugger Version 6.2.8400.0 X86
Copyright (c) Microsoft Corporation. All rights reserved.
CommandLine: C:\Users\ccherng\Go\bin\error.exe
Symbol search path is: *** Invalid ***
****************************************************************************
* Symbol loading may be unreliable without a symbol search path. *
* Use .symfix to have the debugger choose a symbol path. *
* After setting your symbol path, use .reload to refresh symbol locations. *
****************************************************************************
Executable search path is:
ModLoad: 00400000 00971000 image00400000
Unable to insert breakpoint 1 at 64b6ea43, Win32 error 0n299
"Only part of a ReadProcessMemory or WriteProcessMemory request was completed."
bp1 at 64b6ea43 failed
WaitForEvent failed
eax=00415a7b ebx=7ffdd000 ecx=00000000 edx=00000000 esi=00000000 edi=00000000
eip=77b37098 esp=0006fff0 ebp=00000000 iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000200
77b37098 89442404 mov dword ptr [esp+4],eax ss:0023:0006fff4=00000000
To me it was problem because of ASLR.
running editbin /DYNAMICBASE:NO NameOfDetectedExe.exe fixed it.
Switched to Ollydbg which works. Learned that WinDbg sucks badly.