Ich versuche, das Debuggen von WinDbg über das Netzwerk zum Laufen zu bringen, aber es verliert immer die Verbindungen, nachdem ich in den Debugger eingebrochen bin (Debug-> Break) und versuche dann, ihn erneut zu starten (Debug-> Go). Wenn ich jedoch nie in den Debugger einbreche, scheint die Verbindung für einen Zeitraum von "N" stabil zu sein. Ich kann sogar Debug-Druckanweisungen in WinDbg sehen, wenn ich das Zielsystem während dieser Kulanzperiode verwende. Außerdem scheint die Verbindung während der Debug-Pause gut zu sein, da ich Informationen vom Zielsystem sammeln kann. Ich verwende "! Ustr srv! SrvComputerName", um den Namen des Zielcomputers abzurufen, und er gibt den korrekten Namen zurück. Jede Hilfe wäre sehr dankbar.

Einrichtung der Systeme: Ich habe die Anweisungen von @ befolMSDN website, um meine Ziel- und Hostsysteme einzurichten.

Debugging: Im Folgenden sind meine Versuche aufgeführt, dieses Problem zu beheben.

Deaktivieren der Flusskontrolle und Verwenden des Halbduplexmodus auf dem Netzwerkadapter. Ich habe es versucht, nachdem ich diesen Beitrag gelesen habe: WinDbg, Host-Computer verliert das Netzwerk, wenn sich der Testcomputer auf demselben Switch befindetKauf neuer Netzwerkadapter. Gemäßdiese Webseite, mein Netzwerkadapter sollte das Debuggen des Netzwerkkerns unterstützen. Weitere Untersuchungen haben jedoch gezeigt, dass Anbieter die Gewohnheit haben, ihre Geräte-IDs nicht zu aktualisieren. Daher habe ich mich entschlossen, diese Möglichkeit auszuschließen, indem ich neue Adapter von verschiedenen Anbietern kaufte.Netzwerkanschluss ändern. Ich habe eine Hand voll verschiedener Netzwerkports (49152-65535) ausprobiert, nur für den Fall, dass einer von ihnen für einen anderen Zweck verwendet wird.Entfernen Sie das Ethernet-Kabel und schließen Sie es wieder an. Sobald die Verbindung unterbrochen wurde, habe ich versucht, die Verbindung wiederherzustellen.Zielsystem neu starten. Gleicher Grund wie # 4.Changing PCIe ports. Mir gehen die Optionen aus. Hostsystem auf einen anderen Netzwerkswitch verschoben. Keine Änderung

Überwachung

Wireshark zeigt an, dass das Zielsystem ein UPD-Paket an das Hostsystem sendet, sobald das System hochfährt. Das Hostsystem reagiert jedoch erst, wenn WinDbg gestartet wird. Interessanterweise sendet das Zielsystem auch dann noch UPD-Pakete an den Host, wenn das Zielsystem nicht mehr reagiert. Leider verstehe ich die UPD-Paketdaten nicht.WinDbg kann nach einem Neustart die Verbindung zum Zielsystem konsistent wiederherstellen. Das Zielsystem scheint in der Debug-Pause zu stecken.

Systeminformationen Auf dem Host-System wird Windows 8.1 Pro ausgeführt. Auf dem Zielsystem wird eine Windows 8.1 Enterprise-Evaluierungsversion (8 GB RAM) ausgeführt.

WinDbg Ausdruck:

Microsoft (R) Windows Debugger Version 6.3.9600.17237 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.

Using NET for debugging
Opened WinSock 2.0
Waiting to reconnect...
Connected to target **.**.*.*** on port ***** on local IP **.**.*.***
Connected to Windows 8 9600 x64 target at (Fri Mar 27 18:58:06.217 2015 (UTC - 7:00)), ptr64 TRUE
Kernel Debugger connection established.

************* Symbol Path validation summary **************
Response                         Time (ms)     Location
Deferred                                       srv*C:\Symbols*http://msdl.microsoft.com/download/symbols
Symbol search path is: srv*C:\Symbols*http://msdl.microsoft.com/download/symbols
Executable search path is: 
Windows 8 Kernel Version 9600 MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 9600.17031.amd64fre.winblue_gdr.140221-1952
Machine Name:
Kernel base = 0xfffff801`00e70000 PsLoadedModuleList = 0xfffff801`0113a2d0
Debug session time: Fri Mar 27 18:58:06.918 2015 (UTC - 7:00)
System Uptime: 0 days 0:47:15.869
Break instruction exception - code 80000003 (first chance)
*******************************************************************************
*                                                                             *
*   You are seeing this message because you pressed either                    *
*       CTRL+C (if you run console kernel debugger) or,                       *
*       CTRL+BREAK (if you run GUI kernel debugger),                          *
*   on your debugger machine's keyboard.                                      *
*                                                                             *
*                   THIS IS NOT A BUG OR A SYSTEM CRASH                       *
*                                                                             *
* If you did not intend to break into the debugger, press the "g" key, then   *
* press the "Enter" key now.  This message might immediately reappear.  If it *
* does, press "g" and "Enter" again.                                          *
*                                                                             *
*******************************************************************************
nt!DbgBreakPointWithStatus:
fffff801`00fcab90 cc              int     3
0: kd> g
... Retry sending the same data packet for 64 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.
... Retry sending the same data packet for 128 times.
... Retry sending the same data packet for 192 times.

An diesem Punkt reagiert WinDbg nicht mehr und sendet weiterhin Datenpakete. Das Zielsystem reagiert auch nicht.