Windows does not produce full crash dumps even though registry is set correctly
Asked Answered
S

2

7

My client are experiencing software crashes with a VB6 program I wrote.

I had set up the registry to produce full crash dumps, and I saw it working correctly with other programs that crashed on their system, but for some reason, for my program, it stil creates the simple crash dumps in a totally different directory.

My program is 32 bit running on an x64 computer. I have setup the registry as shown in the picture, both for SOFTWARE\Microsoft and SOFTWARE\Wow6432Node\Microsoft.

Still doesn't work.

Does anyone know how I can be sure that full crash dumps are produced every time the program crashes?

Registry changes I hade made

Socialization answered 26/5, 2015 at 11:43 Comment(6)
Your image is small. Did you create a sub key off "LocalDumps" that is the name of your application?Affable
@Affable - you're right, sorry about that. I added a new larger image. And not, I didn't know I needed to do that - just add a subkey under LocalDumps called "[MyApplication].exe"? What does it need to contain?Socialization
The current changes you've made will be applied globally. To trap dumps specifically for your application, you should add a sub key. MSDN has a comment about that under the explanation for each parameter.Affable
I saw that comment. The point is, that I've set these parameters, restarted the computer, but the changes were NOT applied globally: some application produce a full dump, but mine only produces a mini dump in another location.Socialization
Running .Net, correct? What version?Affable
My application is VB6, not .Net.Socialization
D
12

Permissions of the folder to write to

Looking at the permissions of the folder C:\ProgramData\Microsoft\Windows\WER it has

  • Read & execute
  • List folder contents
  • Read

Creating a subfolder LocalDumps will inherit the permissions.

So you should either modify the permissions of that folder or use a different folder with write permissions.

Permissions of the Registry key

Windows might not be able to read the Registry settings if the permissions do not allow it. E.g. the following (really silly) permissions will prevent a LocalDump as well:

LocalDumps permissions

32 vs. 64 bit

Windows Error Reporting is executed by Windows and only uses the registry key with the bitness of the OS. You said you set up both. If that's true, it`s fine. If you only set up the 32 bit Registry key, it won't work.

AeDebug

If you have a setting for AeDebug, those are executed before WER.

Note that this entry may exist in 32 bit (WOW6432Node) and 64 bit.

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug

Usually that should result in starting a debugger, but who knows ... it might do nothing and just exit.

LocalDumps is disabled

Make sure that there is no DWORD Disabled with a value of 1 in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps.

Use of REG_SZ instead of REG_EXPAND_SZ

I have seen people using a REG_SZ for DumpFolder in combination with %APPDATA%. Only REG_EXPAND_SZ will expand environment variables.

Someone cancels the crash dump generation

If the WER dialog is enabled, someone may press the cancel button.

Set DWORD DontShowUI to 1 to disable the dialog (in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting).

User settings instead of machine settings

There's the machine wide setting

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Windows Error Reporting

but also user defined settings in

HKEY_CURRENT_USER\Software\Microsoft\Windows\Windows Error Reporting

Perhaps the machine values are overwritten by the user settings.

Try before using it

To test whether your settings work, you can test with a small C++ program.

#include "stdafx.h"
#include <exception>

int _tmain(int /*argc*/, _TCHAR* /*argv*/[])
{
    throw std::exception();
}

or C# program

using System;

namespace netcrash
{
   class Program
   {
      static void Main(string[] args)
      {
         Console.WriteLine("Press Enter to crash");
         Console.ReadLine();
         throw new Exception("Just a simple crash");
      }
   }
}
Directions answered 26/5, 2015 at 21:18 Comment(5)
It appears the permissions were the problem. Thank you for this super accurate and detailed answer!Socialization
Are registery entries like in user-mode dumps required? I don't have any entries there, should it use the defaults on generate dump files? Do I have to manually enter these? My app is not producing user-mode dump file when it crashes, my permission on WER are right.Overexcite
@zar: if you don't have those Registry entries, Windows will decide to do something else. By default it will show the Windows Error Reporting "Send report to Microsoft" dialog. If you have a debugger installed (like Visual Studio), it will offer a possibility to debug. Regarding "manually", you can of course write those entries programmatically as well, e.g. during the Setup. Be sure not to flood your customer's PC with dump files.Directions
I created 32-bit parameters in the register instead of 64-bit ones. Thank you a lot!Scroggins
@AlexKoshulyan: I'm glad I could help.Directions
I
0

In addition to the excellent answer from @Thomas Weller above let me add:

Make Sure The Windows Error Reporting Service Is Running

Open the services snap-in (run services.msc), located "Windows Error Reporting Service" and make sure that it is set to "Automatic" start-up type and is "Running".

Without this, no matter what registry entries are set, you won't get any crash-dumps written! (as I have just found after a day of going round in circles)

Inessential answered 4/4 at 12:49 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.