Making minidumps more useful

Miniport: meet minidump

Minidumps are a small (~100kb) record of a crash. As their name suggests, they’re optimized for small size… at the expense of usefulness. Minidumps include just enough information to see the stack of the faulting thread, but they don’t generally have other threads or most of kernel pool. If someone brings me with a minidump, the first thing I ask is “um, do you have anything better?”.

But that doesn’t mean that minidumps are completely useless. And with a little care, minidumps with your NDIS miniport can be just a little more useful. Here’s the trick.

When the system bugchecks, NDIS attempts to detect whether the bugcheck was caused by the network stack. If so, NDIS tries to determine which network driver is at fault. If NDIS determines that your miniport is at fault, NDIS will add some extra information to the minidump: enough data for !ndiskd.miniport to (mostly) work, and also a small chunk of your MiniportAdapterContext. In Windows 7 through Windows 8.1, NDIS will save the first 1024 * sizeof(void*) bytes of your MiniportAdapterContext. In other words,

Architecture

Context bytes saved

x64

8096

x86

4096

arm

4096

This is useful to know, because it helps you lay out your context block. You’ll find that, if you put your most important state into the first few kilobytes of your context block, then you’ll have an easier time debugging minidumps.

No. NDIS is not as hands-on with LWFs. And, frankly, LWFs don't cause as many problems in the real world, so we don't tend to spend as much time thinking about them. That's not to say that LWFs aren't 100% supported and recommended for certain types of solutions — LWFs are great. They just quietly do their business without making as much noise as miniports.