Proper way to use Visual Studio or WinDbg Kernel Debugger

Hi, I’m fairly new to Windows Driver Development, and I’m trying to setup my debug environment to the way it should be. Currently, I’m using Visual Studio to deploy the driver to the target machine (via Build or F5/Debugging Tools for Windows - Kernel Debugger). However, it seems that I can’t attach the debugger to my target’s kernel. In Visual Studio, when all the steps/tasks of Driver Installation has passed, nothing happens after that. When I try to use WinDbg on my host to attach the debugger to the target (over the network), it stops at “Waiting to reconnect”. Thus, the way I’m trying to debug my drivers so far is running WinDbg’s kernel debugger locally on my target, using !dbgprint to display the debug messages (the debug messages don’t automatically print in the debugger console). Also, when a bug check occurs, the local debugger can’t catch it before the target blue screens.

From what I’ve read, I don’t think this is a very efficient way of doing this, so I’m hoping that someone could please help me fix this issue? It would be very helpful if I could make the Visual Studio Kernel Debugger attach to the target’s kernel.

Thanks

And the transport physical interface is serial? ethernet? usb? firewire?

Mark Roddy

On Tue, Feb 10, 2015 at 11:33 AM, wrote:

> Hi, I’m fairly new to Windows Driver Development, and I’m trying to setup
> my debug environment to the way it should be. Currently, I’m using Visual
> Studio to deploy the driver to the target machine (via Build or
> F5/Debugging Tools for Windows - Kernel Debugger). However, it seems that I
> can’t attach the debugger to my target’s kernel. In Visual Studio, when all
> the steps/tasks of Driver Installation has passed, nothing happens after
> that. When I try to use WinDbg on my host to attach the debugger to the
> target (over the network), it stops at “Waiting to reconnect”. Thus, the
> way I’m trying to debug my drivers so far is running WinDbg’s kernel
> debugger locally on my target, using !dbgprint to display the debug
> messages (the debug messages don’t automatically print in the debugger
> console). Also, when a bug check occurs, the local debugger can’t catch it
> before the target blue screens.
>
> From what I’ve read, I don’t think this is a very efficient way of doing
> this, so I’m hoping that someone could please help me fix this issue? It
> would be very helpful if I could make the Visual Studio Kernel Debugger
> attach to the target’s kernel.
>
> Thanks
>
> —
> WINDBG is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

Over the local network basically. My host is connected through wired ethernet and my host is connected through WiFi

The connection between your debugger system and your test system needs to
be wired ethernet not wifi. You have to enable ethernet debugging in VS and
have it do its thing to configure the test system, or manually set up
ethernet debugging for windbg. I prefer the latter path by the way. Also
the test system has to have a supported ethernet controller.

Mark Roddy

On Tue, Feb 10, 2015 at 1:37 PM, wrote:

> Over the local network basically. My host is connected through wired
> ethernet and my host is connected through WiFi
>
> —
> WINDBG is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

Oh I see, thanks! Is it also a way to directly connect the host to the target through wired ethernet (as opposed to using a hub or switch)?

No, you don’t really need to make a point to point connection, that will
just complicate things.

Mark Roddy

On Wed, Feb 11, 2015 at 12:46 PM, wrote:

> Oh I see, thanks! Is it also a way to directly connect the host to the
> target through wired ethernet (as opposed to using a hub or switch)?
>
> —
> WINDBG is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

Just in case you’re interested in a cheap Intel card for network debugging, the EXPI9301CTBLK is the one I’m currently using and it works like a charm. I hadn’t had luck with Realtek, but with the Intel just worked right away.

Everyone, thanks for your input!

Tim, I’ll try to see if I could get spare equipment somewhere, but definitely thanks for pointing out that WiFi won’t work and point to point ethernet will just also complicate things.

Antonio, thanks, but I can’t really change the internal hardware of my setup. My host is either a laptop at home or a provided desktop at work, and my target is a touchscreen laptop.

Oh, and one more thing. Is dbgprint! the only way to see debug messages from a driver? Or are they supposed to automatically display on the kernel debug console?

Once you have two machines you will see them appear as they are printed
(assuming that you have enabled DbgPrint output:
http://www.osronline.com/article.cfm?article=295)

-scott
OSR
@OSRDrivers

wrote in message news:xxxxx@windbg…

Oh, and one more thing. Is dbgprint! the only way to see debug messages from
a driver? Or are they supposed to automatically display on the kernel debug
console?

Folks, sorry for interrupting the discussion:

Seems like either I’m too stupid to physically set the things up, correctly
or microsoft didn’t explain enough detailed how to wire up host and target:
I followed all steps and now i’m able to ping both host–>target and vice versa.
however im not able to get the even slightest connection from host to target.
we have a fritzbox 7490 and i did port forwarding of connection port 50002 to the target computer or the host computer but none worked so far.
my setup is: host = windows server 2008r2 x64, firewall completely off
target=laptop with windows 8.1 x64, firewall completely off, ethernet card supported and busparams set correctly, dhcp=yes, and i also have bootdebug btw.
target has no testsigning, host has it. (but that migth not addrezs my issue)
both host and target wired to the same zyxel mini switch if this interesting anyhow.
target ipv4 settings are ‘use automatic ip address’.
host ipv4 settings are the very same.
dns also automatic (but thats not about pure connection)

i keep getting “opened winsock 2.0, waiting to reconnect”.
sorry, but i have absolutely NO IDEA what i doing wrong.
any help highly apperciated, if such seemingly simple stuff (as stated in kernel debugging over a network cable M$ article) not works and i have no clue why not I get quite upset.

I forgot:

Best Regards
Microwave89

On Sat, Feb 14, 2015 at 6:09 PM, wrote:

> fritzbox 7490

Are you actually trying to do this through a NAT? Otherwise port forwarding
on your 7490 is irrelevant.

Host should not have any bcdedit parameters modified - all the
modifications are on the target. Testsigning is irrelevant to getting a
debug connection. Also turn off bootdebug, it is again irrelevant to kernel
debugging and might get in the way.

You should capture the output from “bcdedit” and post it here. That would
describe your settings more accurately. Also post the exact command line
you are using for starting windbg.

Also CTRL ALT D will toggle verbose output from the debugger (and in my
experience while setting up simply CTL D does the same.) CTRL R will
attempt to re-establish the connection.

Finally: wireshark. Its free its easy it will debug the lan level issues.

Mark Roddy

Ok, thanks for answer.
Will do so on friday, at the moment I’m not at home for a few days.
Host and target are connected to the same switch/hub so they should be in the same subnet, so there should be no NAT in between.

A few more things:

  • Do host and target have to be connected to the same hub/switch?
  • Is it important if it is a hub (level 1) or a switch (level 2)?
  • Why will point to point connection complicate things? (refer to answer way above)
  • The Windows 8.1 laptop (target) has a Intel Centrino WLAN card at PCI. Must it be disabled?
  • What happens if the encryption keys do not match, should occur an error other than “trying to reconnect”?
  • Where should I run WireShark? On both, host and target?
  • To prevent loosing to much time, what are telltale signs I should have a keen eye on?
  • I completely don’t understand: Which computer must have an internet connection, in order to get symbols? Or is recommended, to entirely cut both computers off the internet?
  • Are the default Windows network settings for IP4 suitable?
  • If the Router (Fritzbox) provides the IP addresses, how is the debug driver supposed to assign an IP to the target? (Microsoft states something like that).

Can somebody point me optionally to a good (hands on) resources on net debugging, perhaps? Microsoft explains it way too generic, in my opinion…

Best Regards

Microwave89

The target machine IP settings that you can control from UI are completely irrelevant. They are for NDIS layer drivers. KDNET runs directly on the metal.

From an elevated command prompt on the target machine run

reg query hklm\system\currentcontrolset\services\kdnet

If you get an KdInitStatus result that is non zero, then KDNET failed to initialize properly.

The KdInitResultString should give you some reasonable idea what is actually wrong.

If your KdInitStatus is zero, then KDNET should be running on the target.

Run ipconfig /all from the command line, and see if you have an Ethernet adapter with the following description:

Microsoft Kernel Debug Network Adapter.

If you do, and if it has been assigned an IPv4 address, and has DNS server addresses assigned, etc, then KDNET is running properly on the target. Especially if you have net connectivity, and there is only 1 NIC plugged in on the machine.

In that case, the problem is on the host. Something is causing packets to be dropped.

The simplest way to get kdnet running is to plug target and host into the same physical network switch. On a network that has a DHCP server. Leave target KDNET setting to DHCP yes.

Both machines should get an address from the DHCP server (likely your router if a home network).

As long as you have your host setup to let packets through to the debugger, things should just work.

Joe.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Saturday, February 14, 2015 3:09 PM
To: Kernel Debugging Interest List
Subject: RE:[windbg] Proper way to use Visual Studio or WinDbg Kernel Debugger

Folks, sorry for interrupting the discussion:

Seems like either I’m too stupid to physically set the things up, correctly or microsoft didn’t explain enough detailed how to wire up host and target:
I followed all steps and now i’m able to ping both host–>target and vice versa.
however im not able to get the even slightest connection from host to target.
we have a fritzbox 7490 and i did port forwarding of connection port 50002 to the target computer or the host computer but none worked so far.
my setup is: host = windows server 2008r2 x64, firewall completely off target=laptop with windows 8.1 x64, firewall completely off, ethernet card supported and busparams set correctly, dhcp=yes, and i also have bootdebug btw.
target has no testsigning, host has it. (but that migth not addrezs my issue) both host and target wired to the same zyxel mini switch if this interesting anyhow.
target ipv4 settings are ‘use automatic ip address’.
host ipv4 settings are the very same.
dns also automatic (but thats not about pure connection)

i keep getting “opened winsock 2.0, waiting to reconnect”.
sorry, but i have absolutely NO IDEA what i doing wrong.
any help highly apperciated, if such seemingly simple stuff (as stated in kernel debugging over a network cable M$ article) not works and i have no clue why not I get quite upset.


WINDBG is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Whooow, really thanks for your contribution! Almost can’t wait until friday! Your post explains a whole bunch of Things, thank you so much!
So the only question is (this might be a dumb one):
It doesn’t have any influence whether the router assigns the both computer a “preferred” IP address or not, does it? To be exact, on FritzBox I may check a box saying “static IP address” (meant withing a LAN, setting has nothing to do with a static ISP address), but as long as I understand, I should be fine as long as both PCs automatically get an IP address and the other Things work, too.

Best Regards

Microwave89

Hi Windbg list!

I attemped once more to get the kernel debugger working (first of all, using the old setup) and luckily, this time I succeeded within no time.
My host is now a Windows 7 SP1 x64 on a MacBook Pro and the target is a Windows 10 Build 9926 running on my dedicated target machine (my default notebook).
I guess, either the /bootdebug option or my sligthly screwed up Windows 8.1 must have gotten in my way, last week. I also changed the port to 49153, perhaps this might also be a reason…

By delving into the private internals of the disk read/write routine, I have then been able to figure out that the instruction @ storahci!ActivateQueue+0x379 amongst further things switches the harddrive LED on.
Hence, the bare metal debugging over ethernet is working like a charm, now.

Best Regards

Microwave89