0

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

sparco1500
  • 187
  • 3
  • 15
  • To answer some of your questions, yes, you are asking the right questions. – Lightness Races in Orbit Feb 10 '14 at 22:35
  • 1
    Yes, there's no scenario where you are going to get a .dmp file if you filter the exception yourself. You get a program to create a .dmp itself by using SetUnhandledExceptionFilter() and calling MiniDumpCreateDump(). If you want somebody else to do it then you need to let it crash so the exception is externally visible. Enough upheaval in the way things were done before to get you going, I'd say. – Hans Passant Feb 10 '14 at 22:49
  • 1
    You could attach WinDbg and log the output, if the exception is thrown it should be captured in the output as being handled, you could then restart the app, attach WinDbg again, set `Debug>EventFilters...` and enable the offending exception and handle it using WinDbg and then dump the memory. – EdChum Feb 11 '14 at 08:43

2 Answers2

1

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.

Community
  • 1
  • 1
PaulMcKenzie
  • 34,698
  • 4
  • 24
  • 45
  • 1
    Relying on Dr. Watson (or Windows Error Reporting) is usually more reliable than implementing an own exception handler, where things can go wrong, because the address space of the exception handler has already been messed up. – Thomas Weller Feb 11 '14 at 08:54
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.

Thomas Weller
  • 55,411
  • 20
  • 125
  • 222