Activate WER Minidumps

[lmstearn]

Most experienced folks won't have any requirement to set WER up, if, for example, they run AHK in Visual Studio with the VS debugger enabled, or use WinDbg. Other interactive debugging options focused more for AHK scripts can be found here, and another one of interest is dmp(). For compiled scripts that do not always crash, the alternative is a post-mortem dump file analysis, the subject here, so for those who may wish not entertain any notion of a brisk dmp-de-da-dmp cha-cha with Dr. Google, read on:

First up, it is a rare, but unfortunate occurrence when scripts cause AutoHotkey to crash. Most of the time it turns out to be wrong capacities set for variables in NumPut or DLLCall, else a problem with a CallBack routine. If the crashes are not produced every run, but in a "random" 1 every 5, or 1 every 10 runs etc., it's possible we may be reading beyond allocated memory, and occasionally landing in a protected area, so a post-mortem dump analysis may provide deeper insights as to the cause and its location in the code.

The ultimate aim of this short blurb is to gain some insights from a WER minidump reading, where a requirement of dump file generation, according to this dx article, the (compiled) app must be signed. Happy to say it can be done from here.
The reference doc for the exercise is collecting User Mode Dumps.

• First check the existence of the default folder LocalAppData\CrashDumps (created by Windows on the rig), and that it has the appropriate permissions for SYSTEM R/W access.

• Elevate the following script to check the existence of the WER keys:

  Code: Select all

  RegRead out, HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps, DumpCount
  	if (!out)
  	msgbox Dump Count required. Default is 10
  RegRead out, HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps, DumpFolder
  	if (!out)
  	msgbox Dump Folder required. Default is %LOCALAPPDATA%\CrashDumps
  RegRead out, HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps, DumpType
  	if (!out)
  	msgbox Dump Type required. Default is 1
  

  If the keys don't exist, manually add them to the registry, or use Regwrite.

• If we are are using a 32 bit script or compiled executable on a 64 bit system, the safest option is to replicate the above LocalDumps key in HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\Windows Error Reporting as well.

• Next, From learnMS,

  A crash dump is not collected when you set automatic debugging for application crashes.

  So, to exclude an application with the name of MYCrashingAppName.exe, create an REG_DWORD value having the text of MYCrashingAppName.exe in HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug\AutoExclusionList, and give it a value of 1, as explained here. There is no harm in adding another value in there for AutoHotkey.exe, if indeed a crashing script can yield a minidump in the same way.
  Note: Doing this will now affect interactive debugging of the script (or AutoHotkey.exe) by any debug program referenced in HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger such as the VS vsjitdebugger.exe or windbg.exe, so the keys may require removal post-process.

• Again, If we are are using a 32 bit script or compiled executable on a 64 bit system, also replicate the above AeDebug key in HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows NT\CurrentVersion.

• After the app or script generates the crash dump, use something like DumpReport to make the information more readable. There is also CrashRpt (not having been updated awhile) which works with WinDbg, or, provided various conditions and settings in Visual Studio are met, paints an even clear picture.

By the way

Still waiting for the first dmp to be produced for the OP's MYCrashingAppName, so much of the above is to date, untested!