kernel debugger

With VirtualPC I did this:

1. On the virtual machine settings I've set the option "named pipe" (I suppose that is the English name of the option) with "\\.\pipe\VirtualPC_XP_COM1".

2. I've started the virtual pc and edited boot.ini to look like this:

Code:

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /noexecute=optin /fastdetect
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Debugging with Cable" /fastdetect /debug /debugport=COM1 /baudrate=115200

3. I've restarted the virtual pc and on boot I've selected "Debugging with Cable" BUT WITHOUT pressing enter yet.

4. Later, I've started WinDbg and pressed Ctrl+K, checked the pipe option, set Port to "\\.\pipe\VirtualPC_XP_COM1" and clicked Accept button.

5. Finally, I've pressed enter on the virtual pc and windows booted in debug mode.

Now you should see on WinDbg something like this:

Code:

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

Opened \\.\pipe\VirtualPC_XP_COM1
Waiting to reconnect...
Connected to Windows XP 2600 x86 compatible target, ptr64 FALSE
Kernel Debugger connection established.
Symbol search path is: SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols
Executable search path is: 
Windows XP Kernel Version 2600 UP Free x86 compatible
Built by: 2600.xpsp_sp2_rtm.040803-2158
Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055ab20
System Uptime: not available
ERROR: DavReadRegistryValues/RegQueryValueExW(4). WStatus = 5
ERROR: DavReadRegistryValues/RegQueryValueExW(5). WStatus = 5
ERROR: DavReadRegistryValues/RegQueryValueExW(6). WStatus = 5

And that was all. I have used this to do some testings with NDIS and general IRQL management when I was patching a shitty Huawei modem driver (both hardware and software are plain shit but very cheap for ISP). I don't have one of those modems myself but the people that tried the patched driver reported that it was working good and that the BSODs ceased (which was very fortunate because the patch was as simple as removing two calls to NdisMSleep).