none
Kernel Debug Network Adapter not enabled RRS feed

  • Question

  • Hello.

    I am starting a new KMDF device driver and am using Visual Studio 2013 on my Win 7 host machine. My target machine is running Windows 8.1.  The target machine has one built-in network adapter that is listed as compatible for network development and debugging.

    I have been able to configure the computers, update and install the device driver on my target machine successfully. I have not been able to break into the target machine to get control. I have tried with both Visual Studio and WinDbg on my host to get control of the target machine with no success. I used the bcdedit utility to ensure that debug is on and the dbgsettings are set to point to my host machine and all looks good as far as I can tell. The firewall settings for the target machine are all off.

    I did notice in the Network Connections in the Control Panel of the target that the Ethernet adapter is enabled and working. There is another entry for a Microsoft Kernel Debug Network Adapter that is disabled. I have tried to enable this driver and the driver stays greyed out and disabled.

    Are two physical adapters necessary to debug/develop device drivers? My last project had a different target machine with two physical adapters and I had greater luck debugging. Unfortunately that hardware is old and doesn't support PCIe which is the hardware I am developing the driver for. 

    Thoughts?

    Thanks,

    Brian

     

    Wednesday, March 5, 2014 9:19 PM

Answers

  • Ok, that should be fine.  Since you have 2 NICs, you do need to use the busparams keyword to force the debugger to select the right one.  (If the debugger selects the wrong one, then you won't have access to your hardware.)

    Re-reading your description of the symptoms, it does sound like the presence of the add-in card is interfering with the kernel debugger. So it's likely that the kernel debugger is finding the add-in card, and trying to use that.

    I also double-checked the bcdedit syntax -- I was wrong that bcdedit accepts a busparams argument directly on the /dbgsettings command. You do need to set it separately. (VS includes busparams with the other settings, but bcdedit for some reason doesn't.)

    So a typical invocation would be:

    bcdedit /dbgsettings net hostip:x.x.x.x port:x
    bcdedit /set {dbgsettings} busparams x

    It's probably pretty close to what you already had.  The only other thing I can do is suggest that you double-check that the bus/device/function combination is correct.  Use the PowerShell command Get-NetAdapterHardwareInfo to verify that the bus/device/function numbers are correct.  Note that bcdedit parses the busparams string as decimal numbers -- double-check you weren't looking at hex data.

    Also, if you haven't found it already, there's some comprehensive documentation & troubleshooting steps here.

    Monday, March 10, 2014 8:41 PM
  • Eureka!

    I tried your first option and I can now get control of my target machine.

    Thank you very much.

    Brian 

    • Marked as answer by bemoore1234 Wednesday, March 12, 2014 5:32 PM
    Wednesday, March 12, 2014 5:32 PM

All replies

  • Two physical adapters are not necessary to debug and deploy device drivers to a target machine. If your attemps to debug don't work in WinDbg, it is likely an error with your configuration, though I'm not sure exactly what it could be. Did you look at the MSDN documentation about this?

    I'll try to find someone better suited to answer that question. But since this is seems to be purely debugger issue, you might get a faster answer by asking this in the "Windows Desktop Debugging" forum.


    Max -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Monday, March 10, 2014 5:52 PM
  • Max,

    I followed the instructions in the MSDN documentation (at least I think I did.).

    The commands seem quite simple.

    I tried this command to direct the debugger to my built-in ethernet adapter. I don't know if it fouled up my configuration. I don't see a way to clear this entry.

    bcdedit /set "{dbgsettings}" busparams b.d.f

    I have been unable to enable the Microsoft Kernel Debug Network Adapter which appears in the Network Connections. This is what I think is fouled up. It seems like a simple problem. Not sure what to do at this point.

    Brian 

    Monday, March 10, 2014 6:02 PM
  • You've actually set the busparams to "b.d.f" ? Then that part is certainly wrong: if you want to use busparams, you need to use the actual values for those parameters be replacing the placeholders that are "b.d.f". You can remove the entry by using the following command.

    "bcdedit /deletevalue "{dbgsettings}" busparams"


    Max -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Monday, March 10, 2014 6:13 PM
  • Max,

    I used the actual PCI bus values, not b,d,f.  

    Brian

    Monday, March 10, 2014 6:43 PM
  • I have been unable to enable the Microsoft Kernel Debug Network Adapter which appears in the Network Connections.

    The kernel debug adapter enables itself when it detects that kernel debugging is running over the network transport.  It refuses to start if kernel debugging is not running over the network transport.  That it's still disabled is a symptom, not the problem.

    You shouldn't have to manually set individual values in the {dbgsettings} store, as "bcdedit /dbgsettings" does it all for you in a single command.  Can you post the output of "bcdedit /dbgsettings"?

    Monday, March 10, 2014 7:10 PM
  • I am writing a device driver to capture raw data from a high performance PCIe LAN adapter. This particular adapter is supported by Windows so I am working to override the built-in setup/device driver execution information. I can load my driver and run the traceview utility to see that I am going through initialization of my driver for this hardware. I am unable to get control of the target machine with Cntl-Alt-Break from Visual Studio. When I look at Network adapters from the Control Panel, the built-in adapter is enabled and the Microsoft Kernel Debug Adapter is disabled.

    When the target adapter is removed from the chassis, the Microsoft Kernel debug adapter is enabled and uses the hardware for the built-in adapter. There is only one entry for the Lan adapter in the Network Connections dialog and it is the Microsoft kernel debug adapter. The device manager shows the built-in LAN adapter with a yellow exclamation point icon on it and the Microsoft kernel debug network adapter with no issues indicated. I just tried to get control from Visual Studio from the host machine and I was able to get control of the system (Cntl-Alt-Break). Naturally I don't get into the device driver since the hardware is removed but I do at least get control of the target machine.

    I suspect the way I have overridden an existing configuration/setup has introduced a problem that is affecting the debug capability.

    Is there an "accepted" way/procedure to take control from an existing piece of OEM hardware?

    Thanks for the input.

    Brian  


    Monday, March 10, 2014 7:50 PM
  • Let me check if I understand correctly. 

    • You've written a custom driver to replace the normal NIC driver.
    • There is only 1 physical NIC in this system, and it is the NIC that you're targeting.  It's also the NIC that the kernel debugger is targeting.

    Is your driver an NDIS driver, or something else?

    When the kernel debugger enables network debugging, the kernel debugger takes exclusive ownership of the NIC hardware.  NDIS (by design) will decline to load the usual NIC driver on that hardware (which is why you see the yellow exclamation mark in device manager).  The NIC hardware is inaccessible to the OS, as it's being used exclusively by the kernel debugger transport.

    If I understand your situation correctly, you need access to the NIC hardware for your project.  If that's the case, your project is incompatible with kernel debugging, and cannot share the same NIC hardware.  You can still enable kernel debugging -- use two separate NICs (one for you, one for the debugger), or use a different debug transport, like 1394.  (Personally I prefer 1394 anyway, as it's actually higher-bandwidth and lower-latency than network debugging.)

    Monday, March 10, 2014 8:17 PM
  • I am writing a custom driver to replace the driver for an added PCIe Ethernet card, not the built-in Ethernet adapter. I want to use the built-in ethernet adapter for my debug connection.

    My driver is not NDIS. It has a custom interface.

    Does that make it necessary to obtain another LAN adapter to use as the debug port?

    Thanks,

    Brian

    Monday, March 10, 2014 8:24 PM
  • Ok, that should be fine.  Since you have 2 NICs, you do need to use the busparams keyword to force the debugger to select the right one.  (If the debugger selects the wrong one, then you won't have access to your hardware.)

    Re-reading your description of the symptoms, it does sound like the presence of the add-in card is interfering with the kernel debugger. So it's likely that the kernel debugger is finding the add-in card, and trying to use that.

    I also double-checked the bcdedit syntax -- I was wrong that bcdedit accepts a busparams argument directly on the /dbgsettings command. You do need to set it separately. (VS includes busparams with the other settings, but bcdedit for some reason doesn't.)

    So a typical invocation would be:

    bcdedit /dbgsettings net hostip:x.x.x.x port:x
    bcdedit /set {dbgsettings} busparams x

    It's probably pretty close to what you already had.  The only other thing I can do is suggest that you double-check that the bus/device/function combination is correct.  Use the PowerShell command Get-NetAdapterHardwareInfo to verify that the bus/device/function numbers are correct.  Note that bcdedit parses the busparams string as decimal numbers -- double-check you weren't looking at hex data.

    Also, if you haven't found it already, there's some comprehensive documentation & troubleshooting steps here.

    Monday, March 10, 2014 8:41 PM
  • Jeffrey,

    It does look like the card that I am writing the driver for is somehow interfering with the debug capability. I have ordered another LAN card to use as a debug port.  

    Thanks for your inquiry.

    Brian 

    Monday, March 10, 2014 8:49 PM
  • I received an additional LAN card and have installed it so I have two NICs connected to my development LAN. Here is what I am seeing:

    1) I have used the bcdedit /set "{dbgsettings}" busparams 3.0.0 command to assign the new adapter to the Microsoft Kernel Debug Adapter. Device manager shows the adapter is on PCI bus 3, device 0, function 0.

    2) Re-booted the machine and the Microsoft Kernel Debug Adapter is assigned to the new LAN adapter. All looks good.

    3) With Visual Studio 2013 on my host, I attempted to deploy the driver to the target machine. Deployment goes ok.

    4) I pass all of the tests. When the deployment is finished, I am unable to interrupt the target with CNTL-ALT-Break.

    5) I check the device manager and the adapter settings and the Microsoft Kernel Debug Adapter is disabled and I am unable to enable it. 

    The card I am writing an alternate driver for is a LAN adapter. I suspect that during the deployment process, my driver is uninstalled and the original driver for the LAN adapter is re-installed, then uninstalled by the system. This process mucks up the settings for the debugger on the target. 

    Does that sound plausible? 

    Brian

      
    Wednesday, March 12, 2014 4:44 PM
  • The WDK Visual Studio integration stores the debugger settings that you initial set when provisioning your target machine. When deploying a driver, if the debugger settings on the target machine don't match what is stored on the host (Visual Studio machine), then the settings from the host are set on the target. In your case, I would assume this overwrites the bus parameters that you had set manually on the target.

    Workaround for this is to reprovision your target machine with the right debugger settings (no need to unprovision first, so this should be pretty quick)


    Max -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Wednesday, March 12, 2014 5:06 PM
  • Max,

    So I should set up the target machine so it has the Microsoft kernel debug adapter configured correctly and then on the host, Use the Driver->test->configure Computers setting to re-configure?

    Brian

    Wednesday, March 12, 2014 5:12 PM
  • There's two options available to you.

    If you already have the right debugger settings on the target, easiest one is to go to that "Configure Computers Settings" menu, select your target, click next and select the last option ("Manually configure debuggers and do not provision"). Then, just enter the kernel debugger settings that you've set on the target machine.

    If you have not set the right settings on the target, then you can also reconfigure. To do that, select the option to "Provision computer and choose debugger settings", and then just enter the kernel debug settings that you want to use. In theory, you should only have to change the bus parameters in there. Then, during the actual provisioning, whatever debugger settings you entered will be set on the target.


    Max -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Wednesday, March 12, 2014 5:17 PM
  • Eureka!

    I tried your first option and I can now get control of my target machine.

    Thank you very much.

    Brian 

    • Marked as answer by bemoore1234 Wednesday, March 12, 2014 5:32 PM
    Wednesday, March 12, 2014 5:32 PM