0

I cannot get dump files created with Task Manager (32 or 64 bit) or Process Explorer to give useful results in WinDBG or Visual Studio 2015, whereas the dump written directly from VS works brilliantly in both. I need Task Manager dumps to work so that I can analyse dump files sent by my end users.

I have reduced the problem to the simplest possible Win32 application, created in VS 2015 C++, with a deliberate NULL pointer write to cause an exception. If I run the program in VS and use Save Dump As when the exception occurs, then the dump file can be used in VS and WinDBG to see the code causing the problem. This is as expected.

However, if I run the application outside of VS, then Windows shows the usual dialog:

“Win32Project.exe has stopped working … Debug / Close Program”.

Whilst this dialog is still active I go to Task Manager 32bit and select Create Dump file. But loading this dump file into VS or WinDBG gives no useful information. In particular VS shows Exception Code as “not found”. Clicking on “Debug with Native only” causes “The application is in break mode to be shown”. See below…

I am running a new Win 10 64bit PC. DMP, PDB and EXE files are in the same directory, and I have tried endlessly with symbol directories

Visual Studio 2015 output after loading .DMP file:

Dump Summary
------------
Dump File:      Win32Project1 (4).DMP : C:\Users\Rob\AppData\Local\Temp\Win32Project1 (4).DMP
Last Write Time:    24/08/2017 16:38:27
Process Name:       Win32Project1.exe : C:\Temp\ConsoleAp2\Win32Project2\Debug\Win32Project1.exe
Process Architecture:   x86
Exception Code: not found
Exception Information:  
Heap Information:   Present

System Information
------------------
OS Version: 10.0.15063
CLR Version(s): 

Modules
-------
Module Name Module Path Module Version
----------- ----------- --------------
Win32Project1.exe   C:\Temp\ConsoleAp2\Win32Project2\Debug\Win32Project1.exe    0.0.0.0
ntdll.dll   C:\Windows\System32\ntdll.dll   10.0.15063.447
kernel32.dll    C:\Windows\System32\kernel32.dll    10.0.15063.296
...
Thomas Weller
  • 55,411
  • 20
  • 125
  • 222
drb01
  • 189
  • 1
  • 2
  • 17

2 Answers2

3

Why does that happen what you see?

It works in Visual Studio because the debugger is already attached. The debugger is informed about the exception before the process terminates. The debugger will halt the process before the Windows Error Reporting Dialog occurs and create a crash dump when the original exception is still active.

To learn more about the process on how exceptions are passed from the program to the debugger (first chance), back to the program (catch block), to the debugger again (second chance) and finally to the OS, google for the term "exception dispatching".

It does not work with Task Manager, because exception dispatching is already in its last state, which is "get handled by the OS". This makes Windows halt the program by making use of a breakpoint. It then shows that dialog. When you create a crash dump now, it's too late and it's very hard to get useful information from that crash dump.

What options do you have?

a) Windows Error Reporting

The mechanism that applies here is called Windows Error Reporting. If you had an account at Microsoft, your customer could simply click the "submit" button. You would then get some information from Microsoft. The way you ask the question makes me assume that you don't have such an account.

Then, use a feature called LocalDumps (MSDN). It's a Registry key to configure Windows to save a crash dump on disk. Make sure you understand what you need from such a dump in order to configure it correctly. In doubt, have a look at How do I take a good crash dump for .NET and use the same settings (full memory user mode mini dump). It will be good for C++ as well.

It might even be possible to activate this Registry key while the dialog is shown but I have not confirmed this any more since 2014 and I can't recommend it.

Check if your settings work by using your null pointer dereference sample application. To do so, rename your executable to the same name as your actual program.

b) Attaching a debugger

Attach a debugger to the process, then let the application continue. Press "Debug" on the dialog and confirm the message that says "a debugger is already attached". The second chance exception is thrown again, the debugger will get it and you can take a crash dump.

If you need screenshots, see my article about it

Note that in approach b) you can make many mistake which will lead to improper results. The safe way is to activate LocalDumps as described in a)

Thomas Weller
  • 55,411
  • 20
  • 125
  • 222
  • That's incredibly helpful. Unfortunately I don't have a Microsoft account, and I don't feel I can ask customers to mess with the registry, esp as it is a Japanese PC. (1) Is it possible to get the program to write the dump itself before it is too late (it is an old MFC application, not .NET)? (2) if the customer has VS installed, do they need the PDB for it to work? – drb01 Aug 24 '17 at 21:19
  • You could provide a REG file for better usability. Or you could write a small application that sets the Registry keys. For 1), it depends whether you have enough time to attach a debugger before it crashes or whether your customer would be able to run the application within debugger. Note that running the debugger first and then starting the executable inside the debugger will use a different C runtime. For 2) No, PDBs are not needed when the crash dump is taken. They are needed when the crash dump is analyzed. – Thomas Weller Aug 24 '17 at 21:23
1

I recommend giving ProcDump from Windows Sysinternals a shot. You can set it to capture a dump of your app when it crashes, or set it as the Just-in-Time debugger and have it write a dump for any app crash.

See the documentation and examples in the above website for more detail.

label
  • 11
  • 5