{"componentChunkName":"component---src-templates-post-template-js","path":"/windows-windbg-004-kernel-debug-en","result":{"data":{"markdownRemark":{"id":"5045b0ee-88c9-5a11-ab68-4bcbcb57320a","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 Trying the WinDbg User-Mode Debugging Tutorial, I introduced the first steps for debugging a user-mode process with WinDbg based on the official tutorial.

\n

In this article, I summarize how to perform kernel-mode debugging with WinDbg.

\n

For a list of information I have published about Windows debugging and dump analysis with WinDbg, see the page below.

\n

Reference: Debugging and Troubleshooting Techniques with WinDbg

\n

This article covers the following topics.

\n\n

Table of Contents

\n\n

Setting Up an Environment for Kernel-Mode Debugging

\n

To perform kernel-mode debugging with WinDbg, you need two systems: a host computer that runs WinDbg and a target computer to be debugged, connected by one of the following methods.

\n\n

Reference: WinDbg Overview (Kernel Mode) - Windows drivers | Microsoft Docs

\n

Strictly speaking, two machines are required if you want to access and debug the entire kernel.\nYou can also perform local kernel debugging on a single machine, but analyses that require stopping the OS cannot be performed, so there are limitations.

\n

Reference: Manually setting up local kernel debugging of a single computer - Windows drivers | Microsoft Docs

\n

Normally, kernel-mode debugging requires two computers, but WinDbg can also perform kernel-mode debugging against Windows installed in a virtual machine.

\n

This time, I will set up kernel-mode debugging for Windows machines built on Hyper-V and VirtualBox.

\n

Environment Used in This Article

\n\n

Changing Hyper-V Settings

\n

This section assumes that a Windows 10 virtual machine is already running on Hyper-V.

\n

For kernel debugging, open the settings for the target virtual machine in Hyper-V and configure the COM1 settings as shown below.

\n

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

\n

This completes the VirtualBox-side configuration, so start the virtual machine.

\n

Enabling Kernel-Mode Debugging

\n

After the virtual machine starts, launch a command line as an administrator and enter the following commands.

\n
bcdedit /debug on\nbcdedit /dbgsettings serial debugport:1 baudrate:115200
\n

Alternatively, start Msconfig.exe, specify the COM1 port from the advanced options, and enable debugging.

\n

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

\n

Once the settings above are complete, configure WinDbg on the host machine.

\n

This is not required for kernel debugging itself, but if you want to test using a self-made device driver or similar, run the following command and then restart the OS to enable test-signing mode.

\n
bcdedit /set testsigning on
\n

Configuring WinDbg

\n

On the host machine, start WinDbg with administrator privileges.

\n

For kernel-mode debugging, WinDbg must also be started with administrator privileges.\nIf it is started in user mode, kernel-mode debugging will fail with an error such as Kernel debugger failed initialization, Win32 error 5 Access is denied.

\n

After starting WinDbg as an administrator, select [File] > [Kernel Debug] and connect to the target machine using a named pipe as shown below.

\n

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

\n

After completing this setup, click [OK]. A Command window for kernel debugging will open and begin waiting for a connection on the COM port.

\n
Waiting for pipe \\\\.\\pipe\\com1\nWaiting to reconnect...
\n

Finally, restart the Windows machine on the target side.

\n

Then, as shown below, WinDbg connects to the target machine and the target machine starts in test mode.

\n

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

\n

This completes the preparation required to perform Windows kernel debugging with WinDbg.

\n

Performing Kernel Debugging with WinDbg

\n

Now that WinDbg has connected to the target machine over the COM port, the environment is ready for kernel debugging.

\n

However, because the target machine’s Windows OS is currently running, you still cannot operate it from the WinDbg Command window.

\n

To proceed with kernel debugging in WinDbg, you first need to stop the Windows kernel once.

\n

Stopping the Kernel from WinDbg

\n

To stop the Windows kernel for kernel debugging, click the [Break] button on the toolbar at the top of WinDbg, or press [Ctrl+Break].

\n

Alternatively, you can stop it by selecting [Break] from the [Debug] menu at the top of WinDbg.

\n

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

\n

After the following output appears, you can operate WinDbg from the Command window.

\n
Connected to Windows 10 10586 x64 target at (Mon Oct  4 17:32:25.121 2021 (UTC + 9:00)), ptr64 TRUE\nKernel Debugger connection established.\nSymbol search path is: srv*\nExecutable search path is: \nWindows 10 Kernel Version 10586 MP (1 procs) Free x64\nEdition build lab: 10586.162.amd64fre.th2_release_sec.160223-1728\nMachine Name:\nKernel base = 0xfffff803`5280b000 PsLoadedModuleList = 0xfffff803`52ae9cd0\nSystem Uptime: 0 days 0:00:00.121\nKDTARGET: Refreshing KD connection\nBreak instruction exception - code 80000003 (first chance)\n*******************************************************************************\n*                                                                             *\n*   You are seeing this message because you pressed either                    *\n*       CTRL+C (if you run console kernel debugger) or,                       *\n*       CTRL+BREAK (if you run GUI kernel debugger),                          *\n*   on your debugger machine's keyboard.                                      *\n*                                                                             *\n*                   THIS IS NOT A BUG OR A SYSTEM CRASH                       *\n*                                                                             *\n* If you did not intend to break into the debugger, press the \"g\" key, then   *\n* press the \"Enter\" key now.  This message might immediately reappear.  If it *\n* does, press \"g\" and \"Enter\" again.                                          *\n*                                                                             *\n*******************************************************************************\nnt!DbgBreakPointWithStatus:\nfffff803`52952eb0 cc              int     3
\n

Displaying a List of Modules in Kernel-Mode Debugging

\n

Even in kernel-mode debugging, the basic operations performed from the Command window are almost the same as the user-mode debugging introduced in this article.

\n

As a quick test, I ran the lm command to output a list of the loaded modules.

\n

\n \n