1

I wrote a program with C# (.NET 4.0) and distribute it with the publishing assistant of C# Express.

It works fine for most of my users but one. While installing he gets an error that my application has stopped working. So he sent me the mdmp-file of this error so I can evaluate it to get the error.

The problem is, I don't know how to do this. I looked some tutorials for WINDBG up and tried to use them but they didn't help.

I also tried this topic. But I couldn't access the handles.

Is there any way I could evaluate this file so I can find out that error?

Community
  • 1
  • 1
Marco Frost
  • 780
  • 3
  • 12
  • 25
  • you probably need to do a Full dump, so it captures the state of the handle tables, so you can do a Post-mortem analysis using WinDBG, etc. Description of the difference here: http://stackoverflow.com/questions/6903329/minidump-vs-fulldump – Colin Smith Feb 12 '14 at 11:42
  • Then how do I force my application or windows to do a full dump instead of a minidump? – Marco Frost Feb 12 '14 at 11:56
  • How did you conclude you need the handle tables in the first place? There's already a lot of information in a minidump as is. What is the error you are getting? What does analyze -v tell you? And to get a complete dump, the easiest tool for the job imo is procdump from sysinternals. – Lieven Keersmaekers Feb 15 '14 at 10:22

2 Answers2

1

You probably need to do a Full (UserMode) dump, so it captures the state of the handle tables, so you can do a Post-mortem analysis using WinDBG, etc.

Description of the difference here:

If you had WinDBG installed and the crash occurred, you could use the WinDBG commands to create a dump file which contains more information e.g use the 'h' option to include "handle" information in the minidump.

Or you can use the DebugDiagnostics 1.2 tool which is slightly more customer friendly....you can get a Full User Dump to be created.

If you want to see the .NET stack frames and see other NET runtime state captured in the dump, then you need to load SOS.DLL (Son of Strike) to access that information in the dump....it is a WinDBG extension that is distributed with the .NET framework when installed on a machine.

As pointed out, you need to load the same version of the mscordacwks.dll(NET2)/cor.dll (NET4) and sos.dll that was on the originally debugged machine...this can be a pain.

There is a solution...if you set up WinDBG to point to the Microsoft Symbol Servers i.e.:

Then in theory, the mscordacwks.dll/cor.dll matching the NET version used on the target machine, will be downloaded from the symbol server if it's not already present on your machine.

Alternatively, you can avoid all those shenanigans by using PSSCOR instead...it doesn't have a tight binding to specific mscordacwks/cor.dll versions.

Load the PSSCOR2 (NET 2) or PSSCOR4 (NET 4) extensions...depending on the NET framework version your application ran under.....PSSCOR is a superset of SOS. In your case you want to load PSSCOR4 (forget about the regular SOS).

Alex
  • 633
  • 1
  • 10
  • 29
Colin Smith
  • 12,375
  • 4
  • 39
  • 47
  • Do I create the full dump out of the mini dump? Like opening the minidump in WinDBG on the machine where the crash happened or how am I supposed to do this? – Marco Frost Feb 12 '14 at 12:18
  • No you can't create a "full dump" from an existing "minidump" file...you have to create the Full dump on the process which is crashing....so on his machine. Get the Full Dump created using the tools mentioned...then with the .dmp file he gives you, then you can "open" it in WinDBG and analyze it on your machine. – Colin Smith Feb 12 '14 at 12:23
  • See here: http://stackoverflow.com/questions/734272/how-to-use-windbg-to-analyze-the-crash-dump-for-vc-application/25223024#25223024 ... for a list of useful WinDBG resources – Colin Smith Aug 09 '14 at 21:28
0

You can benefit from Windows Error Reporting (WER) configured to create local dumps. As already stated by others, you need a full dump for .NET.

Be aware that this can be several hundreds MB, instead of 1 MB for the .MDMP file. You'll need to explain how it can be sent to you.

If you have the dump, you don't necessarily need WinDbg. You can also open the dump in Visual Studio (not sure for the Express edition, though). If you can open it in Visual Studio, that might be more convenient for you.

Note that for WinDbg you also need the files mscordacwks.dll and SOS.dll from the target computer, unless it's exactly the same version as you have. They can be in various places due to the SXS feature. Maybe it's best to get them all. Just for you I have released the Mscordacwks collector preliminarily.

As a starting point for WinDbg, the following commands should help:

*** configure symbols to be downloaded from Microsoft
.symfix c:\symbols
*** Reload anything which has been loaded so far
.reload
*** Load the .NET extension, because WinDbg itself is native only
.loadby sos clr
*** Or, if the version is different to your system
.load c:\filesfromcustomer\sos.dll
*** Print exception information
!pe
*** Get the callstack
!clrstack
Thomas Weller
  • 55,411
  • 20
  • 125
  • 222
  • Thank you very much for your effort. I will try this definetly! – Marco Frost Feb 13 '14 at 14:29
  • You've linked to a MSDN page for collecting user mode dumps. However, the first paragraph clarifies that this won't work with .NET applications. I don't think that this will help me getting a full dump. – Marco Frost Feb 18 '14 at 11:56
  • @MarcoFrost: There's an if-statement in that sentence: `Applications that do their own custom crash reporting`. I think your application does not do own crash reporting. If you do, you should simply pass the correct parameter to the `MiniDumpWriteDump()` method. – Thomas Weller Feb 18 '14 at 12:13
  • @MarcoFrost: It works for .NET applications. I have instructed all our testers do make use of this feature. Any time the application crashes during a system test I get at least a crash dump, which is really helpful, because the issue is not always reproducible. – Thomas Weller Feb 18 '14 at 12:20
  • I've tried loading the .NET extension by `.loadby sos clr` but I receive the following error message `The call to LoadLibrary(C:\Windows\Microsoft.NET\Framework\v4.0.30319\sos) failed, Win32 error 0n193 "%1 ist keine zulässige Win32-Anwendung." ` So I tried your collector and loaded mscordacwks.dll and sos.dll. But then, when executing `!pe` I receive `Failed to find runtime DLL (mscorwks.dll), 0x80004005 Extension commands need mscorwks.dll in order to have something to do.` – Marco Frost Feb 18 '14 at 13:45
  • @MarcoFrost: for the first error message, it seems you have started the 64 bit version of WinDbg but your application is 32 bit. Please use the 32 bit version of WinDbg. You can install both versions of WinDbg in parallel. – Thomas Weller Feb 18 '14 at 13:49
  • @MarcoFrost: for the second error message: you said it's .NET 4.0. `mscorwks.dll` is .NET 2.0. Or does it say mscor_dac_wks? What's the output of `lm m clr` and `lm m mscorwks`? – Thomas Weller Feb 18 '14 at 13:52