Help with using WinDbg over Ethernet

Hi all,
I’ve taken Tim’s advice and borrowed somebody’s laptop to serve as a WinDbg host.
Now I’m having trouble getting a debug session started.

The host runs Windows 7, and I’ve installed WinDbg on it.

On the target, I’ve set the debug parameters thus…

C:\WINDOWS\system32>bcdedit /dbgsettings
busparams 6.0.0
key 1sgd08a5j4nx1.1wneyark192e4.2fddbmwa96ee7.dr245937voot
debugtype NET
hostip 192.168.0.104
port 50000
dhcp Yes

The hostip is what I get from ipconfig on the host.

On the host WinDbg, I go into File : Kernel Debug…, select the NET tab, and enter port number 50000. There is no place to enter the key!

I click OK, and the Command window opens, showing…

Using NET for debugging
Opened WinSock 2.0
Waiting to reconnect…
Connected to target 192.168.0.100 on port 50000.

At the bottom, it reads “Debuggee not connected”, and it doesn’t allow me to enter anything there.

This is the correct IP for the target, but I don’t know how the host found that out.

If I put a different port in the Kernel Debug… dialog, I don’t get the last “Connected…” line, so I interpret that to mean that some sort of handshake was established with the target.

So what’s wrong here??? Some sort of version mismatch between target and host?

I have a wireless router. The target is ethernet connected to the router, and the target is wireless connected to the router. That’s supposed to be OK, as I understand it.
The host and target can both ping themselves and each other by their IP addresses.

I enabled the firewall on the target as requested the first time I tried Kernel Debug…

I’ve also tried disabling the firewalls on both ends, to no effect.

I’m going to try installing a matching version of Debug Tools on the target, and see if that helps. I don’t know if the code that implements the target interface is built into Windows 10 or it comes from the Debug Tools. It’s worth a try.

Hello,

If I’m not mistaken, the Win7 doesn’t support the debugging over Ethernet.
For Win7 available 1394, RS232 or pipe.
Therefore you have to use ether FireWire or Com-port.
Debugging over Ethernet supported by Win10.

BR,
Dzmitry

On Tue, Mar 6, 2018 at 8:46 AM, xxxxx@rolle.name wrote:

> Hi all,
> I’ve taken Tim’s advice and borrowed somebody’s laptop to serve as a
> WinDbg host.
> Now I’m having trouble getting a debug session started.
>
> The host runs Windows 7, and I’ve installed WinDbg on it.
>
> On the target, I’ve set the debug parameters thus…
>
> C:\WINDOWS\system32>bcdedit /dbgsettings
> busparams 6.0.0
> key 1sgd08a5j4nx1.1wneyark192e4.
> 2fddbmwa96ee7.dr245937voot
> debugtype NET
> hostip 192.168.0.104
> port 50000
> dhcp Yes
>
> The hostip is what I get from ipconfig on the host.
>
> On the host WinDbg, I go into File : Kernel Debug…, select the NET tab,
> and enter port number 50000. There is no place to enter the key!
>
> I click OK, and the Command window opens, showing…
>
> Using NET for debugging
> Opened WinSock 2.0
> Waiting to reconnect…
> Connected to target 192.168.0.100 on port 50000.
>
> At the bottom, it reads “Debuggee not connected”, and it doesn’t allow me
> to enter anything there.
>
> This is the correct IP for the target, but I don’t know how the host found
> that out.
>
> If I put a different port in the Kernel Debug… dialog, I don’t get the
> last “Connected…” line, so I interpret that to mean that some sort of
> handshake was established with the target.
>
> So what’s wrong here??? Some sort of version mismatch between target and
> host?
>
> I have a wireless router. The target is ethernet connected to the router,
> and the target is wireless connected to the router. That’s supposed to be
> OK, as I understand it.
> The host and target can both ping themselves and each other by their IP
> addresses.
>
> I enabled the firewall on the target as requested the first time I tried
> Kernel Debug…
>
> I’ve also tried disabling the firewalls on both ends, to no effect.
>
> I’m going to try installing a matching version of Debug Tools on the
> target, and see if that helps. I don’t know if the code that implements
> the target interface is built into Windows 10 or it comes from the Debug
> Tools. It’s worth a try.
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:> showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:></http:>

Get a newer windbg.

Re Dzmitry: The windbg I installed for Win7 looks like it supports NET, because there is a Net tab, but without any Port entry field. I thought I’d try to reverse the host and target roles to see if I could make a connection that way. When I did the bcdedit thing on the Win7 machine, it did not accept the “net” parameter. So I think you are just saying that for Win7 to be the target, it cannot use ethernet.

Re Matt: I moved the windbg over from my Windows 10 target to the host and ran it. I now have the port number and key fields. I entered the key generated by the host (as quoted in the original post above) into the key field, and I got a complaint that the key was invalid. I surmise that this is a result of running a Win10 windbg on Win7, but maybe there’s something else wrong with the key (??).
I also tried Kernel Debug… with the key left blank, and I got no complaint about invalid key. However, I got the same behavior as I did with the original windbg: Debuggee not connected.


I’m going to at least see if I can make a connection between my target computer and itself using its own IP address. If I can do that much, then I guess I’ll see if I can upgrade my host to Win10, or see if I can use either RS232 or IEEE 1394. I don’t know anything about FireWire, but I’ll find out.

Another possibility is that there’s a networking issue. On the target, the Allow Apps through Firewall dialog doesn’t have entries for either Windows Kernel Debugger or Windows GUI Symbolic Debugger. I added my local windbg.exe to the list, and it showed up as Windows GUI Symbolic Debugger. But I don’t know how to add Windows Kernel Debugger. Maybe this is the problem.

xxxxx@gmail.com wrote:

If I’m not mistaken, the Win7 doesn’t support the debugging over Ethernet.
For Win7 available 1394, RS232 or pipe.

Win 7 cannot be the debug TARGET, but it can certainly be the debug HOST
over Ethernet, as long as windbg is new enough.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Your windbg is too old. The version should be 10.0.*. Also do yourself a
favor and use a key like 1.2.3.4. This is you doing debugging on your two
systems, there really isn’t a lab security issue.

Mark Roddy

On Tue, Mar 6, 2018 at 2:27 PM, xxxxx@probo.com wrote:

> xxxxx@gmail.com wrote:
> >
> > If I’m not mistaken, the Win7 doesn’t support the debugging over
> Ethernet.
> > For Win7 available 1394, RS232 or pipe.
>
> Win 7 cannot be the debug TARGET, but it can certainly be the debug HOST
> over Ethernet, as long as windbg is new enough.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:> showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:></http:>

I’ve tried running windbg 10.0 on my host, but I get the error message about the key being invalid. It says “kernel debugger failed initialization. Win32 error 0n87. The parameter is incorrect.”

Does this mean that some connection attempt got through to the target and was rejected, or what?

Any tips about the target setup, like firewall settings?

The MSDN documentation is really pretty clear. Just follow it step by step:

https:

The thing that makes MOST people nuts is the fact that the “KEY” is parsed like an IP address. My KEY parameter is always 1.1.1.1 – stupid format.

Peter
OSR
@OSRDrivers</https:>

Peter, thanks, but I started off by following that MSDN document step by step.

I read about multiple network adapters. DeviceManager shows one Realtek PCIe adapter, plus several items called “WAN miniport …”. The PCIe adapter shows status of “This device has been reserved for use by the Windows kernel debugger for the duration of this boot session. (Code 53)”. I didn’t think I needed to specify the busparams, since the debugger knew which device to use. Anyway, I originally specified the busparams, see original post above, and that wasn’t sufficient to allow a connection.

To all of you, tell me if it’s the host is supposed to connect to the target after it has booted up, or do I need to boot the target while the host is waiting for a connection. I’ll try this myself later, after my host finishes (slowly) upgrading to Windows 10. Right now it’s applying updates and at the rate it’s progressing, it could be hours longer (sigh!).

Well, seems that nobody told me to restart my target computer while the
host debug session is running.  I did that, and now I’ve got lots of
output in the windbg command window.  So now I’ll start playing with it.

I was about to complain to you all that I couldn’t type into the command
window, but then I realized that it works just like user mode debugging
with VS, in that I have to stop the debuggee in order to interact with it.

Pray tell, why didn’t someone tell me what “waiting to reconnect” meant?


Michael Rolle
xxxxx@rolle.name
408-313-8149

First, let me note that it is hard to be sympathetic with somebody who *complains* about the free help they?re being given by industry experts. I mean… seriously?

Second, let me note that nobody explicitly told you what this means because it?s meaning is self-evident. If you think ?waiting to reconnect? means ?you must reboot now? you are mistaken. There are several ways to cause a debugger to connect to a target. One of them is to reboot the target. Another is to send several ?break? commands from the debugger to the target. There are others as well.

So… yeah: ?Waiting to reconnect? means, ah, ?the debugger is waiting to connect or reconnect to the target.? Sorry we didn?t tell you that.

Peter
OSR
@OSRDrivers

There are practically speaking an infinite number of other things we
haven’t disclosed. We are just plain mean.

Mark Roddy

On Wed, Mar 7, 2018 at 7:30 AM, xxxxx@osr.com wrote:

>


>
> First, let me note that it is hard to be sympathetic with somebody who
> complains about the free help they?re being given by industry experts. I
> mean… seriously?
>
> Second, let me note that nobody explicitly told you what this means
> because it?s meaning is self-evident. If you think ?waiting to reconnect?
> means ?you must reboot now? you are mistaken. There are several ways to
> cause a debugger to connect to a target. One of them is to reboot the
> target. Another is to send several ?break? commands from the debugger to
> the target. There are others as well.
>
> So… yeah: ?Waiting to reconnect? means, ah, ?the debugger is waiting to
> connect or reconnect to the target.? Sorry we didn?t tell you that.
>
> Peter
> OSR
> @OSRDrivers
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:> showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:></http:>