{"id":271,"date":"2008-03-06T11:34:08","date_gmt":"2008-03-06T11:34:08","guid":{"rendered":"https:\/\/driverentry.com.br\/en\/2008\/03\/06\/step-into-kernel-vista-usb2\/"},"modified":"2026-07-27T20:44:44","modified_gmt":"2026-07-27T20:44:44","slug":"step-into-kernel-vista-usb2","status":"publish","type":"post","link":"https:\/\/driverentry.com.br\/en\/2008\/03\/06\/step-into-kernel-vista-usb2\/","title":{"rendered":"Step into Kernel (Vista + USB2)"},"content":{"rendered":"
\"\"<\/a><\/div>\n

\"\"<\/p>\n

I have already mentioned into another post<\/a> that it is possible to perform Kernel Debugging via a 2.0 USB port. In this post I’m going to demonstrate such a 2.0 USB connection working. Yeah, that’s a good thing. So let’s stop this idle talk and go to the business. If you know nothing about Kernel Debugging, you can read this post<\/a> which brings the concepts and basic steps on the subject or you can ask yourself “How have I ever gotten into this site?”<\/em> and return to ORKUT<\/a>.<\/p>\n

The USB bus does not allow us to have direct connections between two computers. In order to use a USB port for this purpose, we must rely on the additional hardware helping. Although it is named as Debug Cable<\/strong>, this is a small device that connects computers via USB ports. I do not know if there are already other manufacturers for the Debug Cable, but the one I’m using at this experiment is NET20DC<\/a>.<\/p>\n

Using the Debug Cable<\/h3>\n

Using the Debug Cable is a luxury that only Windows Vista<\/a> and posterior systems can enjoy. It needs to be plugged into a 2.0 USB port without going through any hub at the TARGET <\/strong>side. But how am I supposed to know for sure which of my ports is actually 2.0?<\/p>\n

An easy way to know that, especially for those ones who have installed WDK,<\/strong> is to build the USBView<\/strong> sample which is in the “C:\\WinDDK\\6000\\src\\usb\\USBView”<\/em> folder of WDK. This program lists the drivers and their respective connected USB devices. Thus, when connecting the Debug Cable to the TARGET machine, USBView should inform us what port this new device is connected to. Note that in this window we can see which controller the port we are using belongs to.<\/p>\n

\"\"<\/div>\n

Windows will prompt a driver when detecting this new USB device presence. No driver must be installed to use the Debug Cable on the TARGET side. So, you can select “Do not show this message again for this device”<\/em> in the window shown below. Not installing any driver to the TARGET side makes sense. Remember that this interface will be used by BIOS of the TARGET machine and its control wont be passed to the operating system core. Do not forget, yet, there is another requirement to use the Debug Cable. The TARGET machine’s BIOS must implement this debug interface control. The most unfortunate part of this story is about checking whether your BIOS offers such support. All that you need to do is just to try. That means you may have the Debug Cable, a free 2.0 USB port and the cables but even that, there is a risk of not connecting it because TARGET BIOS might not support the debug interface. I’m glad to know that my laptop offers this support and have not spent this money for anything importing the Debug Cable. Phew!<\/p>\n

\"\"<\/div>\n

Modifying Boot.ini<\/h3>\n

Sorry? Boot.ini? I’m sorry to tell you that the Boot.ini<\/em> has gone way. Windows Vista uses a new architecture called Boot Configuration Data<\/a> (BCD). That has been the end for Boot.ini file. To edit the BCD settings, we use the BCDEdit.exe <\/strong>tool, a console application that needs to be run with administrative rights. Executing this tool without any parameters returns it to the following output.<\/p>\n

\"\"<\/div>\n

To configure the system in order to have two boot options, the one with enabled debugging and the other isn’t, follow the described steps below. The Boot Manager<\/strong> managers the Boot Loaders<\/strong> which are either possible to be the other operating systems, even prior to Windows Vista or configuration sets of the same system. Each of these items is identified by a GUID. Note that the first command makes a copy of the current configuration to the one contains the “Windows Vista Guinea Pig Mode”<\/em> string as a description. In response to this copy, the tool returns a resulting GUID of the copy. Also, observe that the second command enables the kernel debugging to the setting identified by the GUID just received. Right now, if we take a look at the settings, it will have a result like the same image being displayed below.<\/p>\n

\"\"<\/div>\n

Nice!!! Now we have to configure the media to be used by the Kernel Debugger. I believe that most systems still use serial ports for this purpose. In this case, the most common configuration is to use the COM1 serial port with a 115200 baud rate. To configure these settings, use the following command line. To see the current settings, just run the second command line as it is shown below.<\/p>\n

\"\"<\/div>\n

If you do not know how to use the serial port as a communication way for the kernel debug, this is the post<\/a> that talks about it. However, in this post I am commenting about kernel debug using a 2.0 USB as a communication way. In this case, the settings are described at the command line that is shown below. The TARGETNAME<\/strong> is able to receive any name. I have used the “WINDBG”<\/em> name for obvious reasons, but you can use anyone.<\/p>\n

\"\"<\/div>\n

As you may have guessed, the settings on the debug mode of communication is global, that is not linked to one or another boot configuration identified by a GUID.<\/p>\n

I believe that on the TARGET side everything is ready to make the link. Thus, when you reboot the victim machine, the following menu will be displayed by the Boot Manager:<\/p>\n

\"\"<\/div>\n

Configuring the HOST<\/h3>\n

At the HOST side of this game, we must add the driver that controls the Debug Cable to it and allow Windbg to use this device. Although I’m using Windows Vista on the HOST side, nothing would prevent me from using Windows 2000 or higher on this side of the conversation. The fun starts when you plug the device and click “Locate and install driver (recommended)” <\/em>into the “New Hardware Found” <\/em>window that has already appeared into this post. At this time, Windows searches for the driver at Windows Update database.<\/p>\n

\"\"<\/div>\n

The thing starts to get funny when Windows “asks” me to insert the disk that coming with the Debug Cable. Only two words had been on my mind at that moment, “What disk?”<\/em>. Without some other options, I clicked on “I do not have that damn disk! Are you crazy? Show me anything, for the God sake.”<\/em> Some of you might even have this sequence of windows decorated by just not finding drivers for all devices you have had.<\/p>\n

\"\"<\/div>\n

Finally, when the last window has been shown to me, a light came to me, just like one of those brilliant ideas that I have had every leap year. That’s when I thought to myself “Now I know! I am going to visit the manufacturer’s website and look for a support session.”<\/em><\/p>\n

And at the manufacturer’s web site…<\/p>\n

\"\"<\/div>\n

And at the Microsoft’s web site…<\/p>\n

\"\"<\/div>\n

In the end, I sent this e-mail to get any sign that I had not thrown my money into the trash can. Less than an hour after, I got the answer with a list of requirements and steps to be followed; but the most important thing had just been revealed to me at the end.<\/p>\n

\"\"<\/div>\n

I knew I could count on Microsoft intelligence and agility to resolve this but, for those who are reading this post, my tip is: When Windows prompts for new device driver, point out the “C:\\Program Files\\Debugging Tools for Windows\\usb”<\/em> folder.<\/p>\n

So, I’m glag to show you this next window into the figure below:<\/p>\n

\"\"<\/div>\n

Configuring WinDbg<\/h3>\n

\"\"<\/p>\n

Now it’s children’s play. Select the “Kernel Debug …”<\/em> item from the “File”<\/em> menu. Click on the “USB 2.0”<\/em> tab and type the same TARGETNAME you have chosen at TARGET configuration with BCDEdit.exe. In my case, the name is WINDBG as it is displayed at the figure.<\/p>\n

Clicking OK, the WinDbg command window should display the text highlighted in red below and wait for the connect completion. The output below was obtained with a CTRL+Break<\/em> after having the debugger connected.<\/p>\n

\n
Microsoft (R) Windows Debugger Version 6.8.0004.0 AMD64<\/pre>\n
Copyright (c) Microsoft Corporation. All rights reserved.<\/pre>\n
 <\/pre>\n
Using USB2 for debugging<\/pre>\n
Waiting to reconnect...<\/pre>\n
USB2: Write opened<\/pre>\n
Connected to Windows Vista 6000 x86 compatible target, ptr64 FALSE<\/pre>\n
Kernel Debugger connection established.<\/pre>\n
Symbol search path is: SRV*c:\\websymbols*http:\/\/msdl.microsoft.com\/download\/symbols<\/pre>\n
Executable search path is:<\/pre>\n
Windows Vista Kernel Version 6000 MP (1 procs) Free x86 compatible<\/pre>\n
Built by: 6000.16584.x86fre.vista_gdr.071023-1545<\/pre>\n
Kernel base = 0x82000000 PsLoadedModuleList = 0x82111e10<\/pre>\n
System Uptime: not available<\/pre>\n
Break instruction exception - code 80000003 (first chance)<\/pre>\n
*******************************************************************************<\/pre>\n
*                                                                             *<\/pre>\n
*   You are seeing this message because you pressed either                    *<\/pre>\n
*       CTRL+C (if you run kd.exe) or,                                        *<\/pre>\n
*       CTRL+BREAK (if you run WinDBG),                                       *<\/pre>\n
*   on your debugger machine's keyboard.                                      *<\/pre>\n
*                                                                             *<\/pre>\n
*                   THIS IS NOT A BUG OR A SYSTEM CRASH                       *<\/pre>\n
*                                                                             *<\/pre>\n
* If you did not intend to break into the debugger, press the \"g\" key, then   *<\/pre>\n
* press the \"Enter\" key now.  This message might immediately reappear.  If it *<\/pre>\n
* does, press \"g\" and \"Enter\" again.                                          *<\/pre>\n
*                                                                             *<\/pre>\n
*******************************************************************************<\/pre>\n
nt!RtlpBreakWithStatusInstruction:<\/pre>\n
820818d0 cc              int     3<\/pre>\n
0:kd><\/pre>\n<\/div>\n
Now the easy part has been finished. The next steps are referring to investigate the issue, however this will be described in a future post.<\/p>\n
I hope having helped.
\nCYA \ud83d\ude42<\/p>\n","protected":false},"excerpt":{"rendered":"
I have already mentioned into another post that it is possible to perform Kernel Debugging via a 2.0 USB port. In this post I’m going to demonstrate such a 2.0 USB connection working. Yeah, that’s a good thing. So let’s stop this idle talk and go to the business. If you know nothing about Kernel […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"pagelayer_contact_templates":[],"_pagelayer_content":"","footnotes":""},"categories":[1],"tags":[],"class_list":["post-271","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/posts\/271","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/comments?post=271"}],"version-history":[{"count":3,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/posts\/271\/revisions"}],"predecessor-version":[{"id":296,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/posts\/271\/revisions\/296"}],"wp:attachment":[{"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/media?parent=271"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/categories?post=271"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/tags?post=271"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}