1

I am trying to track down an error occurring on a target machine running Windows 7 64-bit for a C# WinForms application written in Visual Studio 2008. All I have to go on is the Windows Error Reporting output from the Event Viewer. I found a lot of helpful information here: http://www.codeilove.com/2012/09/debugging-using-windows-error-reporting.html. 

Problem signature:
P1: myprogram.exe // filename of the executable
P2: 1.44.0.0 // assembly version for the executable in P1
P3: 560be2df // assembly timestamp for the executable in P1
P4: mscorlib // assembly where the fault occurred
P5: 2.0.0.0 // assembly version for the assembly in P4
P6: 4ca2b889 // assembly timestamp for the assembly in P4
P7: c43 // token for the method where the fault occurred
P8: 59 // IL offset into the method specified in P7
P9: System.FormatException //  name of the exception that caused the fault

From the link it appears that P7, P8, and P9 are the most important, and that I should be able to find the method def for "c43" using ILDASM by looking for 06000c43. In C:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorlib.dll I find the following in System.Number:

.method /*06000C43*/ assembly hidebysig static 
    uint64  ParseUInt64(string 'value',
                        valuetype System.Globalization.NumberStyles/*020003B6*/ options,
                        class System.Globalization.NumberFormatInfo/*020003B5*/ numfmt) cil managed

Based on this information there is a System.FormatException occurring in System.Number.ParseUInt64, right? I have searched through my project in Visual Studio, and I can't find any instances where my code calls this function. Where do I go from here?

I have a top-level exception handler for Application.ThreadException that logs unhandled exceptions to a file. In this case I am getting an application crash and nothing in my log file. Is it safe to assume this Exception is happening in a thread other than my UI?

Postvmvs
  • 11
  • 5

1 Answers1

0

Starting with Vista SP1 you can configure Windows Error Reporting to collect local crash dumps. Just set registry settings on the target machine as described in that article and wait till your program crashes again. After that, check the directory that you've configured as DumpFolder. You should find a .dmp file in there. Open it in WinDbg or with Visual Studio and you should be able to see a full stack trace of where the exception happened.

Michael Domashchenko
  • 1,450
  • 9
  • 13
  • Thanks, this sounds like it is exactly what I need. Unfortunately I followed the steps in the link, yet no .dmp files are being produced when the application crashes. Could this be because I am using Visual Studio 2008? – Postvmvs Nov 10 '15 at 17:53
  • Yes, that's possible, it's probably .Net v3.5 which is different from v4.0 and up. Try `procdump -e` https://technet.microsoft.com/en-us/sysinternals/dd996900.aspx or the (more complicated) procedure from this link: http://blogs.msdn.com/b/dotnet/archive/2009/10/15/automatically-capturing-a-dump-when-a-process-crashes.aspx – Michael Domashchenko Nov 10 '15 at 18:18
  • @Postvmvs: See [this answer](http://stackoverflow.com/a/30469083/4136325) for a list of possible reasons. – Thomas Weller Nov 20 '15 at 09:12