Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

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

matt_sykesmatt_sykes Member - All Emails Posts: 270

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.

Comments

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,035
    via Email
    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?

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • matt_sykesmatt_sykes Member - All Emails Posts: 270

    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_sykesmatt_sykes Member - All Emails Posts: 270

    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_sykesmatt_sykes Member - All Emails Posts: 270

    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_RobertsTim_Roberts Member - All Emails Posts: 13,035
    via Email
    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 Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • matt_sykesmatt_sykes Member - All Emails Posts: 270

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

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,035
    via Email
    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 Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • matt_sykesmatt_sykes Member - All Emails Posts: 270

    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_RobertsTim_Roberts Member - All Emails Posts: 13,035
    edited January 21 via Email
    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 Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • matt_sykesmatt_sykes Member - All Emails Posts: 270

    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_RobertsTim_Roberts Member - All Emails Posts: 13,035
    via Email
    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 Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • matt_sykesmatt_sykes Member - All Emails Posts: 270

    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_RobertsTim_Roberts Member - All Emails Posts: 13,035
    via Email
    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.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • matt_sykesmatt_sykes Member - All Emails Posts: 270

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

    Statically Tim

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,035

    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 Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • matt_sykesmatt_sykes Member - All Emails Posts: 270
    edited January 30

    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)Peter_Viscarola_(OSR) Administrator Posts: 7,378

    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

    Peter Viscarola
    OSR
    @OSRDrivers

  • matt_sykesmatt_sykes Member - All Emails Posts: 270

    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)Peter_Viscarola_(OSR) Administrator Posts: 7,378

    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

    Peter Viscarola
    OSR
    @OSRDrivers

  • matt_sykesmatt_sykes Member - All Emails Posts: 270

    It wasnt me who called someone dense Peter.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,378

    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

    Peter Viscarola
    OSR
    @OSRDrivers

  • kevinfkevinf Member Posts: 1
    edited February 13

    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)Peter_Viscarola_(OSR) Administrator Posts: 7,378

    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

    Peter Viscarola
    OSR
    @OSRDrivers

  • matt_sykesmatt_sykes Member - All Emails Posts: 270

    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)Peter_Viscarola_(OSR) Administrator Posts: 7,378

    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)

    Peter Viscarola
    OSR
    @OSRDrivers

This discussion has been closed.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
Developing Minifilters 29 July 2019 OSR Seminar Space
Writing WDF Drivers 23 Sept 2019 OSR Seminar Space
Kernel Debugging 21 Oct 2019 OSR Seminar Space
Internals & Software Drivers 18 Nov 2019 Dulles, VA