windbg first connect then stuck on "Debuggee not connected." message during kernel debugging
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.
Wakan Tanka
Enthusiastic and passionate for computers and technology, my workhorses: perl, bash, python, tcl/tk, R. LaTeX, Unix
Updated on June 04, 2022Comments
-
Wakan Tanka almost 2 years
I am trying to do Windows kernel debugging so I have set up two machines for this purpose:
- HOST - DEBUGGER - The computer that runs the windbg debugger
- 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:
- start windbg
- File->Kernel Debug->COM
- Baud Rate: 115200, Port: COM1, Pipe: Unchecked, Reconnect: Unchecked, Resets: 0
- 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:
- COM1 port was missing on TARGET machine in Device Manager after above steps.
- 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.
- After booting TARGET to "old" kernel without debugging enabled serial port is available in Device Manager.
- 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?