Microsoft Machine Debug Manager Dump Jit

First published on TechNet on Apr 05, 2015

Matthew Reynolds here. My job is to brand Windows sing (figuratively) in large enterprises.

If yous have a machine which freezes y'all may need to generate a memory dump in club to detect the crusade. If you can generate the retentivity dump before calling Microsoft support you might speed upwardly your diagnosis.

Use this technique if…

· The machine becomes unresponsive (but doesn't crash to a blue screen) such that you cannot apply other diagnostic tools

· The problem is probable to happen again in the future and then you have a chance to configure the automobile for next time

If you are thinking to yourself now, "what most live remote kernel debug?", or "what about subtle differences betwixt binary versions", or "folio file sizes are a many-nuanced topic" y'all are non wrong—you are but reading the incorrect mail service. Exhaustive documentation exists at https://support.microsoft.com/en-us/kb/969028 and linked friends. These encompass many more options, edge cases, virtualization and then on. I am writing this post considering I recently found that my customers and I needed a quick "try this start" reference for ordinary PCs and servers ( https://youtu.exist/pjvQFtlNQ-M ).

Step 1: Configure the Automatic (or Kernel) memory dump setting and page file

Of the various retentivity dump styles "Kernel" is oft the best residue between size and usefulness.

Starting with Windows 8 / Server 2012 the "Automatic" selection is a peachy way to get a Kernel memory dump. The automatic choice is described here. http://blogs.technet.com/b/askcore/archive/2012/09/12/windows-8-and-windows-server-2012-automatic-m... . Substantially you just choose the Automated options for both memory dump configuration and folio file size.

For Windows seven / Server 2008 R2 utilise "Kernel" selection instead with either organization managed page file size or folio file size > size of RAM.

Other dump modes such as Mini or Full might be used in consultation with a support engineer.

Stride 2: Trigger the crash dump

Option A – NMICrashDump (skilful for remotely managed server class hardware)

Some server hardware provides the ability to trigger a crash (to get a memory dump) using a hardware interrupt. Typically this would be triggered using a hardware level remote management interface.

This approach is described here: https://back up.microsoft.com/en-us/kb/927069 .

Essentially you set the NMICrashDump registry value and so utilize the hardware specific remote direction interface to trigger the crash.

Option B – CrashOnCtrlScroll (good for laptops and PC / workgroup-server class hardware)

"CrashOnCtrlScroll" ( https://msdn.microsoft.com/en-us/library/windows/hardware/ff545499(v=vs.85).aspx) is a technique where the keyboard driver and kernel conspire to crash the machine (to get a memory dump) when a magic key sequence is detected. This is like a Windows Internals version of up, up, down, downwardly, left, correct, left, right, B, A… ( http://en.wikipedia.org/wiki/Konami_Code ).

Some keyboards and KVMs preclude the default Control + Scroll Lock + Scroll Lock sequence from working. Where the heck is Whorl Lock on my tiny tablet keyboard?

Fortunately you can change the magic keys. The CrashOnCtrlScroll commodity linked above alludes to this but leaves much of the implementation to the reader'south imagination. I typically start with examples that others have figured out similar http://random-tutorials.blogspot.com/2012/08/transmission-crash-dumps-on-windows.html which looks every bit follows in my registry. Be careful. Command + D + D as configured hither is much more likely to be hitting accidentally than Command + Scroll Lock + Scroll Lock

Step 3: Retrieve the file and go it to an expert for analysis

Copy or move the memory dump file (located by default at %SystemRoot%\retentiveness.dmp) equally needed. If the original hang was blocking boot or logon you lot may accept to use an culling kick path such as Safe Mode to get there. In my world the target audience for the memory dump is normally an escalation level expert deep inside Microsoft support: https://support.microsoft.com .

In case y'all decide to have a go at debugging it using windbg.exe or other tools ( https://support.microsoft.com/en-united states/kb/315263 ) keep in mind that the cause of your crash is already known. You triggered it manually. I stress this because many debugging tools or guides (e.1000., !clarify) assume that you lot are trying to larn the crusade of the crash and volition simply written report that the crash was triggered past whichever method you used.

Instead your goal is to employ the memory dump to find the cause of the unresponsiveness which began prior to the crash. This is going to involve looking for locks, IRPs, critical sections, hung threads, etc. If only there were a cheat code…

Upwards, upward, down, down, left, right, left, right, B, A (and call usa)!

-Matthew "Glamour Shots" Reynolds