./tell

Oder: Wie Linux Dir mal wieder hilft ein Windows Problem zu analysieren…

Der private Windows-PC unseres Marketing-Assistenten hat in letzter Zeit immer wieder Probleme mit Laggs und Performance Problemen gehabt. Nachdem diese immer häufiger geworden sind, begann er, mit den üblichen Methoden das Problem anzugehen. Nachdem die Aktualisierung und das zurückrollen nahezu sämtlicher Treiber, das neu Installieren betroffener Anwendungen und eine Systemreparatur über die entsprechenden Windows-Funktionen nicht geholfen haben, versuchte er es noch mit einem BIOS-Update und dem neu aufsetzten des Betriebssystems.

Nachdem der PC komplett clean neu aufgesetzte wurde, änderte sich wenigstens die Symptomatik des Problems. Zu den mehr als sekündlichen Rucklern in einigen Anwendungen kam nun, dass mit jedem Standbild der Notifikation-Sound fürs Trennen eines USB-Geräts abgespielt wurde. Nach all der Arbeit war das Problem also zunächst schlimmer geworden. Doch die nun dazu gekommene Sound-Ausgabe führte zu einem neuen Ansatz.

Dadurch, dass beim Auslesen sämtlicher systeminterner Ereignisse in enormen Mengen der gleiche Fehler ausgeworfen wurde, war recht klar, dass entweder das Mainboard einen Hardwareschaden hat, oder ein Treiber für einen USB-Anschluss über ein Kompatibilitäts-Problem verfügt. Nachdem wir einen USB Treiber für eine ältere Windows-Version im Kompatibilitätsmodus installiert haben und immer noch sekündlich der Sound abgespielt wurde, erschien allen Beteiligten ein Hardwaredefekt für die realistischste Ursache des Problems.

Mit dieser Vermutung verblieben wir, bis die Idee aufkam einmal zu testen, ob unter Linux die gleiche Symptomatik entsteht. Also booteten wir den PC mit einem Ubuntu-Stick. Nachdem zunächst keine Ereignisse auszulesen werden konnten, wurde der PC mit verschiedenen Benchmark-Tests für einige Zeit unter Last gesetzt.

Auch nach längerer Zeit unter Volllast entstanden unter Linux keine Schwierigkeiten. Weshalb ein Hardwarefehler jetzt doch als eher unwahrscheinlich einzustufen war. Also hieß es: wieder Windows booten und nochmal akribischer nach dem Problem suchen.

Diese genauere Suche bestand hauptsächlich darin, im PowerShell nach einer mit dem Fehler übereinstimmenden ComponentID zu finden. Leider war hier kein Erfolg zu verbuchen. Im Registrierung-Editor gab es dann schließlich eine Übereinstimmung, die uns wiederum zu einer Hardware-ID führte. Im Device-Manager war kurz darauf ein HID Device („Human Interaction Device“) gefunden, welches die entsprechende ID besaß. Mit der Deaktivierung dieses Geräts verschwanden auch die USB-Sounds und Laggs. Wir wissen allerdings bis heute nicht, was genau deaktiviert wurde. Aber da bis jetzt keine gewünschte Funktion im System Schwierigkeiten gemacht hat, nehmen wir das fürs Erste so hin.

So hat Linux einmal mehr geholfen, das Problem (welch eine große Überraschung für alle Developer, dass es Windows war) zu identifizieren und so eine Menge Zeit gespart, die sonst bei Trial-and-Error-Versuchen drauf gegangen wäre gespart.

(Und er versprach uns, doch tatsächlich einmal über eine Linux Installation nachzudenken)