A program I support is crashing with SIGSEGV but I can't from the .dmp file

Question

As per the title, I can't locate any dump files when this program I support is crashing.

The application's logs clearly mention its a SIGSEGV exception, but I have searched my entire hard drive, and there are no .dmp files anywhere to be found.

The developers of the program have seen similar issues elsewhere but have so far been unable to explain why this is happening - and we're kind of a bit stuck at the moment.

The last section in the application logs reads as :

Received signal SIGSEGV, segmentation violation.
OurApplication::sigHandler 11.
Removing signal handlers.
OurApplication::signalCatched.
OurApplication::sigHandler: exiting application.
Removing signal handlers.

My limited understanding of this is that our application's signal handler might be 'neutralising' the SIGSEGV exception that got thrown. And therefore no core dump is getting generated... I did raise this idea with the developers but they never really seemed have investigated if this might be the reason. The theory they raised in counter was that they think the reason the dmp isn't getting generated is because the program may be crashing twice very close together.

So the questions I have at this point are:

• Are there any Windows7 parameters that control the creation of a .dmp file?
• Are there any requirements/flags that need to be compiled into a program in order for it (or windows) to create a core dump file if it crashes?
• I'm 99% sure it must be windows that is responsible for creating the core file, since the program itself would be dead/terminated when it crashed, correct?
• Are there any other things I should be aware of, or check for, or 'evidence' I can collect and then show our developers?

Many thanks in advance

Answer 1

Are there any Windows7 parameters that control the creation of a .dmp file?

There are parameters which control the creation of a crash dump: see MSDN on Collecting user-mode dumps.

Are there any requirements/flags that need to be compiled into a program in order for it (or windows) to create a core dump file if it crashes?

You don't need to compile anything in for the previous answer to work. However, the program needs to terminate due to an unhandled exception, which means you need to let the exception bubble up and not being handled by the unhandled exception handler.

I'm 99% sure it must be Windows that is responsible for creating the core file, since the program itself would be dead/terminated when it crashed, correct?

As stated above, Windows can handle that and it's a good idea to have Windows handle the crash. Imagine that your program is broken due to a memory leak. Some memory has been overwritten. In that case, your unhandled exception handler can be destroyed. Windows, however, still has full control over the process, can suspend it and create a dump from outside (rather from inside).

Are there any other things I should be aware of, or check for, or 'evidence' I can collect and then show our developers?

Well, suggest letting the dump be created by Windows due to above reasons. Then they also don't need to implement a configuration setting (you don't want the crash dump file to be always created, do you?). You don't need to implement a limiting number for the files. You don't need to implement a check for disk space, etc.

And you can suggest to read the Windows Internals 6 books.

Answer 2

Consider creating your own minidump file programatically. Should be plenty of code around showing how to do it. You can try here:

https://stackoverflow.com/search?q=minidump

This way, you're not relying on Dr. Watson or any other settings to create a dump file. Instead you will be calling the functions in DBGHELP.DLL to create the dump file.