Network debugging, took PCs off the DHCP network, WinDbg can no longer connect

matt_sykes

I have successfully run WinDbg over a network with static addresses before, but just installed the new WDK (17763) and VS, and although it could debug when the PCs were on a DHCP network, now they are set up statically, WinDbg cant connect. Firewalls are off on both machines, ping works OK.

Does anyone know of a change in WinDbg 17763 that causes problems on non DHCP networks?

If I try to set the dhcp option to off in bcdedit /dbgsettings I get an error. It seems as if it is a parameter that cant be set.

Or is it some windows setting (the network went to public and I cant seem to be able to change it to private.

Tim_Roberts

matt_sykes wrote:
> I have successfully run WinDbg over a network with static addresses before, but just installed the new WDK (17763) and VS, and although it could debug when the PCs were on a DHCP network, now they are set up statically, WinDbg cant connect. Firewalls are off on both machines, ping works OK.
>
> Does anyone know of a change in WinDbg 17763 that causes problems on non DHCP networks?

The kernel debugger (meaning the part embedded in the target computer's
kernel) is able to connect a windbg on a machine with a static IP, but
it has never supported assigning a static IP to itself.  You either use
DHCP, or you get a fallback address in the 169.254.x.x range.  That
range is not routable, so the two computers have to be directly connected.

Note that the IP address assigned to the network adapter by the
operating system is irrelevant.  The kernel debugger has its own
independent driver stack.


> If I try to set the dhcp option to off in bcdedit /dbgsettings I get an error. It seems as if it is a parameter that cant be set.

What error do you get?

matt_sykes

Like I said I have successfully run windbg over a static network before (as in statically assigned IP addresses, specified manually), this time it is being a pain. The error was something like 'invalid paramater' by the way.

I am getting all kinds of weird shit going on actually. Just after I posted this, it did manage to connect, and was working OK all day. Today, I fire it up, windbg connects, and then after a minute the network icon on the target goes red, thinks no network cable is inserted, and the windbg connection is lost.

So I tried to disable the network adapter, the target hung.

Windows defender messing around? DHCP service? I'll start turning stuff off, lets see how it goes...

matt_sykes

Rebooted, failed to connect
Rebooted, and got this:
Waiting to reconnect...
Connected to target 169.254.181.179 on port 50000 on local IP 192.168.203.1.
You can get the target MAC address by running .kdtargetmac command.

and at the bottom, debugee not connected, target machine shows a red X on the network icon, ie no cable

Something is screwing with the network card after a debug session initiates and causing the cable to go to a removed state.

matt_sykes

Right, so you dont specify dhcp:off, no, that would be too easy wouldnt it. Too much like the other commands. Instead you have to specify 'nodhcp'.

That in itself wouldnt be so bad if Microsoft bothered documenting it, which they dont, here: https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/setting-up-a-network-debugging-connection-automatically

here: https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/setting-up-a-network-debugging-connection

or here: https://msdn.microsoft.com/en-us/data/hh439346(v=vs.71)

Great job Microsoft!

Oh, and VS2017, WDK, and Windows, all installed to the D drive, fails to build a driver, even a stock one straight off the template. On a C drive it is OK. Had the same issue with the WHQL and SQL server last time I tried to run them. Looks like someone put a hard coded path in there somewhere! Another great job eh?

Tim_Roberts

matt_sykes wrote:
> Rebooted, failed to connect
>
> Rebooted, and got this:
>
> Waiting to reconnect...
> Connected to target 169.254.181.179 on port 50000 on local IP 192.168.203.1.
> You can get the target MAC address by running .kdtargetmac command.
>
> and at the bottom, debugee not connected, target machine shows a red X on the network icon, ie no cable

Right.  Those addresses are on different subnets.  To make this work,
your host needs to be 169.254.xxx.xxx with a mask of 169.254.255.255.

matt_sykes

Tim, the test machine is on 192.168.203.10, the same subnet as the host.

Tim_Roberts

matt_sykes wrote:
> Tim, the test machine is on 192.168.203.10, the same subnet as the host.

Um, no, it's not.  The test machine is 169.254.181.179, which is on a
different subnet.  Your message said so.

You're not grasping what I've been trying to say here.  It doesn't
matter one teensy little bit what IP address you assign to the target
interface after the OS has booted.  It's totally irrelevant to the
kernel debugger connection.  The kernel debugger runs a completely
separate network stack.  It will assign its own IP address to that
interface, and it can do so in one of two ways: it can pull from DHCP,
or it can pick a random address from the APIPA range, which is
169.254.xxx.xxx.  That's the extent of your choices.  You cannot force a
static IP of your own choosing.  It's impossible.

Remember, at the time the kernel debugger starts, the kernel doesn't
even KNOW what IP address was assigned.  That all comes later.

matt_sykes

Tim, you can specify a static IP address, you use 'nodhcp' in /dbgsettings. The problem is, as I stated above, that this is NOT documented by Microsoft in either of the links I got fro a google search on setting this up.

Tim_Roberts

matt_sykes wrote:
> Tim, you can specify a static IP address, you use 'nodhcp' in /dbgsettings. The problem is, as I stated above, that this is NOT documented by Microsoft in either of the links I got fro a google search on setting this up.

Yes, you can specify "nodhcp", and that does trigger a static IP
address, but you don't get to specify what IP address to use. The
kernel will choose one at random from the APIPA range, 169.254.xxx.xxx,
which is exactly what showed up in your message. Remember, the HOSTIP
parameter specifies the IP address of the other computer -- the one
running windbg.

matt_sykes

Tim, the relevant take home from this thread is that Windbg in it's latest incarnation has problems connecting to a target on a static network, unless you specify nodhcp, which isnt documented by Microsoft.

Whatever windbg does internally isnt of interest to me. What I am interested in is getting it working so I can get on and do my job, and this is how to get it to work, and if anyone else has this problem, this post just might help them too.

Tim_Roberts

matt_sykes wrote:
> Tim, the relevant take home from this thread is that Windbg in it's latest incarnation has problems connecting to a target on a static network, unless you specify nodhcp, which isnt documented by Microsoft.

I must respectfully disagree.  The "nodhcp" option certainly is documented:

https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/bcdedit--dbgsettings


> Whatever windbg does internally isnt of interest to me. What I am interested in is getting it working so I can get on and do my job, and this is how to get it to work, and if anyone else has this problem, this post just might help them too.

I have told you several times how to get it to work.  Give your debug
host an IP address in the APIPA range.  Then, both machines will be in
the same subnet, and everything will work just fine. For kernel
debugging without DHCP, you are not allowed to choose your own subnet. 
The problem is just that simple.

matt_sykes

Tim, take a look at the three links I gave you earlier, these were the first hits I got off google. It isnt documented there. OK, so yo found one place it is. SO did I (but not on a MSFT site). But this isnt good enough, it should be documented everywhere /dbgsettings net is. Particularly as the latest windbg has problems connecting over a static network.

I have told you several times how to get it to work

And I just told you, I think it is twice now, how to get it to work. Use nodhcp.

Give your debug host an IP address in the APIPA range

So change my entire network because of a bug in the latest windbg?

For kernel debugging without DHCP, you are not allowed to choose your own subnet

Yes you can, just specify nodhcp.

Tim_Roberts

On Jan 23, 2019, at 2:38 AM, matt_sykes wrote:
>
>> Give your debug host an IP address in the APIPA range
>
> So change my entire network because of a bug in the latest windbg?

No. Change the IP address and net mask on your host machine. When you're through debugging, change it back. That's one "netsh" command that you can plop in a batch file.


>> For kernel debugging without DHCP, you are not allowed to choose your own subnet
>
> Yes you can, just specify nodhcp.

And then what? How do you specify the target's IP address?
—
Tim Roberts, [email protected]
Providenza & Boekelheide, Inc.

matt_sykes

And then what? How do you specify the target's IP address?

Statically Tim

Tim_Roberts

Statically Tim

Are you intentionally trying to be dense here? Are you specifically trying to jerk around someone who is actually trying to help you? Look, here are some facts.

• bcdedit has two addressing options: DHCP (by default), or /nodhcp
• If you specify /nodhcp, the test machine's adapter is assigned a static address in the 169.254 subnet
• There is no parameter to bcdedit that lets you specify an IP address for the target
• The kernel debugger doesn't know what IP address might be assigned to the interface after boot has completed

Given those facts, one is led to the inescapable conclusion that there is not now, nor has there ever been, a mechanism to assign a specific static IP address to the kernel debugger's network interface. Therefore, what you are saying is nonsense. If you have a recipe that contradicts this, I'd welcome you to share it, as I have been asking you to do for the last two weeks.

matt_sykes

Tim, it works. Dont you get it? The solution to the problem was nodhcp. It works now. Put the to machines on a static network, set the /dbgsettings up, and reboot. windbg connects. OK? Do you get that?

Peter_Viscarola_(OSR)

Do you get that?

I don't get it Mr. Sykes.

Perhaps you can explain to us the exact steps you've used to assign a static IP address, other than one in the 169.254 subnet, to the test machine. You've said "statically"... but this doesn't tell us WHERE to set this statically. I know how to set it on the HOST machine... in Network Properties. But on the TEST machine? If we are all being incredibly stupid, feel free to paste a screen shot of where we make this change.

I'm taking on face-value that you have found the heretofore unknown incantation to make this work. I'm hoping you will take the time to kindly share this incantation with us. Like Mr. Roberts, I'm under the impression that using /nodhcp gets you a target with a static IP in the 169.254 range and would like to know how to change that.

Thanks,

Peter

matt_sykes

Why so patronising Peter? Really

Surely you know how to assign a static network address to a PC (I used 192.168.137 subnet as the host had been set up to do internet sharing) , so do that, then enable debugging on the target, set the host address, port, and specify nodhcp.

Get the key, put that in windbg on the host, and restart the target.

Windbg connects and you can debug.

Peter_Viscarola_(OSR)

Why so patronising Peter? Really

For somebody who of gets a lot of questions answered here, I find your manner surprisingly aggressive.

Please, Mr. Sykes: For the benefit of everyone, dial it down a level. And bear in mind that when posting here you’re a guest in my house. I don’t invite guests home to have my other guests insulted, be insulted myself, or to have my motives impugned.

Peter

matt_sykes

It wasnt me who called someone dense Peter.

Peter_Viscarola_(OSR)

No, Mr Sykes... but Mr, Roberts has answered questions for quite literally hundreds of people here. His uniform willingness to help, coupled with his exceptional patience, are the stuff of legend. This has earned him the undisputed right to receive respect and deference from every member of this community. And this level of respect is due him regardless of whether Mr, Roberts might display a rare level of frustration in one of his numerous replies.

When you speak disrespectfully to Mr. Roberts, regardless of the provocation, it is not acceptable to me. When you couple this with a snarky reply to me... well, that earns you a bit of a rebuke.

I’m not sure why I need to explain this to you Mr. Sykes. You’ve been here for about five years. Surely you know the rules by now.

Regardless, I’ve taken ten minutes from my Saturday morning to explain this to you, as opposed to going with the faster and simpler alternative of putting you on moderation (which takes 3 mouse clicks), which was my first inclination.

Any reply to this post from you, other than perhaps “Thank you Peter, you are both wise and good looking”, would be Ill-advised. If you want to continue the vain attempt to justify your actions, or you wish to try my patience further in any other way, I ask you to please do so with a direct email. My direct email is visible in my profile.

Peter

kevinf

Thank you for the information @Tim_Roberts , I forgot that KDNET maintains its own IP address stack!

@Tim_Roberts said:

The kernel debugger (meaning the part embedded in the target computer's
kernel) is able to connect a windbg on a machine with a static IP, but
it has never supported assigning a static IP to itself.  You either use
DHCP, or you get a fallback address in the 169.254.x.x range.  That
range is not routable, so the two computers have to be directly connected.

Note that the IP address assigned to the network adapter by the
operating system is irrelevant.  The kernel debugger has its own
independent driver stack.

I wrote a SuperUser post based on extreme slowness to boot with static network. KDNET takes ~10minutes to fall back on link-local address when DHCP server is unavailable. I discovered the DHCP:yes flag was set by default, clearing that flag (on RS5 17763.1) allowed network debug to work as intended.

https://superuser.com/questions/1404669/crossover-computer-connection-vs-network-switch-broadcast-packet-differences

Actually makes it easier, because toggling the IP address of the target machine in Windows is sufficient to block internet access (NDA project), without needing a direct network cross-over connection. WinDbg settings can remain on DHCP

I would recommend amending the Network debug articles to include the nodhcp documentation from https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/bcdedit--dbgsettings as that was definitely missed by me as well.

Peter_Viscarola_(OSR)

I would recommend amending the Network debug articles to include the nodhcp

That is an excellent idea.

Are you aware that the docs are on github... and you can do the edits yourself? Seriously. Go to that page, and you'll see an "edit" link at the top. Go for it! The doc folks are very pleasant to deal with and appreciative of contributions.

Peter

matt_sykes

Actually Peter I have been here since the dawn of time, been writing windows drivers since the days of NT4. (remember the old discussion forum we used before you created these ones on osr? WHat was it, google groups or some such, I forget)

But anyway, I see someone else has agreed with me, that nodhcp is not clearly documented, and nice to see you agree Peter. Now perhaps we can put whatever misunderstanding everyone suffered in this thread behind us and move on.

Peter_Viscarola_(OSR)

Actually Peter I have been here since the dawn of time

Then you should really know the rules, Mr. Sykes, know that Mr. Roberts is worthy of your respect, and act likewise.

What was it, google groups or some such, I forget

It was way before there was a Google, Mr. Sykes. Those original forums, back in the 1993 and 1994, were on CompuServe. We've been answering questions about how to write Windows (NT) drivers for a long, long, time here at OSR...

Oh, these were the days...

Peter
(thread closed)