Schreibt ein PC Logbook! – aviation.pero-online.de

Ich hatte in den vergangenen Monaten massive Probleme mit meinen USB Geräten. Immer wieder sporadische disconnects die ein Fliegen unmöglich machten. Und was macht man als schlauer Simulatorbesitzer in dem Fall? Richtig, hier und da naheliegende Dinge rum konfigurieren, neue Treiber installieren und die USB Geräte hin und her tauschen…

Und schon ist es passiert:

Was hat man eigentlich wann geändert?
Welche Treiberversion hatte ich installiert?
Wann trat das Problem zum ersten Mal auf?
usw.

Ihr merkt worauf ich hinaus will. Und, mal ehrlich: das man Änderungen notieren sollte ist auch keine neue Erkenntnis! Allerdings hatte sich bei mir etwas laissez-faire eingeschlichen, da seit Jahren alles ohne Probleme funktionierte. Wer braucht da schon ein Logbuch oder ein top aktuelles Backup? Zu meinem großen Ärger, auf den ich weiter unten noch eingehe.

Jetzt gibt es wieder eine Logbook.txt auf meinem Desktop (Verknüpfung zu einer Datei auf D:\), in der ich wirklich wieder alles eintragen werde. Auch die kleinsten Auffälligkeiten. Ist ja nicht so, dass man das in der Fliegerei nicht auch machen würde… 🙂

############################################################# 27.11.2022 10.00 Uhr

- .NET 6.0.11 installiert

- Kein USB Disconnect aber PTT funktioniert wieder nicht
	- beide Rudder und beide Joy funktionieren
	- PTT konnte wieder über USB Tree "Restart Port" wiederbelebt werden

Dabei sind mir folgende Dinge wichtig:

Lieber ein Wort mehr schreiben, als eines zu wenig. „Fehler wieder aufgetreten“ ist recht generisch
Wirklich alle Dinge aufschreiben, die unnormal sind
Schreibt alle Updates und Systemveränderungen auf
Kopiert ggf. Ereignisse aus dem Eventlog mit in Euer Logbuch.

Gerne gehe ich auch nochmal auf mein Problem ein:

Begonnen hatte es mit einem USB Disconnect, der bei meinem ersten Online Stream auf YouTube live aufgetreten ist. Das war natürlich der Hammer, da ich vorher nie USB Probleme hatte und diese das erste Mal in einem Livestream aufgetreten sind. Der Disconnect äußerte sich so, dass alle USB Geräte vom Root Hub abgeworfen wurden und sich wieder verbinden wollten.

Anschließend war dieser Fehler im Windows Eventlog sichbar:

Problemereignisame:	LiveKernelEvent
Code:	        144
Parameter 1:	1001
Parameter 2:	ffffa08d38f17730
Parameter 3:	0
Parameter 4:	0
Betriebssystemversion:	10_0_22621
Service Pack:	0_0
Produkt:	256_1
Betriebsystemversion:	10.0.22621.2.0.0.256.48
Gebietsschema-ID:	1031

Wenn man dem Debugger glauben schenken will, dann ist das Problem auf ein USB Gerät zurück zu führen. Also habe ich nach und nach alle USB Geräte gezogen, was bei einem sporadischen Problem ein großer Spaß ist. Mal dachte ich, dass betroffene Gerät gefunden zu haben, dann kam nach 1,5 Tagen doch wieder der Disconnect. Am Ende konnte ich alle USB Geräte als Ursache ausschließen. Wenn ich alle USB Soundkarten (verschiedener Hersteller) abgezogen hatte, trat das Problem auch nicht auf, was im nachhinein zur Ursache passt.

Natürlich waren mittlerweile alle Treiber überprüft, neu installiert usw. Spannend auch, dass ich das Problem eigentlich nur im PREPAR3D v5 reproduzieren konnte, wobei ich P3D nicht wirklich als Ursache gesehen hatte. Prime95, Memtest, und Furmark3D brachten den PC nicht aus der Fassung. Interessant…

Supporttickets bei Gigabyte und Microsoft hatte ich natürlich auch eröffnet und parallel mein Problem auch bei Reddit gepostet. So richtig helfen konnte keiner. Die Hersteller haben aus meiner Sicht nur im Nebel gestochert und keiner konnte klar sagen, was dieses wunderbare Windows Event auslöst. Die Antwort war oft „[…] könnte A sein, kann aber auch B oder C sein“. Man freut sich auch, wenn man hört „[…] ach KernelLiveEvents, die sind blöd in der Fehleranalyse […]“ Große Freude… So schlug Gigabyte natürlich vor, ich solle mal das Netzteil tauschen. Generell hatte ich den Eindruck, dass die Mitarbeiter*innen einfach Ihr Schema abarbeiten und das bei so einem Problem nicht hilfreich ist.

Zur weiteren Eindämmung des Problems, wurde die Grafikkarte, das Netzteil und das Mainboard nach einander getauscht. Was leider das Problem nicht behoben hat – weiterhin disconnects…

Bei der Neuinstallation des PC nach dem Mainboard Tausch ist das Problem dann wieder (mit Windows Event 144/100a) aufgetreten. Installiert waren nur P3Dv5.3, GSXv2, RAAS Professional und JeeHell FMGS. Genau gesagt ist es aufgetreten, als ich die Mikrofoneinstellung im JeeHell Intercom machte und der Simulator lief. Dann fiel mir ein, dass ich im Oktober die Soundkarte für das Captain Stabmikro mit RAAS Professional geteilt hatte, was bisher immer über den Main Speaker lief (also das Mic für JeeHell Intercom und den Speaker für RAAS Professional).

Seit einen Wochen läuft der Simulator ohne RAAS Professional und habe keine Probleme mehr. Wobei ich RAAS bald wieder mit einer dedizierten Soundkarte in Betrieb nehmen werde.

Um es klar zu sagen: ich glaube nicht, an einen Bug in einer der aufgelisteten Softwaren sondern tippe auf ein Treiberproblem, dass in dieser wunderbaren Konstellation auftritt und einen KernelLiveError erzeugt.

Meine Learnings:

Regelmäßige Vollbackups ersparen einen Menge Ärger
Meinen nächsten Computer kaufe ich wieder lokal, aber bei einem großen Händler, der „mal eben“ ein anderes, passendes Netzteil, Mainboard oder CPU „rumliegen“ hat und es zum testen verwenden kann
Ich schreibe wieder ein genaues Logbuch, um nicht Monate lang im Nebel zu stochern…

Diese Programme habe ich bei meinem Problem schätzen gelernt:

Danke an ARLT in Heilbronn für die hilfreiche und unkomplizierte Unterstützung!