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.
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?
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…
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.
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?
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.
Tim, the test machine is on 192.168.203.10, the same subnet as the host.
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.
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.
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.
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.
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.
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.
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, timr@probo.com
Providenza & Boekelheide, Inc.
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.
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?
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
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.
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