Windbg will connect first, then stuck on "Debuggee not connected". message while debugging kernel

I am trying to debug the Windows kernel, so I created two machines for this purpose:

  • HOST - DEBUGGER - the computer running the windbg debugger
  • TARGET - DEBUGEE - the computer is being debugged

Both HOST and TARGET run Windows 7 32 bit and both are installed on Windows Driver Kit 8.0. I did the following steps:

In TARGET I have enabled kernel debugging with the following commands:

bcdedit /copy {current} /d "Windows 7 wih debug"
bcdedit /debug {02b760e4-eafc-11e4-8847-ac1155aec81a} on
bcdedit /dbgsettings serial debugport:1 baudrate:115200
bcdedit /set {bootmgr} displaybootmenu yes
bcdedit /timeout 10

      

Then I started HOST and did the following steps:

  • start windbg
  • File-> Kernel Debug-> COM
  • Baud Rate: 115200, Port: COM1, Pipe: Unchecked, Connect: Unchecked, Resets: 0
  • OK

After that, my windbg command window on HOST looks like this:

Microsoft (R) Windows Debugger Version 6.2.9200.20512 X86
Copyright (c) Microsoft Corporation. All rights reserved.

Opened \\.\COM1
Waiting to reconnect...

      

Then I restarted TARGET and selected "Windows 7 Debugged" from the boot menu.

After that, my windbg command window on HOST looks like this:

Microsoft (R) Windows Debugger Version 6.2.9200.20512 X86
Copyright (c) Microsoft Corporation. All rights reserved.

Opened \\.\COM1
Waiting to reconnect...
Connected to Windows 7 7601 x86 compatible target at (Tue May  5 08:23:33.992 2015 (UTC - 7:00)), ptr64 FALSE
Kernel Debugger connection established.
Symbol search path is: SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols
Executable search path is: 
Windows 7 Kernel Version 7601 MP (1 procs) Free x86 compatible
Built by: 7601.17514.x86fre.win7sp1_rtm.101119-1850
Machine Name:
Kernel base = 0x82611000 PsLoadedModuleList = 0x8275b850
System Uptime: not available

      

But instead of the prompt where the commands are usually typed, I get: Debuggee not connected.

The TARGET system started as usual, and I was able to use it.

A couple of things I noticed:

  • COM1 port was missing on TARGET machine in device manager after above.
  • After closing windb on the HOST machine and trying to restart TARGET, it got stuck with "Shutting Down" message, so I have to turn off the power supply.
  • After loading TARGET into the "old" kernel without debugging, the enabled serial port is available in the device manager.
  • After loading TARGET into a "new" kernel with debugging enabled (and no HOST listening), the serial port is not available in device manager.

What am I doing wrong?

PS: Both machines are virtual guests on XEN. PPS: Connection working 100%, tested on kernel without debug enabled and with putty

EDIT:

The name has been changed.

According to this article, My Kernel Debugger won't connect , it's normal COM1 is missing:

By checking Device Manager, I was able to confirm that there was a problem with the configuration of the OS running in the virtual machine. Bcdedit was 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 did not build COM1 at boot as it was configured to.

I also checked the options described in the article mentioned, but they seem to be in order as well:

C:\>bcdedit

Windows Boot Manager
--------------------
identifier              {bootmgr}
device                  partition=\Device\HarddiskVolume1
description             Windows Boot Manager
locale                  en-US
inherit                 {globalsettings}
default                 {default}
resumeobject            {02b760e0-eafc-11e4-8847-ac1155aec81a}
displayorder            {default}
                        {current}
toolsdisplayorder       {memdiag}
timeout                 10
displaybootmenu         Yes

Windows Boot Loader
-------------------
identifier              {default}
device                  partition=C:
path                    \Windows\system32\winload.exe
description             Windows 7
locale                  en-US
inherit                 {bootloadersettings}
recoverysequence        {02b760e2-eafc-11e4-8847-ac1155aec81a}
recoveryenabled         Yes
osdevice                partition=C:
systemroot              \Windows
resumeobject            {02b760e0-eafc-11e4-8847-ac1155aec81a}
nx                      OptIn

Windows Boot Loader
-------------------
identifier              {current}
device                  partition=C:
path                    \Windows\system32\winload.exe
description             Windows 7 wih debug
locale                  en-US
inherit                 {bootloadersettings}
recoverysequence        {02b760e2-eafc-11e4-8847-ac1155aec81a}
recoveryenabled         Yes
osdevice                partition=C:
systemroot              \Windows
resumeobject            {02b760e0-eafc-11e4-8847-ac1155aec81a}
nx                      OptIn
debug                   Yes

      

EDIT2

Based on this SO answer, I tried to execute the command kd -kl

. I guess it should only be fired on target, but I'm sure I've tried both machines. You can see there is a bug regarding symbols, but I think debugging should work without them as well.

HOST:

c:\Program Files\Windows Kits\8.0\Debuggers\x86>kd -kl

Microsoft (R) Windows Debugger Version 6.2.9200.20512 X86
Copyright (c) Microsoft Corporation. All rights reserved.

The system does not support local kernel debugging.
Local kernel debugging requires Windows XP, Administrative privileges.
Only a single local kernel debugging session can run at a time.
Local kernel debugging is disabled by default since Windows Vista, you must run
"bcdedit -debug on" and reboot to enable it.
Debuggee initialization failed, HRESULT 0x80004001
    "Not implemented"

      

TARGET:

c:\Program Files\Windows Kits\8.0\Debuggers\x86>kd -kl

Microsoft (R) Windows Debugger Version 6.2.9200.20512 X86
Copyright (c) Microsoft Corporation. All rights reserved.

Connected to Windows 7 7601 x86 compatible target at (Tue May  5 12:13:02.806 20
15 (UTC - 7:00)), ptr64 FALSE
Symbol search path is: *** Invalid ***
****************************************************************************
* Symbol loading may be unreliable without a symbol search path.           *
* Use .symfix to have the debugger choose a symbol path.                   *
* After setting your symbol path, use .reload to refresh symbol locations. *
****************************************************************************
Executable search path is:
*********************************************************************
* Symbols can not be loaded because symbol path is not initialized. *
*                                                                   *
* The Symbol Path can be set by:                                    *
*   using the _NT_SYMBOL_PATH environment variable.                 *
*   using the -y <symbol_path> argument when starting the debugger. *
*   using .sympath and .sympath+                                    *
*********************************************************************
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for ntkr
pamp.exe -
Windows 7 Kernel Version 7601 (Service Pack 1) MP (1 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7601.17514.x86fre.win7sp1_rtm.101119-1850
Machine Name:
Kernel base = 0x82653000 PsLoadedModuleList = 0x8279d850
Debug session time: Tue May  5 12:13:02.822 2015 (UTC - 7:00)
System Uptime: 0 days 2:48:38.649
lkd>

      

There are also some guidelines for setting up printer sharing, etc., are they worth trying?

+3


source to share


2 answers


It looks like you have a debugger attached to the target. (1) Ignore WinDbg status message. The best way to find out if you are connected to a target is to try multiple commands. (2) When I debug the VM, the serial port I am using also disappears, but it looks like you figured it out (good job).

To issue commands, you need to break into the core. Click "Debug-> Break" and try the following commands:

.reload
!ustr srv!SrvComputerName 

      



This should give you the computer name of the target system.

If you want to learn more about kernel debugging I would take a look at TheSourceLens on YouTube. In terms of literature, I cannot recommend any books because most of the information I find is online. However, I would recommend checking out OSR Online . Happy debugging.

+4


source


You can try Bellavista.exe to create a new debug entry and find differences.



0


source







All Articles