windbg first connect then stuck on "Debuggee not connected." message during kernel debugging

Question

I am trying to do Windows kernel debugging so I have set up two machines for this purpose:

1. HOST - DEBUGGER - The computer that runs the windbg debugger
2. TARGET - DEBUGEE - The computer being debugged

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

On TARGET I've enabled kernel debugging with 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've started HOST and did the following steps:

1. start windbg
2. File->Kernel Debug->COM
3. Baud Rate: 115200, Port: COM1, Pipe: Unchecked, Reconnect: Unchecked, Resets: 0
4. OK

After this 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've restarted TARGET and choose "Windows 7 with debug" from the boot menu.

After this 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 prompt where usually commands are typed I get: Debuggee not connected. The TARGET system started as usual and I was able to use it.

Few things I've noticed:

1. COM1 port was missing on TARGET machine in Device Manager after above steps.
2. After closing windb on HOST machine and attempting to restart the TARGET it get stuck with "Shutting Down" message so I have to do a force power off.
3. After booting TARGET to "old" kernel without debugging enabled serial port is available in Device Manager.
4. After booting TARGET to "new" kernel with debugging enabled (and without HOST listening) serial port is unavailable in Device Manager.

What i am doing wrong?

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

EDIT:

Title changed.

According to this article My Kernel Debugger Won't Connect it is OK that 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 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.

I've also checked the settings described in mentioned article but they seems to be OK also:

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've tried issue kd -kl command. I suppose it should be issued only on target but to be sure I've tried both machines. You can see that there is an error regarding symbols but I think debugging should be working without them also.

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 recommendations about setting printer sharing etc. are they worth trying?

Hop

What exactly is the issue? It looks like you got the debugger attached to the target. (1) Ignore WinDbg status message. The best way to see if you're connected to the target is to try a few commands. (2) When I debug a virtual machine, the serial port that I'm using also goes missing, but it looks like you figured that out (good job). – Henceforth

Where should I type commands? In the command window of windbg I get "Debuggee not connected." and the place where commands should be typed is gray. I am complete newbie in this so maybe I am doing something wrong but when I open local exe for debugging I am able to type at the bottom of command window. – Hop

Ah I see. You need to break into the kernel in order to type commands. Click "Debug->Break" and try the following commands: (1) .reload (2) !ustr srv!SrvComputerName That should give you the target system computer name. – Henceforth

This worked! Thank you. Post it as an answer so I can accept it. Don't you know about some good kernel debugging literature? – Hop

Answer 1

It looks like you got the debugger attached to the target. (1) Ignore WinDbg status message. The best way to see if you're connected to the target is to try a few commands. (2) When I debug a virtual machine, the serial port that I'm using also goes missing, but it looks like you figured that out (good job).

In order to issue commands you need to break into the kernel. Click "Debug->Break" and try the following commands:

.reload
!ustr srv!SrvComputerName 

That should give you the target system computer name.

If you want to learn more about kernel debugging, I would check out TheSourceLens on YouTube. As for literature, I can't recommend any books, because most information I find are online. However, I would recommend checking out OSR Online. Happy debugging.

Henceforth

Obtaining the target system name was not successful but I finally get the prompt to type commands. – Hop

Could you at least see kernel debug print out? To see the kernel debug print statement use: ed Kd_DEFAULT_MASK 0xF – Henceforth

"Debug->Break"! Thanks for this. – Clyte