CODEWITHSUNDEEP
c++visual-studiodebuggingdumpminidump
Violet Giraffe
Violet Giraffe

Reputation: 33607

Locally generated minidump is loaded, but a remotely generated one fails to load call stack and symbols

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?

Upvotes: 1

Views: 159

Answers (1)

Dmitry Sokolov
Dmitry Sokolov

Reputation: 3190

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.

Upvotes: 1

Related Questions