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.
Related
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
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
[...]
Today I wanted to write a crash dump and I got the error message
0:000> .dump /ma c:\classid_loads_net4.dmp
Creating c:\classid_loads_net4.dmp - mini user dump
GenInvokeEnumStackProviders(C:\Windows\Microsoft.NET\Framework\v2.0.50727\mscordacwks.dll) failed, 0x8007007f
Dump successfully written
I googled for GenInvokeEnumStackProviders but there are no results at all.
What could the reason for this error message be and what impact could this have on the dump (which was successful according the last message)?
Using WinDbg 6.3.9600
Update 2014-09-18
Same error again today, reproducible at the moment. In Process Monitor I can see that WinDbg tries to access verifier.dll while writing the dump
C:\Program Files (x86)\Windows Kits\8.1\Debuggers\x86\verifier.dll
However, the file does not exist in that place. From the list of loaded modules I see it is loaded from
0:008> lm fm verifier
start end module name
6ddf0000 6de50000 verifier C:\Windows\syswow64\verifier.dll
In addition (not sure it is related) I get errors dumping the .NET heap:
0:008> !dumpheap -stat
c0000005 Exception in C:\Windows\Microsoft.NET\Framework\v2.0.50727\sos.dumpheap debugger extension.
PC: 6b55dbe8 VA: 00000000 R/W: 0 Parameter: 00000000
Still using WinDbg 6.3.9600
The problem persists, even after a reboot and after disabling application verifier.
I'm attempting to debug a manual dump file of a 64bit w3wp process with 64bit Windbg (Version 6.10). The dump was taken with taskmgr. I can't get anything from the !clrstack command. Here is what I'm getting:
!loadby sos clr
!runaway
User Mode Time
Thread Time
17:cf4 0 days 5:37:42.455
~17s
ntdll!ZwDelayExecution+0xa:
00000000`776208fa c3 ret
!clrstack
GetFrameContext failed: 1
What is GetFrameContext failed: 1?
Use !dumpstack command instead of !clrstack. It usually works.
Try getting the "native" call stack by doing "k" and see what that gets you. Sometimes, the stack isn't quite right and the !ClrStack extension is pretty sensitive.
I tried traditional ways and answers to analyze my .DMP files. WinDbg doesn`t take it, it outputs:
Could not find the C:\program files\softwaredir\dumps\dumpname_0313.rsa.dmp
File, Win32 error 0n87
It's an Multi Theft Auto: San Andreas crash dump. .rsa.dmp
Why doesn`t WinDbg take it, does it have to do with a certain dump type?
If anyone would want to try opening, here is the dumpfile with the issue
I would like to know if you have the solution to solve the opening problem/or any other tool to open the dump.
But I really need the exception that caused the crash, so either I'll need advise on how to open it or if I can fix it.
For case 2 (can't solve it for me here) the crash memory locations are:
Version 1.3.5-release 6078.0.000
Time Tue Jan 21 03:13:18 2014
Module C:\Program Files (x86)\MTA San Andreas 1.3\mods\deathmatch\client.dll
Code 0 x C0000005
Offset 0 x 0009E796
EAX 00000000 EBX 30994AB0 ECX 21E82218 EDX 0028F71C ESI 3098E520
EDI 6FBBCCC9 EBP 0028F7BC ESP 0028F6F4 EIP 1B00E796 FLG 00210246
CS 0023 DS 002B SS 002B ES 002B FS 0053 GS 002B
This is what I did to generate and analyze a dump file:
Downloaded ProcDump (a free Sysinternals tool)
Created a folder c:\dumps
Added ProcDump to PATH
Entered procdump -ma -i c:\dumps into command prompt to start the JustInTime debugger
Opened the dump file in visual studio
Using this method we were able to resolve a difficult bug and determine what exception was causing my machine to crash.