Ställa in KDNET USB-felsökning i kernelläge (KDNET-USB)

Felsökningsverktyg för Windows stöder felsökning i kernelläge via en USB 3.0-kabel med KDNET via USB. Den här artikeln beskriver hur du konfigurerar det här transportalternativet.

Den dator som kör felsökningsprogrammet kallas värddatoroch datorn som debuggas kallas måldator.

Felsökning via en USB 3.0-kabel kräver följande maskinvara:

På värddatorn, en xHCI USB 3.0+ värdstyrenhet och USB3-port.
På måldatorn, en xHCI USB 3.0+ värdstyrenhet och en USB3-port som stöder felsökning (DBC)
Måldatorns USB-värdstyrenhet måste ha stöd för DBC (Intel xHCI Debug Capability Interface). Mer information finns i xHCI-specifikationen på Intels webbplats.

Binära transportfiler

Drivrutinen kdstub.dll och kdnic.sys används för att stödja KDNET-USB felsökningstransport.

Kabelkrav

En orange Microsoft USB-felsökningskabel, som är en A-A-crossover-kabel som har två manliga typ-A-pluggar och ingen Vbus-anslutning. Den här kabeln är tillgänglig från leverantörer som DataPro – USB 3.0 Super-Speed A/A-felsökningskabel.
En usb 3.0-standardtyp C till typ A-adapter krävs för att ansluta värdtypen A-porten till måltypen C-porten.

För att förenkla felsökningen ansluter du kabeln direkt mellan målet och värddatorn och undviker alla hubbar eller dockningsstationer.

Konfigurera måldatorn

Leta upp och starta UsbView-verktyget på måldatorn. UsbView-verktyget ingår i Felsökningsverktyg för Windows. För ett x64-system finns UsbView i C:\Program Files (x86)\Windows Kits\10\Tools\KitVersion\x64\usbview.exe.
Leta upp alla xHCI-värdstyrenheter i UsbView.

I UsbView expanderar du noderna för xHCI-värdstyrenheterna. Leta efter en indikation på att en port på värdstyrenheten stöder felsökning.

[Port1]

Is Port User Connectable:         yes
Is Port Debug Capable:            yes
Companion Port Number:            3
Companion Hub Symbolic Link Name: USB#ROOT_HUB30#5&32bab638&0&0#{...}
Protocols Supported:
 USB 1.1:                         no
 USB 2.0:                         no
 USB 3.0:                         yes

Anteckna buss-, enhets- och funktionsnumren för den xHCI-styrenhet som du tänker använda för felsökning. UsbView visar dessa siffror. I följande exempel är bussnumret 48, enhetsnumret är 0 och funktionsnumret är 0.
```
USB xHCI Compliant Host Controller
...
DriverKey: {36fc9e60-c465-11cf-8056-444553540000}\0020
...
Bus.Device.Function (in decimal): 48.0.0
```
Om du behöver bekräfta bussparametrarna använder du Enhetshanteraren. Leta upp den USB-styrenhet som du tänker använda för felsökning i Enhetshanteraren. Under Plats på fliken Allmänt visas buss-, enhets- och funktionsnummer. b, d och f är buss-, enhets- och funktionsnummer för USB3-värdstyrenheten. Buss-, enhets- och funktionsnumren måste vara i decimalformat.

Du kan också använda kdnet.exe för att samla in information om USB-styrenheten.

C:\Program Files (x86)\Windows Kits\10\Debuggers\x64>kdnet

Network debugging is supported on the following USB controllers:
busparams=0.20.0, Intel(R) USB 3.0 eXtensible Host Controller - 1.0 (Microsoft)

This Microsoft hypervisor supports using KDNET in guest VMs.

När du har identifierat en xHCI-styrenhet som stöder felsökning är nästa steg att hitta den fysiska USB-anslutningsappen som är associerad med en port på xHCI-styrenheten. Om du vill hitta den fysiska anslutningsappen ansluter du alla USB 3.0-enheter till valfri USB-anslutning på måldatorn. Uppdatera UsbView för att se var enheten finns. Om UsbView visar enheten ansluten till den valda xHCI-värdstyrenheten har du hittat en fysisk USB-anslutning som du kan använda för USB 3.0-felsökning.

Viktigt!

Innan du använder bcdedit eller kdnet.exe för att ändra startinformationen kan du tillfälligt behöva inaktivera Windows-säkerhetsfunktioner som BitLocker och Säker start på testdatorn. Återaktivera dessa säkerhetsfunktioner när testningen är klar och hantera testdatorn på rätt sätt när säkerhetsfunktionerna är inaktiverade.

Välj ett unikt <port address> för varje mål-/värdpar som du arbetar med inom det rekommenderade intervallet 50000-50039. 50005 visas i exemplen nedan.
Leta upp verktyget KDNet.exe i WDK-felsökningskatalogen som matchar din CPU-typ, till exempel x64.
På måldatorn öppnar du kommandotolken som administratör och anger det här kommandot för att aktivera kernelfelsökning med -k alternativet . -w, -b och -h aktiverar kernelfelsökning för winload-, bootmgr- och hypervisor-systemprogram. Mer information om WinDbg-alternativen finns i Startalternativ för WinDbg – Kommandorad.
```
kdnet.exe 169.254.255.255 50005 -k
```
- 169.254.255.255 den icke-dirigerbara länklokala statiska IP-adressen måste användas för KDNET via USB3.
- kdnet.exe returnerar en nyckel w.x.y.z som ska användas av WinDbg för att ansluta till målenheten.
Om du vill använda en specifik USB-port använder du parametern -busparams .
```
kdnet.exe -busparams 0.13.0 169.254.255.255 50005 -k
```
Användning av KDNET-verktyget rekommenderas. Det här verktyget anger alternativ som är mer komplicerade att ange med bcdedit, samt kontroll och inställning av stöd för registervärden för PCI och energisparfunktioner.
```
bcdedit /dbgsettings NET hostip:169.254.255.255 port:50001 key:1.2.3.4 busparams:0.20.0 noDhcp
```

Inaktivera strömhantering

I vissa fall kan strömövergångar störa felsökning via USB 3.0. För att undvika dessa problem inaktiverar du selektivt uppehåll för xHCI-värdstyrenheten och dess rothubb som du använder för felsökning.

I Enhetshanteraren navigerar du till noden för xHCI-värdstyrenheten. Högerklicka på noden och välj Egenskaper. Om det finns en power management-flik öppnar du fliken och avmarkerar kryssrutan Tillåt att datorn inaktiverar den här enheten för att spara ström .
I Enhetshanteraren navigerar du till noden för roothubben för xHCI-värdstyrenheten. Högerklicka på noden och välj Egenskaper. Om det finns en power management-flik öppnar du fliken och avmarkerar kryssrutan Tillåt att datorn inaktiverar enheten för att spara ström .

När du är klar med att använda xHCI-värdstyrenheten för att debugga, aktiverar du selektiv avstängning för xHCI-värdstyrenheten igen.

Starta en felsökningssession med WinDbg

Anslut en USB 3.0-felsökningskabel till de identifierade USB 3.0-portarna som du har valt för felsökning på värd- och måldatorerna.
På värddatorn öppnar du en version av WinDbg med administratörsrättigheter som matchar bitantalet av Windows som körs på värddatorn. Om värddatorn till exempel kör en 64-bitarsversion av Windows öppnar du 64-bitarsversionen av WinDbg som administratör.
På menyn Arkiv väljer du Anslut till kernel. Öppna fliken Net i dialogrutan Kernel-felsökning. Ange följande information och klicka på OK.
- Det <port address> som är unikt för varje mål-/värdpar och ligger inom det rekommenderade intervallet 50000-50039 angavs som indata när kdnet.exe kördes.
- Den <session key> w.x.y.z som genererades när kdnet.exe kördes och dess värde visades i kommandoutdata.

Kommandoradssession med WinDbg

Du kan också starta en session med WinDbg genom att ange det här kommandot i kommandotolkens fönster.

Windbg /k NET:port=<port address>,key=<session key>

Starta om måldatorn

När felsökningsprogrammet har lästs in och är redo att köras startar du om måldatorn. Ett sätt att starta om datorn, är att använda kommandot shutdown -r -t 0 från en administratörs kommandoprompt.

När måldatorn har startats om bör felsökningsprogrammet ansluta automatiskt.

Felsökning

USB-enheten känns inte igen

Om ett Windows-meddelande visas på värddatorn med texten USB-enhet som inte känns igen när du kopplar in felsökningskabeln, är det möjligt att ett känt kompatibilitetsproblem mellan USB 3.1 och 3.1 uppstår. Det här problemet påverkar felsökningskonfigurationer när felsökningskabeln är ansluten till en USB 3.1-kontrollenhet i värddiatorn och en Intelkontrollenhet (Ice Lake eller Tiger Lake) 3.1 USB-kontrollenhet i måldatorn.

Mer information och listor över processormodeller finns i Ice Lake (mikroprocessor) och Tiger Lake (mikroprocessor). Om du vill hitta processormodellen för måldatorn öppnar du appen Inställningar och går till System och sedan Om. Processorn finns under Enhetsspecifikationer.

Du kan kontrollera det här problemet genom att öppna Enhetshanteraren och leta efter USB-felsökningsanslutningsenheten under Universal Serial Bus-styrenheter. Om den här enheten inte kan hittas söker du efter en okänd enhet under Andra enheter. Högerklicka på enheten för att öppna dess egenskapssida. Textrutan enhetsstatus har texten Windows har stoppat den här enheten eftersom den har rapporterat problem (kod 43) och USB-enheten returnerade en ogiltig USB BOS-beskrivning.

Du kan undvika det här problemet genom att köra dessa kommandon från en kommandotolk för administratör för att göra ändringar i registret:

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\usbflags\349500E00000 /v SkipBOSDescriptorQuery /t REG_DWORD /d 1 /f
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\usbflags\045E06560000 /v SkipBOSDescriptorQuery /t REG_DWORD /d 1 /f

Var försiktig när du redigerar registret direkt, eftersom felaktiga ändringar kan leda till systeminstabilitet.

Anslutningen gör återförsök och visar meddelanden i felsökningskonsolens fönster men kan inte få åtkomst till målet – SkipPciProbeDebugDevice

Om du stöter på följande meddelande i KDNET-felsökningskonsolen, inte kan initiera ett inbrott i målet eller uppleva problem med vissa kommandon (t.ex. kdfiles), kan det bero på att KDNET tar emot ett pingpaket utan sekvens.

... Retry sending the same data packet for 128 times.

The transport connection between host kernel debugger and target Windows seems lost.
please try resync with target, recycle the host debugger, or reboot the target Windows.

Det här problemet kan inträffa eftersom pci.sys drivrutinen avsöker felsökningsenheten. Om du vill eliminera dessa felmeddelanden skapar du följande registerpost på TARGET-enheten i en kommandotolk för administratör.

Den här inställningen kan också tillåta felsökningsprogrammet att ansluta om den första KD-transporten inte kunde ansluta vid start, av någon annan anledning, till exempel om felsökningsenheten inte kunde konfigureras vid start.

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\SERVICES\kdnet /v SkipPciProbeDebugDevice /t REG_DWORD /d 1 /f

Starta sedan om måldatorn.

shutdown /r /t 0

När enheten startas om bör felen försvinna och kommandona bör fungera som förväntat.

NO_KDNIC inställning för bättre prestanda och pålitlighet

Om ett Ethernet-nätverkskort är installerat på måldatorn kan ytterligare tillförlitlighet och prestandaförbättringar uppnås genom att ange alternativet NO_KDNIC .

bcdedit /set {current} loadoptions NO_KDNIC

Det är valfritt att lägga till NO_KDNIC och kan endast användas om målet har en extra NIC-, Wi-Fi- eller USB-port för att ansluta ett USB-Ethernet-kort för att ge nätverksåtkomst till Windows.

Om du lägger till NO_KDNIC kommer det att förhindra att kdnic.sys-drivrutinen (en miniporttimerbaserad drivrutin) körs ovanpå KDNET, vilket innebär att Windows TCP/IP-trafik inte dirigeras via KDNET-transport. Sedan kan KDNET-transporten endast användas för att dirigera felsökningsrelaterade paket mellan mål-KDNET och värdfelsökaren.

Detta kan hjälpa med nätverksprestanda som kan påverkas när kdnic.sys-drivrutinen körs ovanpå kdnet. I den här situationen kommer målet aldrig att gå i viloläge, vilket förhindrar strömtestning och orsakar fördröjningar vid åtkomst till målet via RDP. Det beror på att KDNET-gränssnittet måste dirigera både felsökningspaket och Windows TCP/IP-nätverkspaket när kdnic.sys körs.

Automatisk återställning av värd-USB-styrenhet

Ibland kan felsökaren stöta på ett bankat USB-stacktillstånd som kan orsakas av en tidigare misslyckad USB-uppräkning. Detta leder till att felsökaren inte kan ansluta till måldatorn även när alla inställningar är korrekt konfigurerade.

I IC-scenarier kan du lösa det här problemet genom att inaktivera\re-aktivera den överordnade USB-styrenheten manuellt. För andra scenarier, till exempel automatiserade testlabb, är manuella steg som dessa inte möjliga. Genom att aktivera RestartKdNetUsbDebugDevice inställningen övervakar felsökningsklienten automatiskt för misslyckad USB-uppräkning och återställer USB-stacken när en bankad enhet identifieras. Detta gör att felsökaren kan ansluta utan någon användarintervention. Den här funktionen är inbyggd i felsökningsprogrammets klientprogram och är därför endast aktiv när felsökningsklienten körs och inställningen är aktiverad.

Så här aktiverar du:

Alternativ 1: Kör följande kommando från felsökningsprompten.

kd> dx Debugger.Settings.Debug.Advanced.RestartKdNetUsbDebugDevice=true

Varning

Du kanske inte kan använda strategin för att ange alternativet om USB-felsökningsenheten redan misslyckas med att räkna upp eftersom detta hindrar sessionen från att ansluta till och bryta sig in i målet så att du aldrig kommer till en funktionell felsökningsprompt.

Alternativ 2: Från det (nya) Windbg-programmet går du till "Arkiv" –> "Inställningar" –> "Inställningar för kernelfelsökning" och klickar på kryssrutan "Aktivera automatisk återställning av värd-USB-styrenheten när det behövs" och startar sedan som vanligt från dialogrutan "anslut till kernel".

Alternativ 3: Skapa (eller ändra befintlig) config.xml fil för att inkludera inställningen RestartKdNetUsbDebugDevice . Den config.xml filen läses in från samma katalog som felsökningsklientprogrammet, d.v.s. kd.exe eller (äldre) windbg.exe. Om det inte finns någon som finns skapar du en ny fil med namnet config.xml med följande innehåll:

<?xml version="1.0" encoding="utf-8"?>
<Settings Version="2">
  <Namespace Name="Debug">
    <Namespace Name="Advanced">
      <Setting Name="RestartKdNetUsbDebugDevice" Type="VT_BOOL" Value="true"></Setting>
    </Namespace>
  </Namespace>
</Settings>

Om det redan finns en config.xml, sammanfogar <Setting Name="RestartKdNetUsbDebugDevice" Type="VT_BOOL" Value="true"></Setting> du xml-elementet till Debug.Advanced noden i det befintliga XML-dokumentet.

Se även

Konfigurera KDNET-nätverkskärnfelsökning automatiskt

Konfigurera KDNET-nätverkskärnfelsökning manuellt

Ställ in kärnlägesfelsökning manuellt

Konfigurera USB 3.0 xHCI-DBC kärnläge felavhjälpning (KDUSB)

Konfigurera USB KDNET EEM-kärnläge-debuggning (KDNET-EEM-USB)

Feedback

Var den här sidan till hjälp?

Last updated on 2025-09-05