Fireplace Motiv 1 Neu
TeamViewer Motive 4

Win11 Netzwerk-Bug analysieren

AffeMitWaffe_

Cadet 4th Year
Registriert
Juli 2022
Beiträge
116
Guten Tag zusammen,

ich sitze gerade an einem Fall.
In meinem Testszenario geht es um zwei Windows 11 Rechner.
Das Szenario geht so:

1. PC1 anschalten und PC2 per
Code:
ping -t <IP>
anpingen.
2. PC2 einschalten und warten, bis die automatische Anmeldung durchgeführt wurde.
3. Während dem IDLE-Betrieb auf PC2 auf das Quick Access-Menü in der Task-Leiste klicken
(Das ist das Internet+Audio Icon untenrechts am Desktop)
1777124557930.png

4. Sobald die Schnell-Leiste gerendert ist, verliert PC1 den Ping für ein Paket.
Erst das nächste Paket kommt wieder an.
1777124625084.png


Das war's. Nach diesem einen Schluckauf lässt sich das Problem nicht wieder reproduzieren, außer man startet den PC neu.
Bei einem frischen Start jedoch lässt sich das Problem zu 100% triggern.
Diesen Fall konnte ich jetzt auf allen Win11 PCs beobachten die ich in den Fingern hatte.
Dazu musste ich aber die Auto-Start Dienste deaktivieren, die irgendwas mit dem Netzwerk machen.

Ich würde echt gerne wissen, wie ich verstehen kann, was wirklich passiert und wie man das Problem beheben kann.
Vermutung ist, dass das Netzwerk-Stack beansprucht oder überfordert wird und er für einen Moment alle kommenden und gehenden Anfragen ignoriert.
Ich betreibe eine Software, die bei diesem Bug den Geist aufgibt und neu gestartet werden muss. Das ist mega ärgerlich.

Kann mir da ein Sys-Admin oder IT-Crack behilflich sein?


Danke und liebe Grüße
KoKo
 
Wie ist die IP-Verbindung über das Netzwerk konfiguriert bezüglich Geschwindigkeit? Kann es sein, dass bei "Auto" im Moment des Handshake der Connect kurz unterbricht? Gibt es Besserung, wenn auf beiden Rechner eine feste Geschwindigkeit eingestellt ist?
 
Danke für die Rückmeldung!
sGässje schrieb:
über das Netzwerk konfiguriert bezüglich Geschwindigkeit
1777127529899.png

Ist damit die Konfiguration auf Router-ebene gemeint oder gibt es im Netzwerk-Adapter eine Einstellung, die man ändern sollte?
Habe im Adapter leider nichts in der Richtung gefunden bei mir...

LG
 
AffeMitWaffe_ schrieb:
Ich würde echt gerne wissen, wie ich verstehen kann, was wirklich passiert und wie man das Problem beheben kann.

"Schnell-Leiste rendern" -> hohe CPU Last -> Antwortzeit >1sec -> Timeout

1. ist das nich schlimm das die Protokolle auf solche Timeouts vorbereitet sind
2. nein lässt sich nicht beheben und ist auch kein Problem

AffeMitWaffe_ schrieb:
Bei einem frischen Start jedoch lässt sich das Problem zu 100% triggern.
...
Dazu musste ich aber die Auto-Start Dienste deaktivieren, die irgendwas mit dem Netzwerk machen.

AHA also manipulierst du die Standard OS Einstellungen also, um das Problem triggern zu können. Lass die Auto Starts doch so wie sie sind.
Dann ist doch klar das es dazu kommt, wenn die dann wohl während der Schnellstarleiste geladen werden und dann den Treiber der Netzwerkkarte dann abfragen etc.

AffeMitWaffe_ schrieb:
Ich betreibe eine Software, die bei diesem Bug den Geist aufgibt und neu gestartet werden muss. Das ist mega ärgerlich.

Dann solltest du den Programmierer den Bug um die Ohren hauen. Wenn die wegen solchen Fehlern aufgibt, hat der Programmierer geschlampt bei der Fehlerbehandlung und das gehört das gepatcht oder die SW ersetzt gegen eine die besser arbeitet.
 
  • Gefällt mir
Reaktionen: Merlin352, KEV24in_Janßen und tollertyp
Dann kann man also davon ausgehen, dass das ein M$ bekanntes Szenario ist und kein Bedarf besteht, daran was zu schrauben.
Macht schon Sinn, da wirklich alle Anwendungen damit umgehen können, nur diese eine eben nicht.

Finde es trotzdem merkwürdig, da man in einem Zoom-Bewerbungsgespräch mal schnell die Leiste öffnet um sein Gegenüber lauter zu stellen und für ne Sekunde dann Ton und Video aussetzen.
Kein Weltuntergang, aber auch nicht das gelbe vom Ei.

Hatte echt gehofft den Service dahinter zu erschnüffeln und Microsoft ne semi-arrogante Nachricht zu verschicken, aber ich denke dass es die Mühe nicht Wert ist :D
 
AffeMitWaffe_ schrieb:
Dann kann man also davon ausgehen, dass das ein M$ bekanntes Szenario ist und kein Bedarf besteht, daran was zu schrauben.
Das hat nichts mit Microsoft zu tun, sondern dass du einfach einen Dienst nicht verfügbar hast. Auf meinem Win11-PC konnte ich das von dir beschriebene Verhalten jedenfalls nicht reproduzieren. Jeder ICMP-Request wurde normal beantwortet. Die Ursache für den "Bug" bist vermutlich du selbst ("Dazu musste ich aber die Auto-Start Dienste deaktivieren, die irgendwas mit dem Netzwerk machen."). Das ist doch logisch, dass wenn du die Schnellleiste öffnest, die auch Infos von den Netzwerkdiensten benötigt, es zu Verzögerungen kommt, wenn diese noch nicht richtig gestartet sind bzw neu starten müssen.

Was die Auswirkung auf die Anwendung angeht: jede Übertragungsstrecke kann mal kurz unterbrochen sein, entweder durch äußere Einflüsse oder durch das OS, wenn z.B. der Netzwerkstack neu gestartet wird oder wenn die CPU einfach dicht ist. Jede Anwendung muss damit klar kommen. Wenn der Client über WLAN oder Mobilfunk angebunden ist, hat man solche Unterbrechungen durch äußere Einflüsse sogar noch viel häufiger.
 
Sebbi schrieb:
"Schnell-Leiste rendern" -> hohe CPU Last -> Antwortzeit >1sec -> Timeout
das ist natürlich unsinn, denn zum einen wird das öffnen dieser leiste kaum alle kerne komplett auslasten und zum anderen schafft selbst windows unter 100% last auf allen kernen noch einen ping zu beantworten.

@AffeMitWaffe_ deine screenshots zeigen, dass du wlan verwendest. wenn windows die liste der empfangbaren wlan-netze aktualisiert, dann ist auf einigen adaptern kurzzeitig kein traffic möglich (siehe z.b. hier). hast du das gleiche problem auch, wenn du einen kabelgebundenen adapter verwendest?
 
  • Gefällt mir
Reaktionen: qiller und tollertyp
Er meint nicht den MS-Leuten, sondern den Programmieren der Software, die nicht damit umgehen kann.

@0x8100: Das mit dem WLAN ist mir auch aufgefallen, und vor allem, dass dann später von LAN-Verbindungen zu Rede ist...
 
  • Gefällt mir
Reaktionen: sGässje
Ich hatte wohl irrtümlich ebenfalls eine LAN Verbindung vorausgesetzt. Und ja, man kann über die Eigenschaften des LAN Adapter separat die Verbindungsgeschwindigkeit manuell festlegen aber das kommt ja hier offensichtlich nicht als Ursache in Frage.
 
0x8100 schrieb:
das ist natürlich unsinn, denn zum einen wird das öffnen dieser leiste kaum alle kerne komplett auslasten und zum anderen schafft selbst windows unter 100% last auf allen kernen noch einen ping zu beantworten.

die "Schnellstart Leiste" die der TE meint fragt viele Dienste, unter anderen auch den Netzwerkstack, Treiber etc. Da kannst du auch mit einen 100 Kerner kommen, wenn die Ressourcen gerade belegt sind und nicht rechtzeitig auf den ICMP Request antworten, kommt es nunmal zu einen Timeout. Vorallem wenn wie beim TE noch die ganzen Dienste starten müssen, was dann noch einmal extra Zeit braucht.

Zudem laufen die Systemressourcen auf den E-Kernen, wenn dort aber durch andere Dinge Last auf dem Kern erzeugt wird, verzögert sich die Antwort auf andere Anfragen. Und da Pings keine hohe Priorität geniesen, werden die bei knappen Ressoucen entweder gedropt oder verzögert bearbeitet.
 
AffeMitWaffe_ schrieb:
Finde es trotzdem merkwürdig, da man in einem Zoom-Bewerbungsgespräch mal schnell die Leiste öffnet um sein Gegenüber lauter zu stellen und für ne Sekunde dann Ton und Video aussetzen.
Tjoar, man hätte ja das so wie bei allen anderen Windows Versionen davor lassen können, und Netzwerk und Audio getrennte Systrays geben können. Aber muss ja irgendwie immer wieder alles neu und fancy sein, obwohl überhaupt keine Notwendigkeit besteht.
 
Sebbi schrieb:
kommt es nunmal zu einen Timeout.
der default timeout bei "ping" unter windows ist 4s. und jetzt willst du mir sagen, dass das öffnen dieser leiste windows für mehr als 4 sekunden dermassen auslastet, dass es keinen ping beantwortet bekommt? ist klar...

da halte ich meine these dann doch für plausibler, dass in dem moment der icmp request gar nicht im netzwerkstack ankam, weil der wlan-adapter zu dem zeitpunkt nicht verfügbar war.

könnte der te übrigens mit wireshark auf beiden rechnern ja mal kurz überprüfen.
 
  • Gefällt mir
Reaktionen: sGässje und tollertyp
Atkatla schrieb:
Auf meinem Win11-PC konnte ich das von dir beschriebene Verhalten jedenfalls nicht reproduzieren
Das irritiert mich dann doch...
Ich habe das sowohl auf der Arbeit bemerkt (alles LAN) als auch bei mir zu Hause (WLAN pingt LAN)
Win11 Enterprise und Win11 Pro also schon durch
Atkatla schrieb:
Das ist doch logisch, dass wenn du die Schnellleiste öffnest, die auch Infos von den Netzwerkdiensten benötigt, es zu Verzögerungen kommt, wenn diese noch nicht richtig gestartet sind bzw neu starten müssen.
Hier stellt sich aber die Frage, was denn beim Öffnen der Leiste nun gestartet wird.
Selbst wenn ich 100 Pings abwarte während der LAN PC alle Dienste und was auch immer geladen hat und dann die Schellzugriff-Leiste öffne, fällt ein Paket wieder flach. Ich check nicht ganz wie das "normal und unproblematisch" sein kann.

0x8100 schrieb:
deine screenshots zeigen, dass du wlan verwendest
Das stimmt. Ich habe den Fehler bei der Arbeit bemerkt und es zu Hause reproduziert. Im Geschäft ist alles über LAN und da mein angepingter PC auch im LAN steckt, habe ich den WLAN-Pings vertraut.
Lässt sich aber 1 zu 1 so nachbilden wie im Geschäft.

Sebbi schrieb:
Vorallem wenn wie beim TE noch die ganzen Dienste starten müssen, was dann noch einmal extra Zeit braucht.
Weiß nicht was Du mit "ganzen Dienste" meinst, aber ich kann wie erwähnt 100 Minuten im Idle warten, dann die Leiste öffnen und zack bricht die Verbindung kurz ab. Über IP Telefonie verschwindet mein Ton dann für eine Sekunde.
Sebbi schrieb:
Und da Pings keine hohe Priorität geniesen
Aber die IP Telefonie setzt ja nicht auf Pings sondern eher priorisierte Datenpakete oder nicht?
Da wir hier dasselbe Phänomen beobachten, liegt es nicht an der Priorisierung, sondern an einer Auslastung des Netzwerk-Stacks oder nicht?

0x8100 schrieb:
weil der wlan-adapter zu dem zeitpunkt nicht verfügbar war
Bitte WLAN aus dem Thema fern halten. Ich bin sicher, dass das mit WLAN nichts zu tun hat, da es ebenfalls unter LAN-zu-LAN Szenarien auftritt.

0x8100 schrieb:
könnte der te übrigens mit wireshark auf beiden rechnern ja mal kurz überprüfen.
Lustig dass du das sagst. Ich hatte es tatsächlich probiert mal einzufangen.
Mit Wireshark und netsh über cmd.
Wireshark konnte ich leider nichts sinnvolles auswerten und netsh war auch unauffällig für mein Laien-Auge...


Nur um nochmal auf der selben Frequenz zu sprechen:
Ich deaktiviere zum Reproduzieren keine Services.
Und das mit dem Autostart können wir für mein Use Case zu Hause auch ignorieren.
Bei der Arbeit ist mir derselbe Ping-Drop passiert, als ich per Autostart KeePass hab starten lassen, der auf ein Netzlaufwerk zugegriffen hat.
Das war ne unnütze Info von mir, sorräyy :v
 
Zuletzt bearbeitet:
AffeMitWaffe_ schrieb:
Wireshark konnte ich leider nichts sinnvolles auswerten
was war denn zu sehen? auf dem pc, der den ping startet, sieht man eine reihe von icmp echo requests - jeder mit einer aufsteigender sequence number. auf dem problem-pc ist genau die gleiche anzahl requests zu sehen? oder fehlt dort der request, für den es einen timeout gibt?
 
@0x8100 Ich probier das mal morgen erneut.
Ich schau mir einen Ping an und versuch den Filter so zu setzen, dass ich in dieser riesen komplizierten Liste nur die Pings angezeigt bekomme.

Diese werde ich dann, wenn ich es hinbekomme, mal hier posten (Laptop und PC), vielleicht siehst Du bei Gelegenheit rein und erkennst eine Unauffälligkeit. Danke für den Tipp 😄
 
Zurück
Oben