Paketmitschnitt unter Windows in der Praxis — pktmon, netsh trace und Wireshark wählen

„Die Serverkommunikation der Fachanwendung scheitert ein paar Mal im Monat. Das Anwendungslog sagt nur ‚Timeout‘. Im serverseitigen Log gibt es zu dieser Zeit keinen passenden Fehler. Wir wissen nicht, wie wir es reproduzieren“ — in Beratungen zur Fehleruntersuchung taucht diese Form ständig auf.

Ein Anwendungslog behält nur, was die Anwendung „zu schreiben beschloss“. Sie sehen, dass das Ergebnis ein Timeout war, aber ob die Verbindungsanfrage (SYN) keine Antwort bekam, ob die Verbindung stand und der Server dann schwieg, ob sie mit RST abgerissen wurde oder ob das Paket überhaupt das Ziel erreichte, lebt eine Schicht unter dem Log — in den Paketen, die wirklich über die Leitung gingen. Wenn Process Monitor der Weg ist, Datei- und Registrierungszugriffe eine Schicht tiefer zu sehen, ist Paketmitschnitt der Weg, die Unterhaltung eine Schicht tiefer zu sehen.

flowchart TB
    accTitle: Die Pakete eine Schicht unter dem Anwendungslog
    accDescr: Ein Anwendungslog behält nur, was die Anwendung zu schreiben beschloss; ob SYN keine Antwort bekam, der Peer nach Connect schwieg, ein RST abriss oder das Paket ankam, lebt nur in den Paketen, die wirklich über die Leitung gingen
    log["Anwendungslog"] --> dec["Nur was die App zu schreiben beschloss bleibt"]
    dec --> to["Das Ergebnis ist ein Timeout in einem Wort"]
    to -->|eine Schicht tiefer sehen| pkt["Pakete, die wirklich über die Leitung gingen"]
    pkt --> q1["Keine Antwort auf SYN?"]
    pkt --> q2["Stille nach Connect?"]
    pkt --> q3["Mit RST abgerissen?"]
    pkt --> q4["Hat es das Ziel erreicht?"]

Abbildung 1: Das Log behält nur das Ergebnis; die Aufschlüsselung eines Timeouts lebt nur in den Paketen eine Schicht tiefer.

Typisch bleibt man an der Einschränkung „wir dürfen Wireshark auf dem Kundenserver nicht installieren“ hängen. Standorte, an denen Change Control oder eine Sicherheitsrichtlinie Zusatzsoftware für eine Untersuchung nicht genehmigt, sind nicht selten. Windows liefert jedoch bereits zwei Paketmitschnitt-Werkzeuge mit: pktmon und netsh trace. Mit den Inbox-OS-Werkzeugen mitschneiden, die Datei auf den eigenen PC mitnehmen und in Wireshark lesen — mit dieser Aufteilung sehen Sie Pakete auch auf einem install-gesperrten Standort.

Dieser Artikel richtet sich an IT-Personal in kleinen und mittleren Unternehmen und an Windows-Anwendungsentwickler. Er ordnet die Wahl zwischen pktmon, netsh trace und Wireshark und das praktische Vorgehen für jedes. Loopback-Fallen, die Entscheidung, auf Client oder Server mitzuschneiden, der Umgang damit, dass TLS die Nutzlast verbirgt, und die Korrelation des Mitschnitts mit dem Anwendungslog werden aus Primärquellen Stand August 2026 behandelt.

1. Zuerst das Fazit

• „Mit dem Inbox-Werkzeug mitschneiden, mit Wireshark lesen“ ist die Grundaufteilung vor Ort. Auch wenn Sie auf dem Kundenserver keine Software installieren dürfen, sind pktmon und netsh trace in Windows eingebaut. Wandeln Sie das mitgeschnittene Log nach pcapng und analysieren Sie es in Wireshark auf dem eigenen Rechner.¹²
• pktmon ist das Paketmitschnitt-Werkzeug in Windows 10 / Windows Server 2019 und später. Sie nutzen es in vier Schritten — Filter registrieren, starten, stoppen, wandeln — und seine besondere Stärke ist, zu sehen, welche Komponente des Netzwerkstapels das Paket verworfen hat (der Drop-Grund).³⁴
• netsh trace ist das ältere Inbox-Werkzeug; es kann ein Bündel ETW-Provider als „Szenario“ aktivieren. Neben Paketen hält es Ereignisse aus Windows-Komponenten fest, und mit persistent=yes kann der Mitschnitt einen Neustart überleben.⁵⁶
• Beide Werkzeuge schreiben ETL, das Wireshark nicht unverändert öffnet. Wandeln Sie mit pktmon etl2pcap für pktmon und mit Microsofts Open-Source-etl2pcapng für netsh trace nach pcapng.¹²
• Microsoft selbst zeigt auf „zuerst pktmon, dann netsh trace, wenn das nicht reicht, und Wireshark für die Protokollanalyse“. Die Aufteilung in diesem Artikel folgt dieser offiziellen Empfehlung.⁷
• Standardmäßig zeichnet pktmon nur die ersten 128 Bytes jedes Pakets auf. Wollen Sie die Nutzlast in Wireshark lesen, vergessen Sie beim Start nicht --pkt-size 0 (das ganze Paket aufzeichnen).⁸
• Verkehr zu localhost erscheint nicht in einem normalen Mitschnitt. Er geht nie durch eine NIC. Nutzen Sie Npcaps Loopback-Adapter in Wireshark oder pktmons Mitschnitt im Stapel mit den Inbox-Werkzeugen.⁹
• Auch wenn TLS die Nutzlast verbirgt, lernen Sie noch viel. Verbindungsaufbau, ob der TLS-Handshake gelang, RST und welche Seite schwieg bleiben sichtbar, auch wenn verschlüsselt. Entschlüsselung über SSLKEYLOGFILE ist eine Technik nur für die Entwicklungsumgebung.¹⁰
• Ein Mitschnitt enthält die Kommunikation selbst. Gehen Sie davon aus, dass Anmeldedaten und personenbezogene Daten enthalten sein können, und bauen Sie einen minimal nötigen Mitschnitt und das Einengen vor der Übergabe in das Verfahren ein.

2. Die drei Mitschnitt-Werkzeuge und wie man wählt

Zuerst eine Tabelle der Rollen der drei Werkzeuge.

In einem Satz: pktmon und netsh trace sind die „Mitschnitt“-Werkzeuge, Wireshark ist das „Lese“-Werkzeug. Wireshark kann auch mitschneiden, aber dort, wo Sie es nicht installieren dürfen, nicht. Umgekehrt können Sie Inbox-ETL in Text wandeln und lesen, aber ohne Anzeige-Filter und TCP-Analyse darauf zu starren ist Qual. „Vor Ort mit dem Inbox-Werkzeug mitschneiden, nach pcapng wandeln und in Wireshark auf dem eigenen Rechner lesen“ ist der kürzeste Weg auf einem eingeschränkten Standort.

flowchart TB
    accTitle: Mit dem Inbox-Werkzeug mitschneiden, mit Wireshark lesen
    accDescr: Vor Ort schneiden Sie ETL mit pktmon oder netsh trace mit, wandeln jeweils mit dem eigenen Werkzeug nach pcapng und analysieren in Wireshark auf dem eigenen Rechner
    pk["pktmon (Inbox)"] --> etla["ETL-Datei"]
    ns["netsh trace (Inbox)"] --> etlb["ETL+.cab"]
    etla -->|pktmon etl2pcap| pcap["pcapng"]
    etlb -->|etl2pcapng| pcap
    pcap --> ws["In Wireshark auf dem eigenen Rechner analysieren"]

Abbildung 2: Vor Ort schneiden Sie ETL mit den Inbox-Werkzeugen mit, wandeln nach pcapng und lesen in Wireshark auf dem eigenen Rechner.

Microsofts Leitfaden zur Untersuchung von Paketverlust hat dieselbe Form: zuerst mit pktmon mitschneiden und die Ursache eingrenzen, dann bei Bedarf zu Komponenten-Traces wie netsh trace start scenario=InternetClient übergehen und das Protokollverhalten in Wireshark analysieren.⁷

Als Voraussetzung, um zu lesen, was ein Paket wirklich zeigt, hilft auch ein Bild der gestapelten Schichten — Ethernet, IP, TCP, Anwendungsdaten. Die Schichtenanatomie ist in „Das OSI-Modell wirklich verstehen“ dargestellt.

3. pktmon in der Praxis — Filtern, starten, stoppen, wandeln

Der Grundablauf von pktmon hat vier Schritte. Führen Sie sie in einer privilegierten Konsole aus.

:: 1. Zuerst einen Filter registrieren, um das Ziel einzugrenzen (TCP 8443 auf Server 192.168.10.20)
pktmon filter add App8443 -i 192.168.10.20 -t tcp -p 8443
pktmon filter list

:: 2. Erfassung starten. Ganze Pakete aufzeichnen, in einem 1-GB-Ringpuffer überschreiben
pktmon start --capture --pkt-size 0 --file-name C:\temp\app-timeout.etl --file-size 1024 --log-mode circular

:: 3. Den Vorfall nachstellen. Während des Wartens Volumen und Verwürfe mit counters prüfen
pktmon counters --drop-reason

:: 4. Stoppen, dann nach pcapng für Wireshark wandeln
pktmon stop
pktmon etl2pcap C:\temp\app-timeout.etl --out C:\temp\app-timeout.pcapng

:: 5. Den registrierten Filter aufräumen (Filter bleiben, bis man sie ausdrücklich entfernt).
::    Hinweis: filter remove akzeptiert keinen Namen; es löscht „alle“ registrierten Filter.
::    Auf einem Rechner, auf dem noch Filter einer anderen Untersuchung liegen können, zuerst mit pktmon filter list prüfen
pktmon filter remove

flowchart TB
    accTitle: Grundverfahren von pktmon
    accDescr: Ziel mit einem Filter einengen, Mitschnitt starten, Vorfall reproduzieren, stoppen, mit etl2pcap nach pcapng wandeln und zuletzt den registrierten Filter entfernen
    fa["1. Ziel mit filter add einengen"] --> st["2. Mitschnitt mit start --capture starten"]
    st --> re["3. Vorfall reproduzieren"]
    re -.-> ct["Volumen und Drops mit counters prüfen"]
    re --> sp["4. Stoppen"]
    sp --> cv["Mit etl2pcap nach pcapng wandeln"]
    cv --> rm["5. Mit filter remove aufräumen"]

Abbildung 3: pktmon beginnt mit der Filterregistrierung, dann Mitschnitt, Stopp und Wandlung, und Sie entfernen den Filter am Ende ausdrücklich.

Punkte im Blick behalten:

• Registrieren Sie Filter, bevor Sie den Mitschnitt starten. Auch Microsofts Dokumentation empfiehlt nachdrücklich, vor dem Start einen Filter zu setzen, weil aller Verkehr zu laut ist. Filter können IP-Adresse, Port, MAC-Adresse, Protokoll, VLAN-ID usw. angeben, und Sie können bis zu 32 registrieren. Mehrere Filter sind ODER: ein Paket wird aufgezeichnet, wenn es einem davon entspricht.³
• Ein pktmon-Filter unterscheidet Quelle und Ziel nicht. -i 192.168.10.20 bedeutet „Pakete, in denen diese Adresse Quelle oder Ziel ist“. Die Richtung engen Sie später mit einem Wireshark-Anzeige-Filter nach der Wandlung ein.³
• Die Standard-Paketgröße ist 128 Bytes. Das reicht für Header-Analyse, aber wollen Sie auch Anwendungsdaten, zeichnen Sie das ganze Paket mit --pkt-size 0 auf.⁸
• Das Log ist standardmäßig im circular-Modus (Ringpuffer), Standardgröße 512 MB. Die Obergrenze ändern Sie mit --file-size, und --log-mode real-time schreibt in Echtzeit auf den Bildschirm und erzeugt keine Logdatei. Bestätigen Sie zuerst im Echtzeitmodus, dass Sie den relevanten Verkehr wirklich sehen, dann setzen Sie den Produktionsmitschnitt — so vermeiden Sie eine leere Aufnahme.⁸

flowchart TB
    accTitle: Wie pktmon-Filter greifen
    accDescr: Mehrere registrierte Filter zeichnen bei ODER-Treffer auf, die angegebene Adresse unterscheidet Quelle und Ziel nicht, und die Richtung wird später mit einem Wireshark-Anzeige-Filter nach der Wandlung eingeengt
    f1["Filter 1"] --> orc["Aufzeichnen wenn einer trifft"]
    f2["Filter 2"] --> orc
    f3["Filter 3 (bis 32)"] --> orc
    orc --> rec["Im Mitschnitt-Log aufgezeichnet (ODER)"]
    rec -.-> nodir["Quelle und Ziel werden nicht unterschieden"]
    nodir -.-> ws["Richtung in Wireshark nach der Wandlung einengen"]

Abbildung 4: Mehrere Filter wirken als ODER, und ob ein Host Quelle oder Ziel ist, engen Sie in Wireshark nach der Wandlung ein.

3.1. Was nur pktmon kann — sehen, wo ein Paket verworfen wurde

Der besondere Wert von pktmon gegenüber Wireshark ist, dass es ein Paket an mehreren Punkten im Netzwerkstapel mitschneidet, nicht an einer einzigen NIC, und berichten kann, wo und warum es verworfen (dropped) wurde. Weil Sie sehen, welche Komponente ein Paket erreichte und wo es verschwand, führen Drop-Gründe wie „MTU-Abweichung“ oder „VLAN-Filter“ ohne Blind-Suche zur Ursache.⁴

flowchart TB
    accTitle: pktmon schneidet an mehreren Punkten im Stapel mit
    accDescr: pktmon schneidet ein Paket an mehreren Punkten im Netzwerkstapel mit statt an einer einzigen NIC und kann mit Grund berichten, welche Komponente das Paket erreichte und wo es verworfen wurde
    pin["Paket"] --> p1["Am Punkt 1 mitgeschnitten"]
    p1 --> p2["Am Punkt 2 mitgeschnitten"]
    p2 --> p3["Am Punkt 3 verworfen"]
    p3 -.-> rz["Meldet Drop-Ort und -Grund"]
    rz -.-> ex["z. B. MTU-Abweichung oder VLAN-Filter"]

Abbildung 5: Mitschnitt an mehreren Punkten im Stapel sagt, wie weit ein Paket kam und wo es mit Grund gedroppt wurde.

• pktmon list zeigt die überwachbaren Netzwerkkomponenten (NICs, Protokollstapel, Filtertreiber usw.) und ihre IDs.
• pktmon counters --drop-reason listet Durchlass-/Drop-Zähler je Komponente und den jüngsten Drop-Grund. Praktisch als erster Schnitt, bevor Sie das Log analysieren.¹¹
• Wandeln Sie mit pktmon etl2txt in Text, und verworfene Pakete erscheinen mit drop und einem dropReason.³

Den Verdacht, „etwas im OS droppt das, bevor es die Anwendung erreicht“, können Sie mit Wireshark allein nicht klären. Diese Fähigkeit hilft zum Beispiel, einen Fall zu isolieren, in dem die Firewall wegen fehlender eingehender Regel droppt („Windows-Firewall und Business-Anwendungen“).

Ein Vorbehalt. pktmon zeichnet dasselbe Paket an mehreren Punkten im Stapel auf, daher kann die unveränderte Wandlung nach pcapng dasselbe Paket mehrfach erscheinen lassen. pcapng trägt nicht „welche Komponente das mitschnitt“, daher ist der Standardzug, mit --component-id einen Punkt zu wählen (oder Drops allein mit --drop-only in eine getrennte Datei zu legen).¹

flowchart TB
    accTitle: Warum dasselbe Paket nach pcapng-Wandlung zweimal erscheinen kann
    accDescr: pktmon zeichnet dasselbe Paket an mehreren Punkten im Stapel auf, pcapng behält nicht, welche Komponente es mitschnitt, daher können Duplikate erscheinen; der Standardzug ist, vor der Wandlung den Punkt mit component-id einzuengen oder Drops allein in eine drop-only-Datei zu legen
    same["Dasselbe Paket an mehreren Punkten aufgezeichnet"] --> conv["Unverändert nach pcapng wandeln"]
    conv --> lost["Mitschnittpunkt-Information wird nicht mitgenommen"]
    lost --> dup["Dasselbe Paket erscheint mehrfach"]
    dup --> c1["Punkt mit --component-id einengen"]
    dup --> c2["Getrennte Datei mit --drop-only"]

Abbildung 6: Mitschnittpunkt-Information wandert nicht nach pcapng, daher ist der Standardzug, den Punkt vor der Wandlung einzuengen.

4. netsh trace in der Praxis — Szenarien, ETL und Mitschnitte, die einen Neustart überleben

netsh trace ist der Tracing-Mechanismus, der länger in Windows ist als pktmon. Sein Merkmal: als „Szenario“ kann er die ganze Menge ETW-Provider zu diesem Problem auf einmal aktivieren.⁶

:: List available scenarios and inspect the providers in a scenario
netsh trace show scenarios
netsh trace show scenario netconnection

:: Start the capture. Packet capture included, 1GB circular buffer
netsh trace start scenario=netconnection capture=yes tracefile=C:\temp\nettrace.etl maxSize=1024 filemode=circular

:: Reproduce the incident, then stop (the merge takes a little time)
netsh trace stop

• Fügen Sie capture=yes hinzu, um Paketmitschnitt zu aktivieren, und engen Sie das Ziel mit einem Capture-Filter wie ipv4.address=192.168.10.20 ein. Die Filterliste steht in netsh trace show capturefilterHelp.⁶
• Beim Stoppen entsteht neben der ETL eine .cab-Datei. Die .cab hält Systeminformationen wie Adapterkonfiguration und OS-Build und dient damit auch der Umgebungserfassung.⁶
• Nur eine Trace-Sitzung kann gleichzeitig laufen. Bevor Sie einen weiteren Mitschnitt starten, prüfen Sie mit netsh trace show status, dass keine Rest-Sitzung noch läuft.⁶
• Fügen Sie persistent=yes hinzu, und die Sitzung überlebt einen Neustart. „Kommunikation scheitert einen Moment direkt nach dem Neustart“ oder „die Dienstverbindung beim Start scheitert“ — Vorfälle, die Sie nicht rechtzeitig von Hand starten können — ist das eigene Terrain von netsh trace.⁵

flowchart TB
    accTitle: Ein netsh-trace-Szenario mitschneiden
    accDescr: Start mit einem Szenario aktiviert ein gebündeltes ETW-Provider-Set, capture=yes schneidet auch Pakete mit, und Stoppen erzeugt eine ETL-Datei und eine .cab-Datei
    sc["Mit einem Szenario starten"] --> pv["Das Provider-Set aktivieren"]
    sc -->|capture=yes| pc["Pakete werden ebenfalls mitgeschnitten"]
    pv --> re["Vorfall reproduzieren"]
    pc --> re
    re --> sp["Stoppen"]
    sp --> etl["ETL-Datei"]
    sp --> cab[".cab (Systeminformationen)"]

Abbildung 7: Start mit einem Szenario aktiviert ein Provider-Bündel, und Stoppen erzeugt ETL und eine .cab.

4.1. ETL in Wireshark lesbar machen — etl2pcapng

netsh-trace-ETL lässt sich in Wireshark nicht unverändert öffnen. etl2pcapng, das Open-Source-Werkzeug, das Microsoft auf GitHub veröffentlicht, wandelt Pakete in einer mit netsh trace start capture=yes mitgeschnittenen ETL nach pcapng.²

etl2pcapng.exe C:\temp\nettrace.etl C:\temp\nettrace.pcapng

Bei der Wandlung schreibt etl2pcapng die beteiligte Prozess-ID jedes Pakets als Paketkommentar. In Wireshark „wessen Prozess dieser Verkehr ist“ zu sehen hilft, wenn mehrere Anwendungen auf demselben Server sprechen.²

Die ETW-Ereignisse (Windows-interne Ereignisse, die die Szenario-Provider aufzeichneten) werden nicht nach pcapng gewandelt. Wollen Sie auch die Ereignisse, wandeln Sie mit netsh trace convert input=C:\temp\nettrace.etl in Text oder Ähnliches oder öffnen Sie die ETL in Windows Performance Analyzer.⁵⁷

flowchart TB
    accTitle: netsh-trace-ETL lesen teilt sich in zwei Wege
    accDescr: Pakete in der ETL wandeln mit etl2pcapng nach pcapng und werden in Wireshark gelesen; ETW-Ereignisse werden nicht nach pcapng gewandelt, daher lesen Sie sie mit netsh trace convert oder Windows Performance Analyzer
    etl["netsh-trace-ETL"] --> pk["Pakete"]
    etl --> ev["ETW-Ereignisse"]
    pk -->|etl2pcapng| pc["Nach pcapng wandeln"]
    pc --> ws["In Wireshark lesen"]
    pc -.-> pid["Prozess-ID bleibt als Kommentar"]
    ev -.-> no["Nicht nach pcapng gewandelt"]
    no --> alt["Mit convert oder WPA lesen"]

Abbildung 8: Von der ETL werden Pakete nach pcapng gewandelt und gelesen; ETW-Ereignisse liest man anders.

5. Erster Blick aufs Lesen in Wireshark — Anzeige-Filter und TCP-Analyse

Sobald Sie die pcapng öffnen, schneiden Sie zuerst das Rauschen mit einem Anzeige-Filter weg. Übliche stehen in der Tabelle.¹²¹³

tcp.analysis.* sind Analyse-Flags, die Wireshark vergibt, indem es TCP-Sequenznummern verfolgt. Neuübertragungen, doppelte ACKs, Out-of-Order, ZeroWindow und Ähnliches werden mechanisch erfasst, daher ist der Standardweg zu lesen, zuerst tcp.analysis.flags einzugeben und die „sieht aus wie ein Problem“-Stellen aufzulisten.¹³

In einer Timeout-Untersuchung suchen Sie der Reihe nach die folgenden Formen.

1. Ist der Drei-Wege-Handshake vollständig? Sind die drei Pakete SYN → SYN/ACK → ACK alle da? Wird SYN ohne Antwort wiederholt, hat es den Peer nie erreicht oder wurde unterwegs still verworfen (das typische Firewall-Muster).
2. Welche Seite sandte den RST? Ein sofortiger RST auf SYN bedeutet, niemand horcht am Zielport; ein RST nach aufgebauter Verbindung bedeutet, eine Seite hat die Verbindung erzwungen beendet. Die Quell-IP des RST ist der direkte Beweis für „wer schnitt“.
3. Laufen Neuübertragungen weiter? Wiederholte Neuübertragung desselben Segments ist das Zeichen, dass die Bestätigung (ACK) nicht zum Sender zurückkommt. Ob die ausgehenden Daten verloren gingen oder der zurückkehrende ACK, lässt sich aus einem einseitigen Mitschnitt nicht klären (deshalb zählt „auf beiden Seiten mitschneiden“ im nächsten Kapitel). Neuübertragungen und Timeouts sind tiefer in „TCP-Retransmission als Ursache für Kommunikationsausfälle bei Industriekameras“ behandelt.
4. Ist ZeroWindow vorhanden? Das ist das Zeichen, dass die empfangende Anwendung nicht vom Socket liest und der Empfangspuffer voll ist. Es begründet den Verdacht auf das Design der empfangenden Anwendung („Der Irrglaube, man könne über TCP pro Send genau eine Einheit empfangen“) statt auf das Netz.

flowchart TB
    accTitle: Reihenfolge der Formen in einer Timeout-Untersuchung
    accDescr: Abschluss des Drei-Wege-Handshakes, Vorhandensein und Quelle eines RST, weiterlaufende Neuübertragungen, dann ZeroWindow bestätigen, um die Ursache erst zu markieren
    hs{"Bekam SYN eine Antwort?"} -->|nein| ng["Nie angekommen（Typische Firewall）"]
    hs -->|ja| rs{"Ist ein RST da?"}
    rs -->|ja| who["RST-Quelle hat getrennt"]
    rs -->|nein| rt{"Laufen Neuübertragungen weiter?"}
    rt -->|ja| ack["ACK kommt nicht zurück"]
    rt -->|nein| zw{"ZeroWindow vorhanden?"}
    zw -->|ja| app["Empfänger liest nicht"]

Abbildung 9: Handshake, RST, Neuübertragung, dann ZeroWindow in dieser Reihenfolge einzuengen sagt, wo Sie als Nächstes hinsehen.

Bevor Sie Pakete einzeln lesen, hilft es, das Gesamtbild mit den Statistikfunktionen aufzunehmen. [Statistics] → [Conversations] ist eine Liste „welches IP-Paar / Port-Paar sprach, von wann bis wann, wie viel“, damit Sie die relevante Unterhaltung identifizieren und dann nur darauf filtern. [Statistics] → [I/O Graph] ist ein Volumendiagramm über die Zeit; Formen wie „ab diesem Zeitpunkt schwieg eine Richtung“ springen ins Auge. Rechtsklick auf die relevante TCP-Unterhaltung und [Follow] → [TCP Stream] lässt Sie den Austausch dieser Verbindung als Klartext durchlesen.

flowchart TB
    accTitle: Mit Statistik das Bild aufnehmen, dann auf eine Unterhaltung einengen
    accDescr: In Conversations auflisten, welche Unterhaltungen wann wie viel sprachen, das stille Intervall aus dem I/O Graph holen, auf die relevante Unterhaltung filtern und als TCP-Strom durchlesen
    ov["Mit Statistik das Gesamtbild aufnehmen"] --> cv["Unterhaltungsliste in Conversations"]
    ov --> io["Volumen im I/O Graph sehen"]
    cv --> flt["Auf die relevante Unterhaltung filtern"]
    io -.-> mute["Das stille Intervall wird sichtbar"]
    flt --> fs["Als TCP-Strom durchlesen"]

Abbildung 10: Bevor Sie paketweise lesen, nehmen Sie das Bild mit Statistik auf, engen auf die relevante Unterhaltung ein und lesen sie dann durch.

6. Die Loopback-Falle — Verkehr zu localhost geht nie durch eine NIC

Die Kommunikation zwischen Anwendungen auf demselben PC zu untersuchen — etwa eine Fachanwendung, die sich mit einem Zwischendienst auf localhost:8080 verbindet — und bei „in Wireshark erscheint nichts“ hängen zu bleiben, ist eine klassische Falle.

Die Ursache ist klar. Verkehr zu localhost (127.0.0.1) geht nie durch eine physische NIC; er wird auf dem internen Loopback-Pfad des Betriebssystems umgedreht. Ein normaler Mitschnitt, der einen physischen Adapter anvisiert, sieht ihn daher nie.⁹

flowchart TB
    accTitle: Warum Verkehr zu localhost nicht im Mitschnitt erscheint
    accDescr: Verkehr zu localhost geht nie durch eine physische NIC und wird auf dem internen Loopback-Pfad des OS umgedreht, erscheint daher nie in einem normalen Mitschnitt auf einen physischen Adapter
    app["Anwendung"] --> stack["Netzwerkstapel"]
    stack -->|extern| nic["Physische NIC"]
    nic --> seen["Im normalen Mitschnitt sichtbar"]
    stack -->|localhost| lo["Im OS umgedreht"]
    lo -.-> miss["Nicht im normalen Mitschnitt"]
    lo -.-> alt["Npcap-Loopback oder pktmon"]

Abbildung 11: Verkehr zu localhost wird vor der NIC umgedreht, ein physischer-Adapter-Mitschnitt sieht ihn nie.

Es gibt zwei Wege.

• Beim Mitschnitt in Wireshark: Wählen Sie Npcaps „Adapter for loopback traffic capture“ als Mitschnittziel. Das Windows-Wireshark-Installationsprogramm (3.0 und später) bringt Npcap mit, ist Wireshark schon installiert, brauchen Sie nichts Extra.⁹
• Beim Mitschnitt mit den Inbox-Werkzeugen: pktmon schneidet an mehreren Punkten im Netzwerkstapel mit, nicht außerhalb der NIC⁴, und kann daher auch Loopback-Verkehr beobachten. Um sicher zu sein, bestätigen Sie vor einem Produktions-Warten-auf-Repro auf diesem Rechner mit der Echtzeitanzeige pktmon start -c -m real-time, dass der relevante Loopback-Verkehr wirklich sichtbar ist.

Achten Sie auch auf zwei Verwechslungen.

• „localhost“ kann nach IPv6 ::1 auflösen. Die Anwendung verbindet sich mit IPv6 ::1, der Untersucher schaut nur auf 127.0.0.1 (IPv4) und schließt fälschlich „es gibt keinen Verkehr“. Ziehen Sie den Anzeige-Filter über beide, wie in ip.addr == 127.0.0.1 || ipv6.addr == ::1, oder machen Sie die Zieleinstellung der Anwendung zu einer ausdrücklichen Adresse.⁹
• Verkehr zur eigenen echten IP geht ebenfalls nicht auf die Leitung. Verbindet sich derselbe PC von 192.168.10.5 nach 192.168.10.5, ist das Ziel eine echte IP, das OS dreht trotzdem intern um. Merken Sie: „Ich habe eine echte IP angegeben, also geht es durch die NIC“ ist nicht garantiert.

flowchart TB
    accTitle: Die Verwechslung, wenn localhost nach IPv6 auflöst
    accDescr: Das localhost einer Anwendung kann nach IPv6 ::1 auflösen, und schaut der Untersucher nur auf 127.0.0.1, schließt er fälschlich, es gebe keinen Verkehr; ziehen Sie den Anzeige-Filter über beide Adressen oder bestätigen Sie das Ziel als ausdrückliche Adresse
    app["App verbindet sich mit localhost"] --> v6["Löst tatsächlich nach ::1 (IPv6) auf"]
    look["Untersucher schaut nur auf 127.0.0.1"] --> none["Auf dem Bildschirm erscheint nichts"]
    v6 --> none
    none --> fix1["Filter über beide Adressen ziehen"]
    none --> fix2["Ziel zur ausdrücklichen Adresse machen"]

Abbildung 12: Achten Sie auf die Verwechslung, dass localhost nach ::1 auflöst und nur 127.0.0.1 zu „es gibt keinen Verkehr“ führt.

7. Wo mitschneiden — eine Seite, beide Seiten und Uhrensynchronisation

Der Wert eines Mitschnitts entscheidet sich an „wo Sie mitgeschnitten haben“. Die Faustregel lautet wie folgt.

Ein einseitiger Mitschnitt sagt nur „die Tatsachen von meiner Position aus“. Weiterlaufende Neuübertragungen auf dem Client unterscheiden nicht, ob das gesandte Paket auf dem Pfad verschwand oder am Server ankam und die Antwort verschwand. Auf beiden Seiten mitschneiden und nebeneinanderlegen klärt „der Client sandte / der Server empfing nie“ — welche Seite schwieg. Müssen Sie die Verantwortungsgrenze (Anwendung, OS, Netzwerkgerät oder Gegenseite) klären, lohnt es, von Anfang an einen beidseitigen Mitschnitt vorzubereiten.

flowchart TB
    accTitle: Was einseitige und beidseitige Mitschnitte sagen
    accDescr: Ein einseitiger Mitschnitt kann nicht unterscheiden, ob das ausgehende Paket oder die zurückkehrende Antwort verschwand; auf beiden Seiten mitschneiden und nebeneinanderlegen klärt, welche Seite schwieg
    one["Auf einer Seite mitschneiden"] --> fact["Tatsachen von Ihrer Seite"]
    fact --> und["Ausgang oder Rückweg?"]
    both["Auf beiden Seiten mitschneiden"] --> mt["Nebeneinanderlegen"]
    mt --> fix["Welche Seite schwieg"]
    mt -.-> pre["Uhrensynchronisation nötig"]

Abbildung 13: Eine Seite zeigt nur die Tatsachen, die Sie sahen; beide Seiten nebeneinanderzulegen klärt erst die Verantwortungsgrenze.

7.1. Die Voraussetzung der Korrelation ist Uhrensynchronisation

Um Mitschnitte beider Seiten nebeneinanderzulegen, müssen die Uhren beider Maschinen übereinstimmen. Prüfen und notieren Sie vor dem Mitschnitt den Uhrenversatz.

:: Check time-sync status (sync source, last sync time)
w32tm /query /status

:: Measure the offset against the peer server (5 samples)
w32tm /stripchart /computer:sv-app01 /dataonly /samples:5

w32tm /stripchart ist der Befehl, der den Zeitversatz zwischen Ihnen und dem Gegenrechner zeigt, und er wird zur Grundlage einer Korrektur wie „die Serveruhr war +0,8 Sekunden“, wenn Sie die Mitschnitte nebeneinanderlegen.¹⁴ In einer Umgebung mit großem Versatz ist es am Ende kürzer, zuerst die Zeitsynchronisation zu reparieren und dann mitzuschneiden.

flowchart TB
    accTitle: Verfahren zum Prüfen des Uhrenversatzes vor der Korrelation
    accDescr: Eigenen Sync-Status mit w32tm bestätigen, Versatz gegen den Gegen-Server mit stripchart messen und notieren, diesen Versatz als Korrekturgrundlage beim Nebeneinanderlegen nutzen, und bei großem Versatz zuerst die Sync reparieren und dann mitschneiden
    st["Sync-Status mit query prüfen"] --> mc["Versatz mit stripchart messen"]
    mc --> rc["Versatz notieren"]
    rc --> use["Grundlage der Korrektur zur Korrelationszeit"]
    mc -.-> big["Bei großem Versatz zuerst Sync reparieren"]

Abbildung 14: Messen und notieren Sie den Uhrenversatz vor dem Mitschnitt und nutzen Sie ihn als Korrekturgrundlage, wenn Sie die Mitschnitte nebeneinanderlegen.

7.2. Für „wir wissen nicht, wann es passiert“ — ein Ringpuffer

Für einen Vorfall, dessen Reproduktionsbedingungen unbekannt sind, ist der Grundzug, einen Ringpuffer laufen zu lassen und ihn zu stoppen, wenn der Vorfall eintritt.

• pktmon: Standard ist der circular-Modus. Setzen Sie die Obergrenze (MB) mit --file-size; ältere Pakete werden überschrieben.⁸
• netsh trace: Geben Sie es als maxSize=1024 filemode=circular an.⁵
• Wireshark: Unter [Capture] → [Options] → [Output] können Sie „mehrere Dateien + Ringpuffer“ konfigurieren. Es rotiert nach Dateigröße oder Zeit und behält nur die neuesten N Dateien, Sie können lange mit einer Festplatten-Obergrenze laufen.¹⁵

In jedem Fall teilen Sie mit der Person vor Ort die Regel: wenn der Vorfall eintritt, „zuerst die Uhrzeit notieren, dann“ den Mitschnitt stoppen. Ein Ringpuffer löscht die Vergangenheit, je länger Sie warten; ist der Weg vom Auftreten zum Stopp lang, wird das relevante Intervall überschrieben.

flowchart TB
    accTitle: Mit einem Ringpuffer-Mitschnitt warten
    accDescr: Bei unbekannten Reproduktionsbedingungen einen Ringpuffer laufen lassen und beim Vorfall die Uhrzeit notieren und rasch stoppen; ein spätes Stoppen überschreibt ältere Pakete und das relevante Intervall verschwindet
    st["Ringpuffer-Mitschnitt starten"] --> wt["Laufen lassen und warten"]
    wt --> ev["Der Vorfall tritt ein"]
    ev --> memo["Uhrzeit notieren"]
    memo --> sp["Rasch stoppen"]
    wt -.-> ow["Ältere Pakete werden überschrieben"]
    ow -.-> late["Ein spätes Stoppen löscht das relevante Intervall"]

Abbildung 15: Ein Ringpuffer löscht die Vergangenheit, je länger Sie warten; haben Sie die Uhrzeit notiert, stoppen Sie rasch.

8. Das Problem, dass TLS die Nutzlast verbirgt — was Sie trotzdem sehen

Der meiste Fachverkehr heute ist TLS (HTTPS). Man neigt zu „ist es verschlüsselt, nützt Mitschnitt nichts“, aber das meiste, was Sie in einer Timeout-Untersuchung wollen, bleibt mit der Verschlüsselung an Ort sichtbar.

• Ob die TCP-Verbindung aufgebaut wurde (Drei-Wege-Handshake)
• Wie weit der TLS-Handshake kam — ob ServerHello auf ClientHello zurückkam, ob er mit RST oder Alert während des Handshakes abgebrochen wurde
• Der Zielhostname auf ClientHello (SNI) und die ausgehandelte TLS-Version
• Nach aufgebauter Verbindung, welche Seite aufhörte zu senden. Der Ort der Stille, Neuübertragungen, RST oder ein sauberes Schließen (FIN)

Mit anderen Worten: „kann nicht verbinden“, „bricht in der Mitte ab“ und „keine Antwort kommt zurück“ zu isolieren braucht fast nie Nutzlast-Entschlüsselung. Was Verschlüsselung verliert, ist „was sie sagten“; „wer schwieg, und wann“ bleibt.

flowchart TB
    accTitle: Was ein TLS-Mitschnitt zeigen kann und nicht
    accDescr: Verschlüsselung verbirgt nur die Nutzlast der Anwendungsdaten; TCP-Verbindungsaufbau, Erfolg oder Scheitern des TLS-Handshakes, SNI und TLS-Version, RST und welche Seite schwieg bleiben mit der Verschlüsselung an Ort sichtbar
    tls["TLS-Verkehr-Mitschnitt"] --> vis["Sichtbar"]
    tls --> hid["Nicht sichtbar"]
    vis --> v1["TCP-Verbindungsaufbau"]
    vis --> v2["TLS-Ergebnis und SNI"]
    vis --> v3["RST / wer schwieg"]
    hid --> h1["Nutzlast der Anwendungsdaten"]

Abbildung 16: Verschlüsselung verliert nur die Nutzlast; das Skelett der Unterhaltung bleibt mit TLS an Ort lesbar.

Wenn Sie die Nutzlast trotzdem brauchen, kann Wireshark TLS mit Sitzungsschlüsseln entschlüsseln, die über die Umgebungsvariable SSLKEYLOGFILE geschrieben werden. Die Unterstützung beschränkt sich auf einige Implementierungen wie Firefox, Chrome, Chromium-basiertes Edge und OpenSSL-Familie-Bibliotheken; das inbox-SChannel von Windows (Anwendungen, die WinHTTP oder WinINET nutzen) unterstützt diesen Mechanismus nicht.¹⁰ Weil „der Sitzungsschlüssel wird in eine Datei geschrieben“ bedeutet, dass jeder mit dieser Datei die ganze Unterhaltung entschlüsseln kann, ist das keine Produktions-Technik; behandeln Sie sie als Reproduktion und Debugging in der Entwicklungsumgebung.

flowchart TB
    accTitle: Wie SSLKEYLOGFILE-Entschlüsselung funktioniert und ihre Grenzen
    accDescr: Über SSLKEYLOGFILE geschriebene Sitzungsschlüssel lassen Wireshark TLS entschlüsseln, aber nur einige Implementierungen wie Firefox und die Chrome-Familie unterstützen das und SChannel nicht; wer die Schlüsseldatei hat, kann die Unterhaltung entschlüsseln, daher als Technik nur für die Entwicklungsumgebung behandeln
    env["SSLKEYLOGFILE setzen"] --> key["Sitzungsschlüssel schreiben"]
    key --> ws["In Wireshark lesen"]
    key -.-> risk["Schlüsselinhaber kann entschlüsseln"]
    risk -.-> dev["Nur Entwicklung"]
    env -.-> sup["Nur einige TLS-Stapel"]
    sup -.-> sch["SChannel: keine Unterstützung"]

Abbildung 17: Sitzungsschlüssel herauszuschreiben kann entschlüsseln, aber unterstützte Implementierungen sind begrenzt, und die Natur des Schlüssels macht es zu einer Technik nur für die Entwicklungsumgebung.

Geht Verkehr durch einen internen Proxy, ist das Ziel im Mitschnitt der Proxy-Server, und TLS fließt in einem CONNECT-Tunnel. Die Vorfrage, zu welchem Proxy die Anwendung überhaupt geht, ist im gleichentägigen Begleitartikel „Unternehmensproxys und Windows-Anwendungen — Proxy-Auflösung in WinINET, WinHTTP und .NET sortieren“ geordnet.

9. Mit dem Anwendungslog korrelieren — Zeit auf dieselbe Achse legen

Ein Mitschnitt allein erzeugt selten die Schlussfolgerung. Der entscheidende Zug in der Praxis ist, eine Zeile des Anwendungslogs und einen Paket-Hin-und-Zurück auf dieselbe Zeitachse zu legen.

Das Verfahren sieht so aus.

1. Identifizieren Sie die Vorfallszeit aus dem Anwendungslog (zum Beispiel eine Timeout-Ausnahme um 10:23:41). Ist der Timeout-Wert 30 Sekunden, sollte der Start um 10:23:11 liegen.
2. Stellen Sie die Zeitanzeige von Wireshark auf [View] → [Time Display Format] → [Date and Time of Day] und engen Sie das Intervall mit einem Anzeige-Filter ein (Sie können auch nach Zeit filtern, wie in frame.time >= "2026-08-20 10:23:00" && frame.time <= "2026-08-20 10:24:00").
3. Bestätigen Sie in diesem Intervall die Reihenfolge aus Kapitel 5 (Handshake → RST → Neuübertragung → ZeroWindow). Können Sie bis „30 Sekunden vor der Timeout-Zeit des Logs wurde ein SYN gesandt, danach nur SYN-Neuübertragungen“ ausrichten, ist das „Timeout“ des Logs durch die Beobachtung „an diesem Mitschnittpunkt kam überhaupt keine Antwort zurück“ ersetzt (ob das SYN den Peer nie erreichte oder der zurückkehrende SYN/ACK auf dem Rückweg verloren ging, lässt sich von diesem Mitschnittpunkt allein nicht klären. Müssen Sie es klären, schneiden Sie auf dem Server mit und legen Sie sie nebeneinander).
4. Korrigieren Sie immer den Versatz zwischen Mitschnittzeit und Logzeit (den in Abschnitt 7.1 gemessenen Uhrenversatz und die Zeitzonenangabe des Logs). Ein paar Sekunden Korrelationsfehler nageln die falsche Unterhaltung als Täter fest.

flowchart TB
    accTitle: Verfahren, Anwendungslog und Pakete nebeneinanderzulegen
    accDescr: Vorfallszeit aus dem Anwendungslog identifizieren, Startzeit aus dem Timeout-Wert zurückrechnen, Intervall in Wireshark mit einem Anzeige-Filter einengen, Formen der Reihe nach bestätigen, Uhrenversatz korrigieren und auf dieselbe Zeitachse legen
    lg["1. Vorfallszeit aus dem Log identifizieren"] --> rev["Start aus dem Timeout-Wert zurückrechnen"]
    rev --> flt["2. Intervall mit einem Anzeige-Filter einengen"]
    flt --> chk["3. Formen in der Reihenfolge aus Kapitel 5 bestätigen"]
    chk --> adj["4. Uhrenversatz korrigieren"]
    adj --> done["Das eine Wort des Logs wird eine Beobachtung"]

Abbildung 18: Engen Sie das Intervall aus der Logzeit ein, bestätigen Sie die Form, korrigieren Sie den Uhrenversatz und legen Sie sie auf dieselbe Achse.

Wenn Sie Untersuchungsergebnisse an Dritte (einen Hersteller, einen Carrier, das Netzwerkpersonal des Kunden) übergeben, ist das Rauschen vor der Übergabe mit einem Filter wegzuschneiden Höflichkeit und Sicherheitsmaßnahme. In Wireshark engen Sie mit einem Anzeige-Filter auf die relevante Unterhaltung ein und speichern „nur angezeigte Pakete“ mit [File] → [Export Specified Packets], und Sie erhalten eine kleine pcapng nur des nötigen Bereichs.

Zuletzt eine Behandlungswarnung. Eine Mitschnittdatei enthält die Kommunikation selbst. Sie kann Anmeldedaten aus Klartextprotokollen, HTTP-Cookies und API-Schlüssel, den Inhalt von Mail oder Berichten und personenbezogene Daten enthalten. Entscheiden Sie die folgenden drei Punkte als Satz mit dem Mitschnittverfahren.

• Minimal nötiger Mitschnitt: Engen Sie das Ziel mit den Filtern vor dem Mitschnitt (Kapitel 3 und 4) ein und halten Sie das Zeitfenster so kurz wie möglich. Machen Sie auf einer Kundenumgebung kein „einfach alles mitschneiden“
• Vor der Übergabe einengen: Exportieren Sie nur die relevante Unterhaltung; nehmen Sie fremden Drittverkehr nicht mit. Bleiben sensible Teile, vereinbaren Sie mit dem Empfänger Maskierung oder einen anderen Weg
• Aufbewahrung und Löschung: Entscheiden Sie, wo Mitschnittdateien liegen, wie lange und wann sie gelöscht werden, und löschen Sie sie, wenn die Untersuchung fertig ist

flowchart TB
    accTitle: Drei Entscheidungen vor der Übergabe einer Mitschnittdatei
    accDescr: Ein Mitschnitt enthält die Kommunikation selbst, daher entscheiden Sie als Satz mit dem Mitschnittverfahren, dass Sie mit Filtern vor dem Mitschnitt und einem Zeitfenster auf das Minimum einengen, vor der Übergabe nur die relevante Unterhaltung extrahieren, damit fremder Verkehr nicht enthalten ist, und Aufbewahrungsort und -dauer festlegen und nach der Untersuchung löschen
    cap["Mitschnitt = der Verkehr"] --> p1["Das Minimum mitschneiden"]
    cap --> p2["Zuerst das Ziel extrahieren"]
    cap --> p3["Aufbewahrung setzen, löschen"]
    p2 -.-> exp["Filtern und exportieren"]

Abbildung 19: Entscheiden Sie Minimalmitschnitt, Einengen vor der Übergabe sowie Aufbewahrung und Löschung als Satz mit dem Mitschnittverfahren.

10. Zusammenfassung

• Eine Schicht unter dem „Timeout“ des Anwendungslogs liegt die Tatsache der Pakete, die wirklich über die Leitung gingen. Ob SYN keine Antwort bekam, ein RST abriss, Neuübertragungen weiterliefen oder ZeroWindow erschien, ändert, wo Sie als Nächstes hinsehen.
• Auch auf einem Standort, auf dem Sie Wireshark nicht installieren dürfen, können Sie mit den Windows-Inbox-Werkzeugen pktmon und netsh trace mitschneiden. Mit dem Inbox-Werkzeug mitschneiden, mit Wireshark auf dem eigenen Rechner lesen — diese Aufteilung ist die Grundform.
• pktmon hat vier Schritte: Filter registrieren → pktmon start --capture → pktmon stop → pktmon etl2pcap. Standardmäßig ist auf 128 Bytes gekürzt, wollen Sie die Nutzlast, vergessen Sie --pkt-size 0 nicht. Drop-Ort und -Grund zu sehen ist eine Stärke, die nur pktmon hat.
• netsh trace schneidet ein Bündel ETW-Provider als Szenario mit, und mit persistent=yes kann es einen Neustart überleben. Wandeln Sie die ETL mit etl2pcapng nach pcapng, um sie zu lesen.
• In Wireshark beginnen Sie bei tcp.analysis.flags und suchen Handshake, RST, Neuübertragung und ZeroWindow in dieser Reihenfolge. Es geht schneller, wenn Sie zuerst mit Conversations und dem I/O Graph das Bild aufnehmen und dann einengen.
• Verkehr zu localhost geht nie durch eine NIC, Sie können ihn nicht auf dem gewöhnlichen Weg mitschneiden. Nutzen Sie Npcaps Loopback-Adapter oder pktmons Mitschnitt im Stapel.
• Auf beiden Seiten mitschneiden und nebeneinanderlegen klärt „welche Seite schwieg“. Die Voraussetzung ist Uhrensynchronisation (w32tm). Für einen Vorfall mit unbekannten Reproduktionsbedingungen warten Sie mit einem Ringpuffer.
• Auch unter TLS ist das Skelett der Unterhaltung sichtbar. Behandeln Sie Entschlüsselung (SSLKEYLOGFILE) als Technik nur für die Entwicklungsumgebung und die Mitschnittdatei selbst als vertraulich: bauen Sie Minimalmitschnitt, Einengen und Löschen in den Betrieb ein.

Paketmitschnitt gilt oft als „Werkzeug des Netzwerkspezialisten“, in der Praxis ist er ein untersuchendes Werkzeug auf der Anwendungsseite, das erst etwas bedeutet, wenn Sie es mit dem Anwendungslog nebeneinanderlegen. Wenn eine Untersuchung das nächste Mal beim einen Wort „Timeout“ stehen bleibt, gehen Sie eine Schicht tiefer schauen.

Weiterführende Artikel

• TCP-Retransmission als Ursache für Kommunikationsausfälle bei Industriekameras – Ursachensuche und Eingrenzung
• Der Irrglaube, man könne über TCP pro Send genau eine Einheit empfangen ── Empfangslogik entwerfen, die es als Bytestrom behandelt
• Das OSI-Modell wirklich verstehen — eine einzelne HTTP-Anfrage in ihre sieben Schichten zerlegen
• Process Monitor (ProcMon) Praxisleitfaden — „Konfiguration wird nicht gelesen“ und ACCESS DENIED in 10 Minuten identifizieren
• Windows-Firewall und Business-Anwendungen — Eingehende Regeln über das Installationsprogramm registrieren
• Unternehmensproxys und Windows-Anwendungen — Proxy-Auflösung in WinINET, WinHTTP und .NET sortieren

Zugehörige Beratungsfelder

KomuraSoft LLC übernimmt kommunikationsbedingte Fehleruntersuchungen wie „die Kommunikation der Fachanwendung scheitert von Zeit zu Zeit und wir finden die Ursache nicht“ und „wir wollen einen Verbindungsfehler isolieren, der nur auf der Kundenumgebung auftritt“. Wir nehmen Mitschnitt-Entwurf (wo, was und wie viel), Wireshark-Analyse, Korrelation mit dem Anwendungslog und die Korrektur auf der Anwendungsseite als ein durchgehendes Stück Arbeit.

• Windows-Anwendungsentwicklung
• Fehleruntersuchung und Ursachenanalyse
• Technische Beratung und Design-Review
• Kontakt

Quellen

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Wie fange ich Pakete auf einem Kundenserver, auf dem ich Wireshark nicht installieren darf?

Nutzen Sie die mitgelieferten Windows-Werkzeuge pktmon oder netsh trace — zusätzliche Software ist nicht nötig. Bei pktmon registrieren Sie in einer privilegierten Konsole einen Filter, starten den Mitschnitt mit pktmon start --capture und beenden ihn mit pktmon stop. Die entstandene ETL-Datei lässt sich mit pktmon etl2pcap nach pcapng wandeln, die Analyse holen Sie sich in Wireshark auf dem eigenen Rechner. „Mit dem Inbox-Werkzeug mitschneiden, mit Wireshark lesen“ ist die Grundaufteilung auf Installations-gesperrten Standorten.

Soll ich pktmon oder netsh trace verwenden?

Hat das Betriebssystem pktmon (Windows 10 / Windows Server 2019 und später), beginnen Sie mit pktmon. Die Befehle sind einfach, Sie sehen, welche Komponente des Netzwerkstapels das Paket verworfen hat (der Drop-Grund), und die pcapng-Wandlung ist in sich geschlossen. netsh trace ist die bessere Wahl, wenn Sie auf einem älteren OS ohne pktmon mitschneiden, wenn Sie ETW-Ereignisse von Windows-Komponenten als Szenario sammeln wollen oder wenn der Mitschnitt mit persistent=yes einen Neustart überleben soll. Auch Microsofts eigene Fehlersuche-Materialien zeigen diese Reihenfolge: zuerst pktmon, dann netsh trace, wenn das nicht reicht.

Warum erscheint Verkehr zu localhost (127.0.0.1) nicht in Wireshark?

Verkehr zu localhost geht nie durch eine physische NIC; er wird auf dem internen Loopback-Pfad des Betriebssystems umgedreht. Ein normaler Mitschnitt, der einen physischen Adapter anvisiert, sieht ihn daher nie. In Wireshark wählen Sie Npcaps „Adapter for loopback traffic capture“ und können Loopback-Verkehr mitschneiden. pktmon schneidet innerhalb des Netzwerkstapels mit und kann Loopback-Verkehr ebenfalls beobachten. Eine weitere häufige Verwechslung: „localhost“ löst nach IPv6 ::1 auf, ein Bildschirm, der auf 127.0.0.1 wartet, zeigt nichts — bestätigen Sie, indem Sie die Adresse ausdrücklich angeben.

Kann ich den Inhalt von HTTPS-(TLS-)Verkehr in einem Paketmitschnitt sehen?

Die Nutzlast der Anwendungsdaten ist verschlüsselt und nicht sichtbar. Das „Skelett“ der Unterhaltung — TCP-Auf- und -Abbau, ob der TLS-Handshake gelang, ein RST-Abbruch, welche Seite nicht mehr antwortete — bleibt auch verschlüsselt sichtbar, die meisten Timeout-Untersuchungen kommen mit unentschlüsseltem TLS aus. Brauchen Sie die Nutzlast, gibt es die Entschlüsselung über SSLKEYLOGFILE, aber nur einige TLS-Implementierungen wie Firefox und die Chrome-Familie unterstützen sie; das inbox-SChannel von Windows nicht. Der Mechanismus schreibt Schlüsselmaterial heraus, behandeln Sie ihn als Option nur für die Entwicklungsumgebung.

Ist es sicher, eine Mitschnittdatei an einen externen Support zu schicken?

Sie unverändert zu schicken ist gefährlich. Ein Mitschnitt enthält die Kommunikation selbst und kann Anmeldedaten aus Klartextprotokollen, Cookies, API-Schlüssel und personenbezogene Daten enthalten. Zuerst, zur Mitschnittzeit, engen Sie Filter und Zeitfenster auf das nötige Minimum ein, und bevor Sie übergeben, extrahieren Sie nur die Zielunterhaltung mit einem Wireshark-Anzeige-Filter und exportieren sie. Für das, was bleibt, vereinbaren Sie mit dem Empfänger den Umgang mit sensiblen Teilen (Maskieren oder auf anderem Weg liefern), bevor Sie senden. Legen Sie im Voraus fest, wie lange Mitschnittdateien aufbewahrt und wann sie gelöscht werden.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.