0

I have added an registry-key

SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\MyApp.exe

with the values

DumpCount 0x2
DumpType 0x1

to let Windows create a Minidump in case MyApp.exe crashes. The value for the path is not set in order to let Windows use the default storage location. Unfortuntately now after my application crashes, no dump is written to C:/Windows/Minidump (I added a memory access to 0x00000000 to the application in order to force a crash and to test writing of Minidumps).

Any idea what could be missing here?

Thanks!

Elmi
  • 5,899
  • 15
  • 72
  • 143
  • What sort of program is it? Maybe it has a global default exception handler that eats the exception? – 500 - Internal Server Error Feb 04 '19 at 10:11
  • @500-InternalServerError no, there is no default exception handler or something like that, right for this test I let it die without any further action in order to get a crash dump – Elmi Feb 04 '19 at 10:19
  • 1
    It needs to be a location that you have write access to without UAC elevation. So not c:\windows. Look here: https://stackoverflow.com/a/8765468/17034 – Hans Passant Feb 04 '19 at 11:55
  • The best thing is to create the dump yourself using a top level exception handler. – Michael Chourdakis Feb 04 '19 at 12:02
  • @HansPassant also when I set DumpFolder to e.g. D:\ (a drive where everybody can write to) nothing happens. By any chance, is there a registry option which disables this globally and overwrites application-local settings? – Elmi Feb 04 '19 at 12:55
  • Your OS version matters a lot, recent Win10 versions disable WER. [Look here](https://troubleshooter.xyz/wiki/enable-or-disable-windows-error-reporting-in-windows-10/). Follow up with as much relevant info at superuser.com if that doesn't help. – Hans Passant Feb 04 '19 at 14:13
  • @Michael: Sorry, but no. This is almost always never a good idea. Even the MSDN docs say so [MiniDumpWriteDump should be called from a separate process if at all possible, rather than from within the target process being dumped. _This is especially true when the target process is already not stable. For example, if it just crashed._](https://learn.microsoft.com/en-us/windows/desktop/api/minidumpapiset/nf-minidumpapiset-minidumpwritedump). – Christian.K Feb 04 '19 at 14:19
  • You may use Procdump from Systeninternals to do more tests and find a problem. – xMRi Feb 04 '19 at 14:59
  • @Christian.K so, this is equally like saying that do not use exceptions because the application has just crashed. A minidump handler is just as (un) stable as any exception handler. Moreover, you usually need the dump when your application has crashed in a system you do not have access to. – Michael Chourdakis Feb 04 '19 at 15:49
  • Possible duplicate of [LocalDumps registry key stopped working (Windows Error Reporting)](https://stackoverflow.com/questions/9535676/localdumps-registry-key-stopped-working-windows-error-reporting) – zett42 Feb 04 '19 at 23:45
  • @Michael: The point is you might be making things worse in a situation where your process is already in a bad shape. Several things might happen: (a) your process might not (eventually) exit / i.e. deadlock - which could be worse than an exit; (b) the real error reason might be hidden (even if you get a dump), making troubleshooting super annoying, ... There is a reason why Microsoft discourages that. Been there, done that. _The OS provides facilities to capture dumps without the help of the application itself_. YMMV of course. – Christian.K Feb 05 '19 at 09:03

1 Answers1

2

Create/Write a DWORD(32-bit) value named "Disabled" under the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting, and set it to 0 to turn on the WER or set to 1 to turn off.

If the value for the DumpFolder is not set, the Default value is %LOCALAPPDATA%\CrashDumps(According to Collecting User-Mode Dumps). Like:

enter image description here

And the "Report.wer" file is located at C:\ProgramData\Microsoft\Windows\WER\ReportArchive

Drake Wu
  • 6,927
  • 1
  • 7
  • 30