Getting more out of a minidump

we have a product deployed to a large customer base. By large I mean half a billion large! Needless to say, a lot of crash dumps come our way, and they are mostly minidumps. Unless the crash point is self indicative and obvious, it is hard to track down the root cause in many cases.

Adding to those are the difficulties of acquiring all dumps from Microsoft, it is a complex process altogether.

I am trying to see, if there is a way to enhance the output of a minidump itself in case the crash is pointing to our driver. I am trying to find smarter ways to get more info dumped, will registering a bugcheck handler here help in any way?

The only two ways I know to extend the minidump are:

  1. Registering a bugcheck callback for KbCallbackTriageDumpData
  2. Using the In Flight Recorder (IFR) support to have your last WPP messages stored in the minidump

Though even with awesome logging you still might not be able to figure out the problem (e.g. the bug might not be your problem). So, I’d have a backup plan for how you are able to acquire at least kernel summary dumps.

1 Like

@“Scott_Noone_(OSR)” said:
The only two ways I know to extend the minidump are:

  1. Registering a bugcheck callback for KbCallbackTriageDumpData
  2. Using the In Flight Recorder (IFR) support to have your last WPP messages stored in the minidump

Though even with awesome logging you still might not be able to figure out the problem (e.g. the bug might not be your problem). So, I’d have a backup plan for how you are able to acquire at least kernel summary dumps.

Thanks Scott. the IFR doesn’t seem to work for my dumps:
6: kd> !wdfkd.wdfldr

KMDF Drivers

LoadedModuleList 0xfffff80211e8a2b8

ReadListEntry failed
Wudfrd.sys is not loaded.
Not listing UMDF drivers.

This is definitely from one of the latest Win10 machines
6: kd> vertarget
Windows 10 Kernel Version 19041 MP (16 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Machine Name:
Kernel base = 0xfffff80210200000 PsLoadedModuleList = 0xfffff80210e2a390
Debug session time: Wed Feb 17 12:25:51.260 2021 (UTC - 8:00)
System Uptime: 1 days 9:16:31.700

Per MSDN documentation, there seem to be nothing specific that needs to be done apart from WPP tracing to get these logs, I tried on multiple dumps though, and got the same error.

Do you have “Enable WPP Recorder” set in your project properties when you build your driver?

@“Scott_Noone_(OSR)” said:
Do you have “Enable WPP Recorder” set in your project properties when you build your driver?

This is a legacy style project using sources files (with the latest WDK), would you by any chance know what is the equiv flag for that?

… using sources files (with the latest WDK) …

How? Sources is strongly dependent on “makefile.def” and “i386.mk”, which are no longer distributed. Are you saying you created up-to-date versions of those for WIndows 10?

Looking in WindowsDriver.Common…targets, it looks like it adds a preprocessor symbol ENABLE_WPP_RECORDER=1, and adds wpprecorder.lib to the list of link libraries.

The IFR is Win10+ only so the old environment doesn’t support it. I’d say this is a good opportunity to finally update your build environment.

I think ifr is 8+

Thanks everyone for the inputs.
Does anyone know what happens if the binary with IFR enabled is used in older OSs, would there be load issues? Our driver is KMDF 1.11 but ENABLE_WPP_RECORDER=1, and adding wpprecorder.lib seems to build fine. But whether it loads or not is something I haven’t been able to verify yet. Trying to get my hands of such a rig, but it seems it will take time.

We have to have backward compatibility for older OS, and hence the Q.

Given that wdf depends on other frame work drivers to execute this task, and those drivers aren’t likely to be present in the older platforms, I would assume nothing good is going to happen here. Best case scenario, your driver won’t load, as dependencies will fail to resolve, worst case a BSOD.

If you have the old Depends.exe tool lying around, try checking your binary for the OS where you are trying to use it.

@Albert said:
Thanks everyone for the inputs.
Does anyone know what happens if the binary with IFR enabled is used in older OSs, would there be load issues? Our driver is KMDF 1.11 but ENABLE_WPP_RECORDER=1, and adding wpprecorder.lib seems to build fine. But whether it loads or not is something I haven’t been able to verify yet. Trying to get my hands of such a rig, but it seems it will take time.

We have to have backward compatibility for older OS, and hence the Q.