{"componentChunkName":"component---src-templates-post-template-js","path":"/windows-windbg-005-kernel-dump-en","result":{"data":{"markdownRemark":{"id":"0c19f2b3-544e-5397-a5a3-5408686b2541","html":"
\n

This page has been machine-translated from the original page.

\n
\n

My goal is to become proficient with WinDbg for Windows debugging and dump-based troubleshooting.

\n

In a previous article, First Steps in Kernel Debugging with WinDbg on Windows 10, I covered how to get started with kernel-mode debugging using WinDbg.

\n

This time, rather than live debugging, I’ll walk through how to analyze a kernel memory dump.

\n

For a full list of articles on Windows debugging and dump analysis with WinDbg, see the index page:

\n

Reference: Debugging and Troubleshooting Techniques with WinDbg

\n

This article covers the following topics.

\n\n

Table of Contents

\n\n

Tools Used

\n

In this article I’m using the following two tools on a Windows 10 system.

\n\n

WinDbg Preview

\n

WinDbg Preview is the UWP version of WinDbg available from the Microsoft Store.

\n

Compared to the classic WinDbg included in Windows Debug Tools, it features a much more modern UI and adds support for Time Travel Debugging (TTD), among other improvements.

\n

It shares the same underlying engine as the classic WinDbg, so all existing functionality continues to work.

\n

Reference: Debugging Using WinDbg Preview - Windows drivers | Microsoft Docs

\n

NotMyFault

\n

NotMyFault is a tool for manually generating the memory dump that would normally be produced when a computer crashes.

\n

It can be obtained from the link in the following document.

\n

Reference: Generate a kernel or complete crash dump - Windows Client Management | Microsoft Docs

\n

Capturing a Kernel Memory Dump

\n

First, let’s capture a kernel memory dump for analysis.

\n

Configuring Everything with a PowerShell Script (Added July 2023)

\n

The following article describes how to configure full memory dump capture settings and keyboard-crash settings all at once with a PowerShell script.

\n

Reference: Configure Windows Full Memory Dump and Keyboard Crash Settings with a PowerShell Script

\n

Changing Settings via Control Panel

\n

Open Control Panel on the machine you want to capture a dump from and navigate to System and Security.

\n

Click System, then Advanced system settings to open the System Properties window.

\n

First, under the Performance section, change the virtual memory paging file size to a value at least 300 MB larger than the physical memory size.

\n

\n \n \n \n \n \n \n \n \n

\n

With Notepad in this state, run the NotMyFault tool you extracted earlier.\nYou will be prompted to agree to a EULA — click OK.

\n

When the tool opens, leave the default selection and click Crash.

\n

\n \n \n \n \n \n \n \n \n

\n

After the restart, confirm that MEMORY.DMP exists directly under C:\\Windows.\nIn my environment it was roughly 450 MB.

\n

The kernel memory dump has now been captured.

\n

Analyzing the Kernel Memory Dump

\n

Loading the Dump File into WinDbg

\n

Launch WinDbg with administrator privileges.

\n

Go to File → Open dump file and import the MEMORY.DMP file created earlier.\n(Loading a memory dump into WinDbg can take several minutes.)

\n

Once the dump is loaded, you will see output similar to the following:

\n
Loading Dump File [C:\\Windows\\MEMORY.DMP]\nKernel Bitmap Dump File: Kernel address space is available, User address space may not be available.\n\nSymbol search path is: srv*\nExecutable search path is: \nWindows 10 Kernel Version 19041 MP (3 procs) Free x64\nProduct: WinNt, suite: TerminalServer SingleUserTS\nEdition build lab: 19041.1.amd64fre.vb_release.191206-1406\nMachine Name:\nKernel base = 0xfffff800`62600000 PsLoadedModuleList = 0xfffff800`6322a230\nDebug session time: Thu Oct  7 20:33:12.945 2021 (UTC + 9:00)\nSystem Uptime: 0 days 0:00:54.755\nLoading Kernel Symbol
\n

Reading the Output at Load Time

\n

The output above gives us the following information:

\n\n

Debug session time and System Uptime in particular can be important clues during troubleshooting, so it’s worth checking them.

\n

Running Automatic Analysis with !analyze -v

\n

Next, run the automatic analysis command:

\n
!analyze -v
\n

The automatic analysis in modern versions of WinDbg is quite powerful, and even this single command reveals a great deal of information.

\n

The command produces a lot of output. Let’s look at a few key excerpts.

\n

The first thing printed is the crash analysis result. During troubleshooting, this is often a good starting point.

\n
2: kd> !analyze -v\n*******************************************************************************\n*                                                                             *\n*                        Bugcheck Analysis                                    *\n*                                                                             *\n*******************************************************************************\n\nDRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)\nAn attempt was made to access a pageable (or completely invalid) address at an\ninterrupt request level (IRQL) that is too high.  This is usually\ncaused by drivers using improper addresses.\nIf kernel debugger is available get stack backtrace.\nArguments:\nArg1: ffffd8024aaa8010, memory referenced\nArg2: 0000000000000002, IRQL\nArg3: 0000000000000000, value 0 = read operation, 1 = write operation\nArg4: fffff80060da1981, address which referenced memory
\n

Because we triggered the crash using NotMyFault’s High IRQL Fault (Kernel-mode) option, the output shows a DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1) error.

\n

Reference: Bug Check 0xD1 DRIVERIRQLNOTLESSOR_EQUAL - Windows drivers | Microsoft Docs

\n

This error occurs when code executing at an Interrupt Request Level (IRQL) higher than PASSIVE_LEVEL (the lowest level) attempts to access paged pool memory.

\n

For more detail, the following article is a useful reference:

\n

Reference: Device Driver Lecture 12 │ Science Park Co., Ltd.

\n

After registry information is printed, the analysis output shows the crashing process and the stack trace:

\n
PROCESS_NAME:  notmyfault64.exe\n\nTRAP_FRAME:  ffffd48f77af97e0 -- (.trap 0xffffd48f77af97e0)\nNOTE: The trap frame does not contain all registers.\nSome register values may be zeroed or incorrect.\nrax=00000000c85c00f0 rbx=0000000000000000 rcx=ffffd80241e00340\nrdx=0000000000000890 rsi=0000000000000000 rdi=0000000000000000\nrip=fffff80060da1981 rsp=ffffd48f77af9970 rbp=0000000000000002\n r8=ffffd8024abbdc80  r9=0000000000000000 r10=ffffd80241e002c0\nr11=ffffd8024aa9bff0 r12=0000000000000000 r13=0000000000000000\nr14=0000000000000000 r15=0000000000000000\niopl=0         nv up ei ng nz na pe nc\nmyfault+0x1981:\nfffff800`60da1981 8b03            mov     eax,dword ptr [rbx] ds:00000000`00000000=????????\nResetting default scope\n\nSTACK_TEXT:  \nffffd48f`77af9698 fffff800`62a09169     : 00000000`0000000a ffffd802`4aaa8010 00000000`00000002 00000000`00000000 : nt!KeBugCheckEx\nffffd48f`77af96a0 fffff800`62a05469     : 00007ff8`f16ecc00 00000000`00000000 00000000`00000f4d 00000000`00000000 : nt!KiBugCheckDispatch+0x69\nffffd48f`77af97e0 fffff800`60da1981     : 00000000`00000000 ffffd48f`77af99c8 00000000`00000000 00000000`00000000 : nt!KiPageFault+0x469\nffffd48f`77af9970 fffff800`60da1d3d     : 00000000`c85c00f0 000001e3`5fb24550 00000000`000000f0 00000000`00000000 : myfault+0x1981\nffffd48f`77af99a0 fffff800`60da1ea1     : ffff9189`4ed94d70 00000000`00000000 00000000`00000000 fffff800`62bf5e51 : myfault+0x1d3d\nffffd48f`77af9ae0 fffff800`6288f865     : ffff9189`4ed94d70 00000000`00000001 ffffd48f`77af9ec0 00000000`00000001 : myfault+0x1ea1\nffffd48f`77af9b40 fffff800`62c75328     : ffffd48f`77af9ec0 ffff9189`4ed94d70 00000000`00000001 fffff800`00000000 : nt!IofCallDriver+0x55\nffffd48f`77af9b80 fffff800`62c74bf5     : 00000000`00000000 ffffd48f`77af9ec0 00000000`00000000 ffffd48f`77af9ec0 : nt!IopSynchronousServiceTail+0x1a8\nffffd48f`77af9c20 fffff800`62c745f6     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!IopXxxControlFile+0x5e5\nffffd48f`77af9d60 fffff800`62a08bb5     : 00000000`fffffffc ffff5121`00000000 00000000`00000001 000001e3`5f5e99a0 : nt!NtDeviceIoControlFile+0x56\nffffd48f`77af9dd0 00007ff8`f16ece54     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x25\n0000007a`e6bde8d8 00000000`00000000     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00007ff8`f16ece54\n\nSYMBOL_NAME:  myfault+1981\nMODULE_NAME: myfault\nIMAGE_NAME:  myfault.sys\nSTACK_COMMAND:  .thread ; .cxr ; kb\nBUCKET_ID_FUNC_OFFSET:  1981\nFAILURE_BUCKET_ID:  AV_myfault!unknown_function\nOS_VERSION:  10.0.19041.1\nBUILDLAB_STR:  vb_release\nOSPLATFORM_TYPE:  x64\nOSNAME:  Windows 10\nFAILURE_ID_HASH:  {9745090a-9bce-ccba-c096-ca6e9ca04c64}\nFollowup:     MachineOwner
\n

As you can see, !analyze -v alone gives you a substantial amount of information.

\n

Analyzing the Stack Back Trace

\n

Next, let’s analyze the stack back trace.

\n

For documentation on stack back trace display commands, refer to:

\n

Reference: k, kb, kc, kd, kp, kP, kv (Display Stack Backtrace) - Windows drivers | Microsoft Docs

\n

Here I compared the output of three commands: k, kb, and kv.

\n

\n \n \n \n \n \n \n \n \n

\n

kv clearly provides more information, including Frame Pointer Omission (FPO) data.

\n

Notice the line (TrapFrame @ ffffd48f77af97e0)`. This is the trap frame — it records the CPU registers and stack at the moment an interrupt occurred, and is critical information for restoring the thread state at that point.

\n

Restoring a Thread from a Trap Frame

\n

Use the .trap command to restore the thread state from the trap frame.

\n

The output shows register values at the point captured in the trap frame:

\n
2: kd> .trap ffffd48f`77af97e0\nNOTE: The trap frame does not contain all registers.\nSome register values may be zeroed or incorrect.\nrax=00000000c85c00f0 rbx=0000000000000000 rcx=ffffd80241e00340\nrdx=0000000000000890 rsi=0000000000000000 rdi=0000000000000000\nrip=fffff80060da1981 rsp=ffffd48f77af9970 rbp=0000000000000002\n r8=ffffd8024abbdc80  r9=0000000000000000 r10=ffffd80241e002c0\nr11=ffffd8024aa9bff0 r12=0000000000000000 r13=0000000000000000\nr14=0000000000000000 r15=0000000000000000\niopl=0         nv up ei ng nz na pe nc\nmyfault+0x1981:\nfffff800`60da1981 8b03            mov     eax,dword ptr [rbx] ds:00000000`00000000=????????
\n

The stack back trace confirms we are now viewing the state at the trap frame:

\n
2: kd> kv\n  *** Stack trace for last set context - .thread/.cxr resets it\n # Child-SP          RetAddr               : Args to Child                                                           : Call Site\n00 ffffd48f`77af9970 fffff800`60da1d3d     : 00000000`c85c00f0 000001e3`5fb24550 00000000`000000f0 00000000`00000000 : myfault+0x1981\n01 ffffd48f`77af99a0 fffff800`60da1ea1     : ffff9189`4ed94d70 00000000`00000000 00000000`00000000 fffff800`62bf5e51 : myfault+0x1d3d\n02 ffffd48f`77af9ae0 fffff800`6288f865     : ffff9189`4ed94d70 00000000`00000001 ffffd48f`77af9ec0 00000000`00000001 : myfault+0x1ea1\n03 ffffd48f`77af9b40 fffff800`62c75328     : ffffd48f`77af9ec0 ffff9189`4ed94d70 00000000`00000001 fffff800`00000000 : nt!IofCallDriver+0x55\n04 ffffd48f`77af9b80 fffff800`62c74bf5     : 00000000`00000000 ffffd48f`77af9ec0 00000000`00000000 ffffd48f`77af9ec0 : nt!IopSynchronousServiceTail+0x1a8\n05 ffffd48f`77af9c20 fffff800`62c745f6     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!IopXxxControlFile+0x5e5\n06 ffffd48f`77af9d60 fffff800`62a08bb5     : 00000000`fffffffc ffff5121`00000000 00000000`00000001 000001e3`5f5e99a0 : nt!NtDeviceIoControlFile+0x56\n07 ffffd48f`77af9dd0 00007ff8`f16ece54     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x25 (TrapFrame @ ffffd48f`77af9e40)\n08 0000007a`e6bde8d8 00000000`00000000     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00007ff8`f16ece54
\n

Inspecting Processes

\n

Now let’s try to analyze the state of the Notepad process that was mid-save when the crash occurred.

\n

The following command lists all running processes:

\n
!process 0 0
\n

Reference: !process - Windows drivers | Microsoft Docs

\n

When the first argument is 0, information is printed for all processes.

\n

To display information for a specific process only, provide a hexadecimal process address or a process ID as the first argument.

\n

The second argument controls the level of detail.

\n\n

Search through the output to find the Notepad process:

\n
PROCESS ffff9189527e9080\n    SessionId: 2  Cid: 1e90    Peb: bb6f2ac000  ParentCid: 15e8\n    DirBase: 1d822d000  ObjectTable: ffffd80249eb8040  HandleCount: 817.\n    Image: notepad.exe
\n

Now use that process address to print its detailed information.

\n

Setting the flag (second argument) to 7 shows the complete details for a single process:

\n
2: kd> !process ffff9189527e9080 7\nPROCESS ffff9189527e9080\n    SessionId: 2  Cid: 1e90    Peb: bb6f2ac000  ParentCid: 15e8\n    DirBase: 1d822d000  ObjectTable: ffffd80249eb8040  HandleCount: 817.\n    Image: notepad.exe\n    VadRoot ffff918953a30a20 Vads 285 Clone 0 Private 2175. Modified 340. Locked 2.\n    DeviceMap ffffd80247fe8cf0\n    Token                             ffffd8024a19c770\n    ElapsedTime                       00:00:47.378\n    UserTime                          00:00:00.000\n    KernelTime                        00:00:00.000\n    QuotaPoolUsage[PagedPool]         430688\n    QuotaPoolUsage[NonPagedPool]      39648\n    Working Set Sizes (now,min,max)  (11788, 50, 345) (47152KB, 200KB, 1380KB)\n    PeakWorkingSetSize                11793\n    VirtualSize                       2101500 Mb\n    PeakVirtualSize                   2101501 Mb\n    PageFaultCount                    14745\n    MemoryPriority                    BACKGROUND\n    BasePriority                      8\n    CommitCharge                      3452\n\n        THREAD ffff91895309d080  Cid 1e90.1e94  Teb: 000000bb6f2ad000 Win32Thread: ffff9189523d0fc0 WAIT: (UserRequest) UserMode Non-Alertable\n            ffff918953118260  SynchronizationEvent\n            ffff918952d83d80  QueueObject\n        Not impersonating\n        DeviceMap                 ffffd80247fe8cf0\n        Owning Process            ffff9189527e9080       Image:         notepad.exe\n        Attached Process          N/A            Image:         N/A\n        Wait Start TickCount      3492           Ticks: 12 (0:00:00:00.187)\n        Context Switch Count      10798          IdealProcessor: 2             \n        UserTime                  00:00:00.140\n        KernelTime                00:00:00.328\n        Win32 Start Address 0x00007ff7e2e85a30\n        Stack Init ffffd48f777bffd0 Current ffffd48f777bead0\n        Base ffffd48f777c0000 Limit ffffd48f777ba000 Call 0000000000000000\n        Priority 10 BasePriority 8 PriorityDecrement 0 IoPriority 2 PagePriority 5\n        Child-SP          RetAddr               Call Site\n        ffffd48f`777beb10 fffff800`6280c970     nt!KiSwapContext+0x76\n        ffffd48f`777bec50 fffff800`6280be9f     nt!KiSwapThread+0x500\n        ffffd48f`777bed00 fffff800`628805ce     nt!KiCommitThreadWait+0x14f\n        ffffd48f`777beda0 fffff800`62c6f620     nt!KeWaitForMultipleObjects+0x2be\n        ffffd48f`777beeb0 ffffeccb`d0c3798d     nt!ObWaitForMultipleObjects+0x2f0\n        ffffd48f`777bf3b0 ffffeccb`d0b46c5e     win32kfull!xxxMsgWaitForMultipleObjectsEx+0xd9\n        ffffd48f`777bf460 ffffeccb`d15d6fd0     win32kfull!NtUserMsgWaitForMultipleObjectsEx+0x3fe\n        fffff800`62a08bb5     win32k!NtUserMsgWaitForMultipleObjectsEx+0x20\n        ffffd48f`777bfdd0 00007ff8`eed7a104     nt!KiSystemServiceCopyEnd+0x25 (TrapFrame @ ffffd48f`777bfe40)\n        000000bb`6f17e2d8 00000000`00000000     0x00007ff8`eed7a104\n{{ omitted }}
\n

From this output we were able to retrieve information about the Notepad process at the moment it was trying to save a file.

\n

Because this is a kernel memory dump, it only contains kernel-mode process information. To inspect user-mode process information as well, a complete (full) memory dump is required.

\n

Wrap-up

\n

In this article, I covered how to manually capture a kernel memory dump on Windows and how to perform basic analysis using WinDbg.

\n

Going forward, I plan to document more advanced analysis techniques as well.

\n

For other articles on Windows debugging and dump analysis with WinDbg, see the list on the following page:

\n

Reference: Debugging and Troubleshooting Techniques with WinDbg

","fields":{"slug":"/windows-windbg-005-kernel-dump-en","tagSlugs":["/tag/win-dbg-en/","/tag/kernel-en/","/tag/reversing-en/","/tag/english/"]},"frontmatter":{"date":"2021-10-08","description":"","tags":["WinDbg (en)","Kernel (en)","Reversing (en)","English"],"title":"How to Manually Capture a Kernel Memory Dump on Windows and Analyze It with WinDbg","socialImage":{"publicURL":"/static/21701f5e36fa675d31449570ab3e9c7d/windows-windbg-005-kernel-dump.png"}}}},"pageContext":{"slug":"/windows-windbg-005-kernel-dump-en"}},"staticQueryHashes":["251939775","401334301","825871152"]}