Kernel Debugger Windows 10

[Efraine Ton]

Forinformation about how to get Debugging Tools for Windows, see Download and install the WinDbg Windows debugger. After you have installed the debugging tools, locate the installation directories for 64-bit (x64) and 32-bit (x86) versions of the tools. For example:

A kernel-mode debugging environment typically has two computers, the host computer and the target computer. The debugger runs on the host computer, and the code being debugged runs on the target computer. The host and target are connected by a debug cable.

After you set up your host and target computer and connect them with a debug cable, you can establish a kernel-mode debugging session. Follow the instructions in the same topic that you used for getting set up. For example, if you decide to set up your host and target computers for debugging over Ethernet, you can find instructions for establishing a kernel-mode debugging session in the following article:

To open the debugger documentation CHM file, go to the Help menu and select Contents. The debugger documentation is also available online in Debugging Tools for Windows.

When you establish a kernel-mode debugging session, WinDbg might break into the target computer automatically. If WinDbg doesn't break in, go to the Debug menu and select Break.

If the target computer doesn't break into the debugger immediately, perform a few actions on the target computer (for example, open Notepad). The target computer will break into the debugger when MmCreateProcessAddressSpace is called. To see the stack trace, enter the following commands:

If the target computer doesn't break into the debugger immediately, perform a few actions on the target computer (for example, open Notepad and save a file). The target computer will break into the debugger when ClassGlobalDispatch is called. To see the stack trace, enter the following commands:

I suspect what is happening is that because a debugger is enabled, user mode exceptions are being triggered in the kernel debugger process and it is waiting for me to enter some input from an attached debugger??

Is there any way to change the boot option before Windows loads so that I can turn off kernel debugging. I have only the one boot config which was, in hindsight, my problem - I should have created a copy of the first boot config for my debug boot option.

The only option I can think of now is to attempt to connect a debugger from a different machine through a USB port. However, don't I need to configure the target PC to accept a debugger on a USB port or will this just work if I get a proper debug USB cable?

Opening a command prompt and typing "bcdedit -debug off" which was accepted but didn't seem to help.I then tried restoring to a restore point of a couple of days previous. Again I got a hang on reload.

There is no need for to use the repair option! Just press F10 instead of F8, now you will be able to edit the bootparameter! Just delete /DEBUG and press enter to continue the boot process. After set use bcdedit -debug off to permanently change the debug option.

Debugging Tools for Windows supports local kernel debugging. This is kernel-mode debugging on a single computer. In other words, the debugger runs on the same computer that is being debugged. With local debugging, you can examine state, but not break into kernel mode processes that would cause the OS to stop running.

The first is using a local kernel debugger, which means configuring WinDbg to look at the kernel of the local machine. This can be configured by running the following command in an elevated command window, and restarting the system:

Some aspects of a typical kernel might not show up when debugging a VM. For example, looking at the list of interrupt service routines (ISRs) with the !idt command on my Hyper-V VM shows something like the following (truncated):

A kernel debugger is a debugger present in some operating system kernels to ease debugging and kernel development by the kernel developers. A kernel debugger might be a stub implementing low-level operations, with a full-blown debugger such as GNU Debugger (gdb), running on another machine, sending commands to the stub over a serial line or a network connection, or it might provide a command line that can be used directly on the machine being debugged.

This error is on Windows 7 Home Premium on my laptop (x64). I am trying to learn more about Windows Internals by using local kernel debugging in WinDBG, followed by LiveKD. I have Windows Debugging Tools for Windows 7 installed.

I keep getting the following errors - what could be wrong (in the screenshot I use kd instead of windbg to capture the error message; the shell is run as administrator)? I tried running LiveKD because WinDBG was failing. I just wanted to look at internal data structures.

BTW, WinDBG asked me to run "bcdedit -debug on and reboot to enable it" - I ran it and rebooted the machine. There was no change in the boot sequence - the machine booted directly into Windows 7 as usual.

I managed to fix it by re-installing debugging tools for windows. To do this, I first uninstalled it, and downloaded the x64 Windows 7 SDK ISO from this link ( -us/download/details.aspx?id=8442). The file name is GRMSDKX_EN_DVD.iso. Be sure to check the SHA1 checksum of the downloaded ISO image - in my case, my first download was incomplete and the installation didn't go smoothly. I chose to install only the WinDBG tools the second time and now I can debug the kernel locally. After I downloaded the latest version of SysInternals suite, I am also able to run LiveKD without any issues.

I run into the same situation once. Yet figure out what happened to me was that I forgot to run windbg as administrator. Basically to enable local kernel debugging on Windows 7, only few steps are needed.

@dotslash I was facing the same problem. Apparently, the remote debugger version that comes with VS is not compatible with KDNET version which I was using. May be that could be problem in your case but I am not sure.

The reason I wanted to try using VS is that (I presume) I can look at the source code of my driver and step through it and examine variable, etc. And VS already knows where the PDB and sources are located. And it would automatically move my latest driver.sys over to the target.

There is a problem where after one connection, the next tries but cannot connect. It seems that the connection is not fully closed, and the target does not know, so the debugger cannot connect. I solve this problem by leaving an old test driver of mine running that does a DbgPrint periodically, but if all else fails, do a quick restart.

It is worth noting that (a while back) Scott and I spent almost 20 minutes in the office of the dev who owns this functionality, after we had complained about it not being predictable, while he tried to prove to us that it works. He WAS eventually able to demo it.

Second, the primary issue with using WinDbg from within VS is that you have to STOP DEBUGGING and disconnect from the target to make any changes to your source code. This model is far less than optimal for many kernel devs.

Installing WinDbg is trivial but is also something that will waste our time (Windows SDK, Updates etc); since its installation can be automatized, I will recommend to install WinDbg via Chocolatey. From an elevated PowerShell launch the following command:

This will download all available symbols from the Microsoft Symbol Server to your local directory at c:\symbols. If you prefer to place your downloaded symbols somewhere else choose another local path instead.

bcdedit /dbgsettings serial debugport:1 baudrate:115200

You can add the /noumex switch to the dbgsettings command to avoids user mode exceptions from causing the system to break into the kernel debugger. e.g. bcdedit /dbgsettings serial debugport:1 baudrate:115200 /noumex.

Now open an administrator prompt and use bcdedit utility to create a new entry to the boot manager like we did on Windows 7 and enable the debug mode for it. But unlike Windows 7, now we have to setup the network properties:

I'm sitting here waiting for an update to download on one of my macOS VM's in order to run a kernel debugger and take a peek at a couple of things. Unfortunately, said download is through my amazing Australian broadband:

We can debug over serial by connecting an FTDI USB-to-serial board up to the Raspberry Pi's UART, and Microsoft provide documentation for setting up kernel debugging over serial on their IoT core builds: -us/windows/iot/docs/windbg

Hooking up to the FTDI chip is documented very well in the Microsoft Dev Center article - You only need to connect three pins - GND, TX and RX. Admittedly the Raspberry Pi pinout is mildly convoluted, so I had to lookup a pinout diagram.

Enabling debugging is easy and documented in the aforementioned link. You can use a remote PowerShell session, or SSH in. I'm still somewhat uncomfortable with SSHing natively into a Windows machine, but it's pretty awesome.

Huzzah! Now we're in the debugger we can do all of our usual Windows debuggy things, similar to if you were debugging a full-blown installation of Windows 10. We can inspect process lists, set breakpoints and step or trace through, etc:

The first step is to locate the LSA process. The typical way to do this is to use the !process 0 0 command and look for a process name of LSASS.exe. The next step requires that we know the EPROCESS value for LSA, hence the enumeration. For instance:

Next, we set up a breakpoint on a particular internal LSA function that is used to determine whether a given password is accepted for a local account logon. The breakpoint changes the function to always return TRUE, such that all local account logons will succeed if they get to the point of a password check. After that, execution is resumed.

From there, you can simply reset the password for your account via the Computer Management console. Be warned that this will wipe out EFS keys and the like, however. To restore password checking to normal, either reboot the box without the kernel debugger, or use the bc* command to disable the breakpoint you set.

3a8082e126