1

My Windows application uses SEH and SetUnhandledExceptionFilter to create a minidump upon crash. I have already successfully used it for debugging segmentation faults that occur on the client side. I. e. I get a dump, build the same version of the program locally as the one that produced the dump, open it and can see some call stack entries and sources.

However, now I've got a dump that's been caused by std::exception rather than a segfault. In addition to the SEH handler, I also have a plain C++ catch block that looks like this:

catch (std::exception& e)
{
    Logger() << "std::exception caught:" << e.what();
    throw;
}

The minidump is generated for exceptions just as well. When generated locally, it can be opened and I immediately see where the exception has been thrown - PDBs are loaded, call stack is available, sources are also loaded. BUT, when I open the remotely generated dump, I get almost nothing. The only callstack entry is KERNELBASE.dll!_RaiseException@16(), no sources are loaded etc. And the weird part is that the Visual Studio's UI is different for exception dump and for segfault dump. When loading a segfault dump, it usually says that such and such .pdb can't be located; I can browse for it and load everything after. With the exception dump, there's literally no way to do that.

So, how can I load my minidump and see the exception occurrence site?

Violet Giraffe
  • 32,368
  • 48
  • 194
  • 335
  • While in debugging, you can verify you have the correct symbols and executable by using the _Debug/Windows/Modules_ menu item. It will display a dialog with the module statuses. – rrirower Apr 16 '15 at 12:19

1 Answers1

1

Try to rebuild your application, keep .pdb files, and supply your client with this application. When a new crash will occur, examine a dumpfile with thees saved .pdb files.

In a nutshell, you should keep all .pdb files for every version of an application that you supply. Such thing like SymStore was invented for that purpose.

Dmitry Sokolov
  • 3,118
  • 1
  • 30
  • 35
  • I've tested that this works (by running the program on another computer). But I don't see how my initial scenrario (reverting the source code to that release version via a version control system, and re-building it) is different. Why can't I load the minidump? Storing PDBs is quite expensive in terms of disk space. – Violet Giraffe Apr 16 '15 at 12:38
  • [Debugging with Symbols - How symchk Works](https://msdn.microsoft.com/en-us/library/windows/desktop/ee416588%28v=vs.85%29.aspx#how_symchk_works). – Dmitry Sokolov Apr 16 '15 at 14:05
  • You can try to alter reverted from source code .pdb files [1](http://stackoverflow.com/questions/3660084/is-it-possible-to-load-mismatched-symbols-in-visual-studio), [2](http://stackoverflow.com/questions/744870/how-can-you-change-an-age-mismatched-pdb-to-match-properly). – Dmitry Sokolov Apr 16 '15 at 14:07
  • Hmm. My binaries are being digitally signed after linking, which explains why symbols fail to load. But it doesn't explain why I still can load everything from a segfault dump, but not exception dump. – Violet Giraffe Apr 17 '15 at 08:24
  • Thanks for the links. I've used chkmatch to make the old binaries (the exact binaries the dump was produced by) match the newly built .pdbs from the same source. But I still can't load the symbols. This is all I see in Visual Studio: http://i.imgur.com/tNTBokQ.png – Violet Giraffe Apr 17 '15 at 10:01
  • Think I found it. The link you named "2" describes the problem and the solution. I intend to write a tool that will automatically patch the PDB's age to match that of a binary, let's see if that helps. – Violet Giraffe Apr 17 '15 at 11:37
  • Nope, it doesn't work. I have created a tool that does everything described here, and still age mismatch http://stackoverflow.com/a/12246955/634821 – Violet Giraffe Apr 23 '15 at 13:28
  • @VioletGiraffe: code signing (with a certificate) does not affect the DLLs matching to PDBs. Though PDBs are large, IMHO they compress quite well and disk storage is cheap. No need to delete PDBs. Given the amount of time you spend now to find the old source, rebuild the symbols etc. is it worth it? – Thomas Weller May 27 '15 at 19:51
  • @ThomasWeller: storage is not the only consideration. If I just need to build the correct source revision, I can do that on any PC - at work, on my home desktop, on my home laptop... On the other hand, if I must keep the original PDBs, I'd need to make them accessible online if I had to work with them from home. Finding the right source is 30 seconds of interacting with the version control system, building is another 2.5 minutes. Yes, it's totally worth it - just for the ease of use, if nothing else. – Violet Giraffe May 28 '15 at 07:47
  • @VioletGiraffe: depends on what you need to build. I need several licenses (DevExpress, PostSharp, ...), a special build environment (e.g. Visual Studio) etc. That's also not available on very PC. Setting up any PC to make it build takes about 1 day. Well, I wish you good luck with your approach, can't help you any further with it. – Thomas Weller May 28 '15 at 18:28
  • @ThomasWeller: sure, it depends on your project. Mine - you just clone and build on any PC with VS 2013. I've applied some effort making it build-able from freshly cloned repository on any computer. – Violet Giraffe May 28 '15 at 18:57