[English]Bei den zum 13. Dezember 2022 freigegebenen Sicherheitsupdates laufen einige Nutzer in arge Probleme. Die .NET-Framework-Updates bewirken Probleme mit dem Grafikausdrucken (siehe .Net Update vom 13. Dez. 2022 verursacht Druckprobleme bei DATEV-Briefköpfen mit Grafiken). Und zum Update KB5021233 für Windows 10 22H2 liegen mir zahlreiche Berichte über auftretende BlueScreens vor. Microsoft hat gerade bestätigt, dass alle Windows 10 20H2 – 22Hx-Versionen betroffen sind und erklärt die Ursache samt Hinweis, wie man das Problem beheben kann.
Anzeige
Update KB5021233 für Windows 10 20H2 – 22H2
Das kumulative Update KB5021233 steht für die noch im Support befindlichen Windows 10-Varianten von (20H2 nur Enterprise/Education) 21H1 bis 22H2 zur Verfügung und enthält Sicherheitsfixes – wobei Microsoft keine Details angibt. Die Liste der Verbesserungen lassen sich im Blog-Beitrag Windows 10 20H2-22H2 Preview Update KB5020030 (15.11.2022) nachlesen, da das Preview-Update ja zum Patchday des Folgemonats in das reguläre Sicherheitsupdate einfließt. Das Einzige, was Microsoft bei diesem Update erwähnt, ist eine Problembehebung bei der Kamera-App Die App reagiert ohne den Fix nicht mehr, wenn der Speicherplatz knapp wird.
Microsoft weist auch darauf hin, dass dieses Update Qualitätsverbesserungen am Servicing Stack (ist für Microsoft Updates verantwortlich) durchführt. Ich hatte im Blog-Beitrag Patchday: Windows 11/Server 2022-Updates (13. Dezember 2022) über das Updates berichtet. Im Supportartikel KB5021233 ist nur ein Problem in Verbindung mit dem Microsoft Edge-Browser aufgeführt, der sich u.U. nicht auf die aktuelle Version aktualisiert.
Nutzer melden BlueScreens
Kurz nach Veröffentlichung des kumulativen Updates KB5021233 meldete sich Birgit hier im Blog mit dem Kommentar, dass sie unter Windows 10 22H2 von einem BlueScreen betroffen sei:
Probleme nach KB5021233 auf Windows 10 22H2 mit Bluescreen bekannt? HW: HP Omen 870-260nz
Könnte ein Einzelfall gewesen sein, aber Blog-Leser Christian M. bestätigte in diesem Kommentar, dass in seiner Firmenumgebung mehrere Rechner mit Windows 10 22H2 von dem durch das Update KB5021233 ausgelösten BlueScreen betroffen sind.
Hatten heute bereits 3 Systeme bei denen ein Bluescreen kam und Windows nicht mehr starten wollte. Konnte nur durch die Systemwiederherstellung behoben werden.
Bin mal gespannt wie viele Ausfälle da in den nächsten Tagen in unserer Firma noch kommen werden :-(
Ich hatte es mir auf "beobachten" gelegt, und bin dann in der patchmanagement.org-Mailing-Liste auf einen weiteren Beitrag von Susan Bradley gestoßen, die das Problem ebenfalls erwähnt:
Seeing some BSODs reported on REDDIT
Tracking reports of blue screens of death that may be occurring on Windows 10 22H2 on Reddit threads – Cumulative Updates: December 13th, 2022 : Windows10 (reddit.com) It's unclear at this time if this is being triggered by secure boot patch KB5012170 or with the Windows 10 22H2 patch itself.
Remember secure boot patch KB5012170 is our dear friend that has triggered systems asking for bitlocker recovery keys.
Es deutet sich also an, dass das Update KB5021233 ein größeres Problem verursachen könnte. Den Hinweis auf das Secure Boot .dbx-Update KB5012170 kann man ignorieren.
Microsoft bestätigt das Problem
Zum 17. Dezember 2022 hat Microsoft dann in der Known Issues-Sektion seines Windows 10 22H2 Healt Statusbereichs den Beitrag You might receive an error (0xc000021a) with a blue screen eingestellt, der das Problem bestätigt.
Nach der Installation von KB5021233 starten einige Windows-Geräte möglicherweise mit einem Fehler (0xc000021a) und einem blauen Bildschirm.
Microsoft erklärt das Problem mit dem Hinweis, dass es nach der Installation von KB5021233 zu einer Diskrepanz zwischen den Dateiversionen von hidparse.sys in
Anzeige
c:/windows/system32
und
c:/windows/system32/drivers
kommen kann (Laufwerk C bezieht sich auf das Windows Installationslaufwerk). Die verschiedenen Dateiversionen können dazu führen, dass die Signaturüberprüfung bei der Bereinigung fehlschlägt. Betroffen sind folgende Windows 10-Client-Versionen:
- Windows 10 Version 22H2
- Windows 10 Version 21H2
- Windows 10 Version 21H1
- Windows 10 Version 20H2 (nur Enterprise und Education)
Mir liegen aktuell aber nur Berichte zu BlueScreens bei Windows 10 Version 22H2 vor. Das Modul hidparse.sys gehört vom Namen her zu Windows und hat die Aufgabe, die HID-Einträge (Einträge der Human Interface Device, HID, USB-Geräte wie Maus etc.) zu analysieren, um die Geräte zu identifizieren. Der Stop-Code 0xc000021a bedeutet, dass der zugehörige Systemprozess unerwartet beendet wurde (STATUS_SYSTEM_PROCESS_TERMINATED).
Anmerkung: In den nachfolgenden Kommentaren berichten Nutzer, dass die Datei im Verzeichnis system32 bei ihnen fehle. Das kann ich auf meinem (noch für Dez. 2022 ungepatchten) Windows 10 22H2 Testsystem bestätigen. Dort ist die Datei unter system32/drivers und in system32/driverstore zu finden. Warum Microsoft das nicht adressiert, und warum die Datei in nachfolgendem Workaround kopiert werden soll, ist mir aktuell unklar.
Workarounds für das Problem
In den Kommentaren hier im Blog hat Birgit durch Deinstallation des Updates im abgesicherten Modus gelöst, während Christian M. die Systemwiederherstellung zum Rollback verwendet hat. Das ist aber aus Sicherheitsgründen keine wirkliche Option.
Microsoft hat als Workaround aber einen Fix veröffentlicht, bei dem man in der Eingabeaufforderung der Windows PE-Umgebung die Treiberversion manuell kopiert, um den gleichen Revisionsstand herzustellen.
1. Zuerst ist die Windows-Wiederherstellungsumgebung aufrufen. Falls dies nicht automatisch passiert (sollte nach 3 maligem erfolglosen Booten mit Ausschalten passieren), kann man die Hinweise hier versuchen.
2. Wählen Sie in der Wiederherstellungsumgebung (blaue Kacheloberfläche) die Schaltfläche Problembehandlung, dann Wiederherstellung, Problembehandlung und Diagnosetools starten. Anschließend gehen Sie auf die Schaltfläche Erweiterte Optionen und dann auf die Option Eingabeaufforderung.
3. Warten Sie ggf. den Neustart ab und melden Sie sich am Gerät an, um in der Eingabeaufforderung den nachfolgenden Befehl auszuführen.
Der folgende Befehl kopiert die aktualisierte Treiberdatei in den Windows-Ordner system32, so dass die Versionen übereinstimmen.
xcopy C:\windows\system32\drivers\hidparse.sys C:\windows\system32\hidparse.sysAnschließen können Sie exit als Befehl eingeben und Windows 10 neu starten lassen. Danach sollten das System wieder funktionieren. Administratoren, die eine größere Anzahl an Clients reparieren müssen, benötigen aber einen anderen Ansatz, der diese Kopieroperation während des Systemstarts vornimmt. Microsoft will das Problem erst mit einem der nächsten Updates beheben. Preview Updates wird es aber im Dezember 2022, wegen der Weihnachtsfeiertage nicht geben.
Ähnliche Artikel:
Windows 10 20H2-22H2 Preview Update KB5020030 (15.11.2022)
Microsoft Security Update Summary (13. Dezember 2022)
Patchday: Windows 10-Updates (13. Dezember 2022)
Patchday: Windows 11/Server 2022-Updates (13. Dezember 2022)
Windows 7/Server 2008 R2; Windows 8.1/Server 2012 R2: Updates (13. Dezember 2022)
Windows 11 22H2: Secure Boot DBX Update KB5012170 (Dez. 2022)
Bestätigt: Secure Boot DBX Update KB5012170 sorgt für Installationsärger (Error 0x800F0922)
Net Update vom 13. Dez. 2022 verursacht Druckprobleme bei DATEV-Briefköpfen mit Grafiken
Windows Server 2019/2022: Dezember 2022-Sicherheitsupdates verursachen Hyper-V-Probleme
Windows 11 22H2: Spiele-Performance Upgrade-Blocker jetzt aufgehoben
Windows 11 22H2: Fix für Leistungsproblem beim Kopieren von Dateien noch nicht verfügbar
2015
Danke für die Info <3
Gleich im WSUS auf remove gestellt…
Gibt es da ein Zeitfenster in dem der BSOD auftreten kann oder passiert das sehr rasch? Bei uns wurden die Updates im Laufe des Mittwochs installiert. Bisher zeigt kein Client irgendwelche Probleme. Ich hoffe mal, das hält noch bis Ende der Woche an. Dann ist eh Urlaub :D
Hab gerade vor einer Woche meinen privaten Rechner mit Win10 Pro 22H2 komplett sauber neu installiert und alle Updates inkl. dem vom Dezember aufspielen lassen. Habe kein Bluescreen-Problem aber mal interessehalber wegen der hidparse.sys geschaut. Hier gibt es die nur im Drivers-Ordner, direkt in System32 existiert die bei mir gar nicht. Auf meinem Büro-Desktop-PC (Win10 vor ca. 2 Jahren sauber selbst installiert) genau das gleiche, auch nur 1x vorhanden. Jedoch am Firmenlaptop Lenovo P53 wo Win10 vorinstalliert war gibt es die Datei in beiden Ordnern, da allerdings identischer Stand.
Also ggf. nur vorinstallierte Rechner überhaupt betroffen? Anscheinend ist die Datei im System32-Ordner ja gar nicht erforderlich (trotzdem lösche ich die am Lenovo jetzt nicht einfach so).
Ich habe auch gerade geschaut und kann das Nicht-Vorhandensein im System32-Verzeichnis bestätigen.
Microsoft schreibt dazu selbst: "We do not recommend deleting the hidparse.sys from your Windows\System32 folder.".
Zwei dumme, ein Gedanke …
Aber das mit dem vorinstalliert ist ein guter Hinweis. Hier ist auch so, dass auf einem vorinstallierten System die SYS-Datei in beiden Verzeichnissen existiert, ebenfalls ein Lenovo-Notebook. Das andere System wurde über den MS-Installer selbst installiert, dort existiert sie nur im Drivers-Verzeichnis. Meiner Meinung nach gehört sie auch nur dort hin.
Stellt sich jetzt die Frage, was auf den vom BSOD betroffenen Systemen anders ist.
Auf unseren Dell Rechnern liegt die Datei auch nur im Drivers Verzeichnis. Die sind auch alle vorinstalliert. Also herstellerabhängig?
Könnte sein, könnte aber auch am Geräte-Typ liegen.
Ich habe hier mehrere Lenovo-Systeme mal kurz überprüft, alles Notebooks, keine Desktops/WS. Bei allen überprüften mit vorinstalliertem System liegt genannter Treiber in beiden Verzeichnissen, dann aber immer in identischer Version. Wir haben auch Lenovos mit selbst installiertem Windows 10. Dort liegt der Treiber nur unter drivers und nicht in system32. Die mit vorinstalliertem System sind aber fast alle auf aktuellem Stand, d.h. dass die Installation des Updates in beiden Verzeichnissen die SYS-Dateien auf die mitgelieferte Version angehoben hat.
Eine durch den Hersteller angepasste SYS könnte ich mir eigentlich nur für Notebooks vorstellen, wegen Touchpad und TrackPoint. Allerdings wären die hier dann irgendwann verloren gegangen und durch Microsoft-Versionen ersetzt worden. Mir sind jedoch keine Probleme mit Touchpads und TrackPoints bekannt.
Weiß der Geier. Hauptsache hier bleiben alle von diesem BSOD verschont.
Ist bei mir auch so. Finde hidparse.sys nur in c:/windows/system32/drivers, aber nicht in c:/windows/system32.
Windows, das nicht zu verstehende System.
Hier sind allem Anschein nach gar keine Systeme von diesem Problem betroffen. Ein Vergleich zweier Systeme (22H2) zeigt kleinere Unterschiede.
Auf System A existiert die oben genannte hidparse.sys nur im Verzeichnis
C:\Windows\System32\Drivers. Im übergeordneten Verzeichnis System32 existiert sie überhaupt nicht. Ernste Frage: wieso sollte dort überhaupt eine SYS-Datei (Treiber) liegen? Dafür gibt es doch wohl das Drivers-Verzeichnis!?
Auf System B existiert diese SYS-Datei dann doch in beiden Verzeichnissen, es handelt sich aber um die identische Version. Von daher kommt es nicht zu dem genannten Problem.
Was ist denn jetzt die Ursache? Macht die Update-Installation den Fehler nicht beide SYS-Dateien auf identischem Stand zu halten, falls erforderlich. Oder ist es bereits ein Fehler/Problem, wenn in System32 eine/diese SYS-Datei liegt?
Im oben genannten System System A befinden sich allerdings dann doch exakt vier SYS-Dateien im System32 Ordner, alles "win32k*.sys" vom Namen her.
Da herrscht bei mir wohl die groesstmoegliche Diskrepanz – die Datei gibt's in C:\Windows\system32 ueberhaupt nicht; ich wuerde' mal annehmen, dass das auch so sein soll, und nur auf manchen Systemen eine (alte) Kopie in system32 gelandet ist, die dann natuerlich nicht gepatcht wird…
Es ist einfach grandios zu sehen, wie Microsoft das Spiel "Wie lange können wir mit Jahre und Jahrzehnte alten Codeschnippseln weitermurkseln, ohne das alles zusammenbricht?" immer weiterspielt. Das ist so ähnlich wie bei Banken-Mainframes, auf denen noch Cobol-Programme laufen und die allermeisten Programmierer sind seit Jahren tot oder in Rente. Ein Systemwechsel wurde aus Kostengründen immer wieder rausgeschoben aber irgendwann (wenn man selbst hoffentlich nicht mehr in der Verantwortung ist) muss alles sauteuer neu gemacht werden.
Habe hier auf meiner HP Z2G4 mit vorinstalliertem Windows (21H2, Dez.-Patch) zwei unterschiedliche Versionen gefunden. Aber keine in system32.
C:\Windows\servicing\LCU\Package_for_RollupFix~31bf3856ad364e35~amd64~~19041.2364.1.4\amd64_dual_input.inf_31bf3856ad364e35_10.0.19041.2251_none_9d8e6d8b9f1f91ec\n\hidparse.sys (20.739 Bytes, 04.11.2022)
C:\Windows\System32\drivers\hidparse.sys (46.080 Bytes, 09.11.2022)
C:\Windows\System32\DriverStore\FileRepository\input.inf_amd64_292ece99a27cec96\hidparse.sys (46.080 Bytes, 09.11.2022)
C:\Windows\WinSxS\amd64_dual_input.inf_31bf3856ad364e35_10.0.19041.2251_none_9d8e6d8b9f1f91ec\hidparse.sys (46.080 Bytes, 09.11.2022)
C:\Windows\WinSxS\amd64_dual_input.inf_31bf3856ad364e35_10.0.19041.2251_none_9d8e6d8b9f1f91ec\n\hidparse.sys (20.739 Bytes, 04.11.2022)
Kleiner Hinweis zum Artikel: HID steht hier nicht für "Hardware ID", sondern für "Human Interface Device", das sind Tastatur, Maus usw.
Hatte gestern gerade einen Kunden mit PC Win10 21H2 der genau diesen BlueScreen hatte. Die Info hätte mir den Restore zum letzten SnapShot erspart :-)
Aber am WE vermeide ich, allzu viel im Blog zu posten – liest ja eh kein Admin – und Freitag war es mir noch zu früh für einen Beitrag ;-)
Eigentlich darf ich gar nichts sagen – wir bekommen hier super Infos (besser und um einiges schneller als vom Branchenriesen heise) und das zum Nulltarif. Aber dass Admins am Wochenende nicht arbeiten würde ich so nicht unterschreiben – die IT ist schon lange ein 24/7-Unternehmen. Ein kurzer Blick in die gängigen Foren ist immer drin – und natürlich auch in Ihren Blog. Für uns mittlerweile die Nummer 1!
War ja auch kein Vorwurf. War ein wenig "an die eigene Nase fassen". Hier liegt oft ein Schmierzettel auf dem Schreibtisch, und seit dem 14. oder 15. Dez. stand da "nach BSOD zum W10 Update recherchieren, ob es außerhalb des Blogs weitere Funde gibt". Bin nicht dazu gekommen … bis MS das dann thematisiert hat.
Habe oft einen riesigen Stack an Themen "musst Du vieleicht Samstag drüber bloggen" … und dann fällt es unter den Tisch. Ich ärgere mich dann über mich selbst, wenn was liegen bleibt.
Das ist wohl ein schlechter Witz. Es ist bekannt, dass das Update Rechner unbenutzbar machen kann; man weiß auch anscheinend, woran das liegt — aber will es erst "mit einem der nächsten Updates" beheben???
Jedenfalls vielen Dank für die Information. Updates pausiert bis zum 20.01.2023.
Das grandiose ist ja, das mit dem nächsten Update, das nächste nicht geht.
Egal ob Client oder Server Bereich.
Irgendwas ist immer Faul.
Die Zeit die derzeit in die Patchdays gesteckt werden müssen nehmen von Jahr zu Jahr gefühlt exponentiell zu.
Hatte am Sonnabend Blue-Screen an Dell-Notebook (älteres Modell) mit Win 10 21H2. Nach dem automatischen Diagnoselauf mit Reparaturversuch des Systems änderte sich nichts und der BSOD war persistent. Gestartet werden konnte aber mit deaktivierter Erzwingung der Signatur.
Das Problem konnte nach verschiedenen erfolglosen Versuchen (Systemwiderherstellung, Deinstallation des Patches…) letztlich mit Inplace-Update ohne Datenverlust behoben werden (auch der aktuelles Patch bzw. das aktuelle Build war erfolgreich installiert). Die MS-Empfehlung war da noch nicht bekannt und der Hinweis keine anderen Workarounds zu versuchen schon etwas zynisch.
Gestern (Sonntag) an weiterem Rechner (Notebook auch auf 21H2) auch BOSD beim ersten Neustartversuch, doch die automatische Diagnose und Reparatur führte zum erfolgreichen Abschluss der Patch-Installation im zweiten Neustartversuch.
An einigen Rechnern lief das Update auch ohne erkennbare Zwischenfälle durch…
Dass es hier um von OEMs vermurkste Vorinstallationen geht, erscheint mir plausibel. Ich habe das Update mittlerweile auf ca. 100 Rechnern installiert (vorwiegend W10 22H2, einzelne W11 21H2, W11 22H2 und Server 2022), kein einziges Problem dabei. Aber auch keine einzige OEM-Vorinstallation, die ersetze ich aus Prinzip immer durch eine eigene Installation.
Dies kann ich nicht bestätigen. Der BSOD ist bei mir auch auf einem Rechner ohne OEM-Installation aufgetreten (saubere Windows-Installation – auch kein externes Antivirenprogramm), der alle Updates bisher bereitwillig geschluckt hat.
Die Funktionsupdates auf diesem wurden seit der Verfügbarkeit mittels Enablement-Packages installiert. Ggf. gibt es ja da Zusammenhänge, weil die Installation nicht so "sauber" wie bei der langwierigen Alternative ist (kann man sofort in den GPOs sehen…).
Offensichtlich ist Windows mit all seinen Funktionen und Funktiönchen im Zusammenspiel mit der breitgefächerten HW-Basis derart komplex, dass klare Ursachenfindung hoch (zu?) anspruchsvoll ist. Es dauerte Tage, bis dieser extreme Fehler erkannt wurde und die Abhilfe scheint derart Banal, dass man sich doch wundert, dass dies nicht schon automatisch gefixt wurde…
Ansonsten muss man schon konstatieren, dass die Stabilität der Updates in den letzten Jahren deutlich verbessert wurde (meine hier nicht die zahlreichen Fehler – wie z.B. das Druckerthema…)
Danke für die BSOD Information zu KB5021233.
Seit dem KB5021233 Update letzte Woche habe ich auf einem Rechner (Win10 Pro 22H2) bei jedem Neustart einen
BSOD mit BAD_SYSTEM_CONFIG_INFO
KB5021233 deinstalliert und der Rechner startet und läuft wieder einandfrei.
In der Zwischenzeit wurde KB5021233 von Windows Update erneut installiert.
Bisher keine Probleme.
Vielen Dank für den tollen Blog und den guten Beiträgen.
Bei uns im Unternehmen haben wir mit KB5021233 das Problem, das kein Word/PDF Druck nicht mehr funktioniert.
Windows 10 22H2
wir haben den Patch deinstalliert.
Schau den Beitrag .Net Update vom 13. Dez. 2022 verursacht Druckprobleme bei DATEV-Briefköpfen mit Grafiken an. Vielleicht hilft der Registry-Eintrag.
Kann es sein das bei der BlueScreen Problematik fast nur die HP Geräte betroffen sind ?
Von anderen habe ich noch nichts gelesen.
Derzeit habe ich das KB5021233 bei ca. 1.000 / 54.000 Fujitsu Geräten ausgerollt und noch keinerlei Probleme.
Könntet Ihr evtl. die eingesetzten Hersteller mit nennen ?
Ebenfalls auf ca. 1000 Geräten installiert. Bisher keine Bluescreens. Geräte sind von Dell/Lenovo/Fujitsu, Windows 10 21H2.
@Frank K.
Nein, wir haben bei Lenovo (M720) das gleiche Problem mit den Bluescreens
So da ich das gerade lese: 2022-12 Kumulatives Update für Windows 10 Version 22H2 für x64-basierte Systeme (KB5021233), ich kann dieses Update vielleicht auch zum Glück nicht installieren, egal was ich ausprobiert habe, ich denke es ist auch besser so…oder? Thinkpad T480
Zur Info falls das noch jemand haben sollte.
Das Update KB5021233 hat bei mir(Win10 64bit 21H2 19044.2364) dafür gesorgt dass Programme die Verbindungen aufbauen(beispielsweise putty oder vncviewer) ca. 20 Sekunden verzögert starteten bzw. beim Herstellen der Socketverbindung einfroren.
Deinstallation des Updates und Neustart hat geholfen:
wusa /uninstall /KB:KB5021233 /quiet /promptrestart
Habe gerade einen "noname" PC hier, der genau diese Problem hat.
Hat die HIDPARSE.SYS sowohl in System32, Drivers, Repository
Alle Dateien haben die gleiche Version 10.0.19041.2251, Datum 09.11.22 und Dateigröße 46080 byte.
Weder Überschreiben, noch Löschen, Noch sfc /scannow funktionieren.
Fehler bleibt gleich. Windows startet nicht durch. Updates lassen sich nicht deinstallieren. Wiederherstellungspunkt ebenfalls nicht.
SSD auf Fehler geprüft, alles ok.
Noch jemand eine Idee?
Guten Morgen zusammen,
falls es jemandem hilft, bei meinen Kunden tritt der Fehler bisher vermehrt auf "älteren" Win10 Systemen auf, die entweder falsch installiert oder durch ein damaliges Upgrade von Win7 auf einem MBR Laufwerk laufen.
Der Trick war hier, das eigene Tool mbr2gpt zu nutzen und im Anschluss BIOS dementsprechend umzustellen auf UEFI.
Vielleicht hilft es noch weiteren, falls ich den Fehler richtig eingrenzen konnte.
Danke für diese Ergänzung.
Bei uns traf es bisher nur wenige Rechner mit BlueScreen oder BSOD.
Eine "zweite" hidparse.sys liegt aber bei vielen, vor allem erst im November über image neu installierten Windows10 Rechnern auch im C:\windows\system32
Wieso haben dann nicht alle den BSOD?
Wieso nicht an jedem Tag BSOD?
Hilft der xcopy Befehl wirklich, da liegen doch noch andere .sys Dateien?
Was haben die .sys Dateien eigentlich dort zu suchen, die gehören doch in den "drivers" Unterordner, schreibt schon weiter oben ein Kommentator?
Wer legt die denn dort ab und wo ist die Quelle?
Steht alles in der Registry!
Kleine Suche nach hidpars.sys und Ihr werdet fündig.
Achtung die .inf Dateien sind von PC zu PC unterschiedlich und werden beim Patchen neu nummeriert!
HID ist wie oben geschrieben für Eingabegeräte.
Da gibt es seit Jahren einen Hersteller Namens LOGITECH.
(Von dem hatte ich auch meine erste Maus – schon mit 3 Tasten – DOS , i386…)
Meine Suche nach hidparse.sys ergab im Zusammenhang mit dem C:\windows\system32 Ordner immer .inf Dateien die folgendes enthalten:
"Copyright (c) 2012 Logitech" und "for Windows XP/VISTA/Win7" und "DriverVer 09/09/2016" und "DefaultDestDir = 11".
(.inf Dateien findet man übrigens im C:\Windows\INF Verzeichnis)
Also ein nagelneuer Treiber von 2016 für die aktuellsten Betriebssystemversionen, der als Zielverzeichnis in den system32-Ordner kommt.
(Suche nach "DefaultDestDir" im Internet und dann Fundstelle: https://learn.microsoft.com/en-us/windows-hardware/drivers/install/inf-destinationdirs-section )
Die Nummer 12 wäre da wohl richtiger gewesen!
Die Registry Einträge verweisen bei uns im Key "Source" auf ein FileRepository "input.inf_amd64_adeb6424513f60a2" das auf den Rechnern nicht mehr existiert.
Ob schnell mal im Install-Image nachgeblättert wird, wenn Windows eine automatische Reparatur nach BSOD ausführen darf und danach .sys Dateien vom 26.11.2022 im system32 Ordner auftauchen kann ich aktuell noch nicht verifizieren.
Vermutung: Da bei uns im Büro aktuell nur wenige Logitech Mäuse und Tastaturen im Umlauf sind, gab es bisher nur wenig BSODs. Wie ist das bei Euch?
Einige schalten ihre Funkmäuse zum Stromsparen aus – sehr lobenswert, dann gibt es beim Booten keinen BSOD. ;-)
Dass so viele neu installierte PCs mit dem .sys Treibern von Logitech "infiziert" sind, lässt sich dadurch erklären, das einer der Administratoren eine dieser Mäuse beim PC aufsetzten verwendet. Danach beim Benutzer dann andere Mäuse und scheinbar auch keine BSODs.
Mit der INF Datei, die die Treiber in den system32 Ordner zwingt und dem nicht vorhandenen FileRepository haben Microsoft und Logitech noch etwas Nacharbeit – im Januar-Patch hat sich da ja nichts getan.
Guten Abend!