0
  • Problem:

    • Network configuration results in 10 minute operating system load time.
  • Setup

    • Two Windows 10 systems, latest updates
    • connected directly with ethernet cable (non-crossover)
    • Static IPs on both
    • Windows Kernel Network Debugging is enabled
    • Windows Firewall is disabled on target
    • Host machine has two network interfaces
  • Questions:

    • How does crossover connections affect broadcast packets?
    • Could the network switch store-and-forward table be responsible?
  • Observations:

    • the 10 minute boot time hang is at spinning windows boot splash
    • I assume the KDNET filter is having a hard time...
    • When I connect both PCs to a network switch, problem solved
    • when I disable network debug, problem solved
    • Connected to target 169.254.78.132 on port 50008 on local IP 192.168.128.1 prints in WinDbg on connection, with network switch or crossover cable
    • Connected to target 172.29.2.197 on port 50008 on local IP 172.29.13.140 is when DHCP is enabled on target, connecting through primary network interface.
    • Leaving WinDbg closed (no kernel debug session open), still slow
    • List of IP addresses of target as per netadapter
IP ADDRESSES

unicast            ffffd206bfefb040 - 192.168.128.100
multicast          ffffd206bfef2040 - 224.0.0.1
multicast          ffffd206ccdd1040 - 224.0.0.251
multicast          ffffd206ccddb040 - 224.0.0.252
multicast          ffffd206cd375040 - 239.255.255.250
broadcast          ffffd206bfef8040 - 255.255.255.255
broadcast          ffffd206ccda9040 - 192.168.128.255
  • Are these computers part of a Windows domain? Are there any startup scripts configured? Is there anything listed in the event logs? – Appleoddity Feb 12 at 4:21
  • The host machine is part of a domain. Target is not. No startup script on target. I'll double check event logs of target. – kevinf Feb 12 at 4:27
0

TL;Dr: Use bcdedit /set {dbgsettings} dhcp No or nodhcp flag.

bcdedit /dbgsettings NET HOSTIP:ip PORT:port [KEY:key] [nodhcp] [newkey] [/start startpolicy] [/noumex]

WinDBG using Windows 10 (RS5 / 17763.1) kernel network debugging requires DHCP by default to function optimally.

Recall, that KDNET kernel module operates on a lower level than Windows OS. The "Microsoft Kernel Debug Network Adapter" connection's IP address settings are NOT used, nor the hidden real (Intel/Realtek/Broadcom) adapter, that had its IP address as well.

For example, setting IPV4 address to 192.168.128.1 in Network Connections control panel, the debugger (while connected to switch) reports this:

Connected to target 172.29.1.132 on port 50008 on local IP 172.29.13.140.

this correlates to my previous observation that when crossover cable was used:

Connected to target 169.254.78.132 on port 50008 on local IP 192.168.128.1

So a crossover cable with no DHCP server results in KDNET stalling for 10 minutes on DHCP before finally falling back to link-local address.

Confirmed by https://community.osr.com/discussion/290941/network-debugging-took-pcs-off-the-dhcp-network-windbg-can-no-longer-connect

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.

Also, communication is done via UDP packets, not TCP... so it doesn't need an IP address really. Here is the Wireshark packet capture showing the DHCP requests using crossover cable:

Wireshark Packet Capture

Looking closer at the output of bcdedit and bcdedit /dbgsettings I see windows automatically used the DHCP flag, despite me never adding it. I see they also added a "nodhcp" option, although its hard to find in the documentation

debug                   Yes
----- dbgsettings -----
busparams               3.0.0
key                     1.2.3.4
debugtype               NET
hostip                  192.168.128.1
port                    50008
dhcp                    Yes

Adding DHCP:no to my network debug setup batch script solved the problem!

@echo off

rem get bus device function from Device Manager of network adapter
set bdf=3.0.0

rem port used in WinDbg
set port=50008

rem set your workstation machine to the following IP on a secondary adapter
set ip=192.168.128.1

rem enable network debug using the ip address of the dev system
bcdedit /debug on
bcdedit /create {dbgsettings} > NUL 2>&1
bcdedit /dbgsettings NET HOSTIP:%ip% PORT:%port% KEY:1.2.3.4
bcdedit /set {dbgsettings} busparams %bdf%
bcdedit /set {dbgsettings} dhcp No

rem rebuilt BCDs don't contain these sections / inheritance, and prevents Microsoft Kernel Debug Network Adapter from appearing
bcdedit /set {current} inherit {globalsettings}
bcdedit /create {globalsettings} > NUL 2>&1
bcdedit /set {globalsettings} inherit {dbgsettings}

pause

There is also the Firewall issue caused by static networks with no DNS being marked "public", I have this powershell snippet to fix it, but its required on Startup.... I just disabled the Firewall for this target machine to mitigate the issue instead.

# Name             : Unidentified network
# InterfaceAlias   : nameOfYourNetworkAdapter
# InterfaceIndex   : 6
# NetworkCategory  : Public
# IPv4Connectivity : NoTraffic
# IPv6Connectivity : NoTraffic

# converts the "Public" network to "Private" so file sharing and such works with Windows firewall
# this is good for local connections that do not need gateway / dns

get-netconnectionprofile -InterfaceAlias *
set-netconnectionprofile -InterfaceAlias nameOfYourNetworkAdapter -NetworkCategory Private
get-netconnectionprofile -InterfaceAlias *

# note, I don't believe this persists between reboots... so add to startup menu if needed
# it makes it easier to rename your nework adapter to 'debug' or something without spaces

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.