• Ntdebugging Blog

    My Kernel Debugger Won't Connect


    Hello ntdebugging readers, the Debug Ninja is back again with a quick blog this holiday season.  I recently encountered a situation where the kernel debugger could not connect to a Windows Server 2008 R2 system running in a Hyper-V virtual machine.  The configuration appeared correct; however, the debugger would not connect to the VM.


    In windbg you can use Ctrl+Alt+D to view the debugger’s internal information flow.  In KD use Ctrl+D followed by ENTER to toggle the output.  Enabling this output I could see that the debugger was unable to read from the debug port, and that it was getting timeouts.  The error "SYNCTARGET: Timeout." is a clear indication that the debug host cannot communicate with the debug target, especially when this error appears after a “Send Break in” message.

    SYNCTARGET: Timeout


    Because I was using a named pipe on a Hyper-V VM I knew that I didn't have a bad cable, although this is a common cause of kernel debug failures.  I also knew that the configuration of the VM was correct, and I could use the debugger for other VMs on this server.  The problem was most likely with the OS running in the VM.


    By checking Device Manager I was able to confirm that there was a problem with the configuration of the OS running in the VM.  The bcdedit settings were configured to use COM1, and this should make COM1 unavailable in the OS, however, COM1 was present in device manager.  For some reason the debugger was not capturing COM1 on boot as it was configured to.

    Device Manager


    Examining the bcd configuration of this server I found that the bcd configuration was not correct.  In the bcd store of normal Windows 7 or Windows Server 2008 R2 OS, the Windows Boot Loader sections of bcdedit have an inherit setting.  You can view this information on your system from an elevated command prompt using the command ‘bcdedit /enum all’.  Ordinarily the Windows Boot Loader inherits the {bootloadersettings}, the {bootloadersettings} inherit the {globalsettings}, and the {globalsettings} inherit the {dbgsettings}.  Without the inherit settings, the debugger configuration will not be read by the boot loader.


    Below are the bcd settings from the broken VM.  You can see that all of the normal inherited settings are missing.

    C:\Windows\system32>bcdedit /enum all


    Windows Boot Manager


    identifier              {bootmgr}

    device                  partition=C:

    path                    \bootmgr

    description             Windows Boot Manager

    locale                  en-US

    default                 {current}

    displayorder            {current}

    timeout                 30


    Windows Boot Loader


    identifier              {current}

    device                  partition=C:

    path                    \Windows\system32\winload.exe

    description             Windows Server 2008 R2 Standard (recovered)

    locale                  en-US

    osdevice                partition=C:

    systemroot              \Windows

    resumeobject            {2ec5363f-2a92-11e1-bbe4-806e6f6e6963}

    usefirmwarepcisettings  No

    debug                   Yes


    Resume from Hibernate


    identifier              {2ec5363f-2a92-11e1-bbe4-806e6f6e6963}

    device                  partition=C:

    path                    \Windows\system32\winresume.exe

    description             Windows Server 2008 R2 Standard (recovered)

    locale                  en-US

    inherit                 {resumeloadersettings}

    filedevice              partition=C:

    filepath                \hiberfil.sys

    debugoptionenabled      Yes


    Windows Memory Tester


    identifier              {memdiag}

    device                  partition=C:

    path                    \boot\memtest.exe

    description             Windows Memory Diagnostic

    locale                  en-US


    Debugger Settings


    identifier              {dbgsettings}

    debugtype               Serial

    debugport               1

    baudrate                115200


    Because my only interest in this VM was to get the debugger working, I did not add all of the missing settings to the bcd store.  I was able to force the debugger configuration to be read on boot using this command:

    bcdedit /set inherit {dbgsettings}


    I hope this helps the next time you are trying to configure a debugger and it does not work.  Remember that we don't just need the debugger to be turned on and be configured; we need the settings to be inherited as well.

  • Ntdebugging Blog

    Configuring a Hyper-V VM For Kernel Debugging


    Yesterday's blog prompted some questions about how to set up a debugger for a Windows OS running in a Hyper-V VM.  I was surprised that I wasn't able to find good, publicly available, Microsoft issued documentation for this configuration.


    The first step is to configure the Windows OS in the VM to enable a kernel debugger on COM1.  One would use these same steps if you were preparing the OS to be debugged using a null modem cable.  Hyper-V will allow us to redirect the COM port so that we don't need such a cable.

    1. Start an administrative command prompt.
    2. Turn on debugging with this command:
      bcdedit /debug on
    3. Configure the debugger to use COM1 with this command:
      bcdedit /dbgsettings SERIAL DEBUGPORT:1 BAUDRATE:115200
      Note that these are the default settings and already exist in most bcd stores.  However setting them again won't damage anything, and guards against a situation where the dbgsettings have been previously modified.
    4. Reboot so that the boot loader can read the new settings and configure the OS for debugging.



    Next, configure Hyper-V to redirect the COM1 port to a named pipe.  We will use this pipe in place of a traditional null modem cable.

    1. Open Hyper-V Manager and browse to the settings page of the VM you configured to debug.
    2. Under the Hardware list choose COM 1.
    3. Change the Attachment to 'Named pipe:' and provide a pipe name.
      1. Note that the Hyper-V Manager provides the complete path to your named pipe.  Make a note of this path as you will need it in the next step.



    After the OS and the VM are configured for debugging, we need to connect a debugger.

    1. On the Hyper-V parent partition download and install the Debugging Tools for Windows from http://msdn.microsoft.com/en-us/windows/hardware/gg463009.
    2. After installing the debugging tools you will have a ‘Debugging Tools for Windows’ entry in your start menu.
      1. From this folder right click ‘WinDbg’ and choose ‘Run as administrator’.  Windbg needs administrative rights to connect to the pipe.
    3. In windbg open the File menu and choose ‘Kernel Debug’.
    4. Enter a Baud Rate of 115200, to match the settings made in the VM.
    5. Enter the Port that you configured in the VM settings page.
      1. To connect to the pipe remotely, substitute the '.' in the path with the Hyper-V server name.
    6. Ensure that the Pipe and Reconnect boxes are checked.
    7. Set Resets to 0.
    8. Click OK to start debugging.
    9. Windbg should display the string ' Waiting to reconnect...'



    To test the debugger connection in windbg, from the ‘Debug’ menu choose ‘Break’.  This should cause the server to break into the debugger and display a kd> prompt.  Please note that breaking into the debugger will cause the OS running in the VM to halt until you tell the debugger to go, the OS will appear to be hung during this time.  The command 'g' followed by Enter will tell the debugger to ‘go’ causing the VM to resume operation.



Page 1 of 1 (2 items)