WMI-Repository prüfen und reparieren mit winmgmt – Windows 10/11

winmgmt /verifyrepository

winmgmt /salvagerepository

winmgmt /verifyrepository

Wenn Programme oder Windows-Verwaltungsfunktionen keine Systeminformationen mehr richtig auslesen können, WMI-Abfragen fehlschlagen oder Fehler zu Windows Management Instrumentation (WMI) auftreten, kann das WMI-Repository beschädigt oder inkonsistent sein.

Windows bringt mit winmgmt ein eigenes Werkzeug mit, mit dem sich das WMI-Repository überprüfen und bei Bedarf reparieren lässt.

Wichtig ist dabei die richtige Einordnung:

winmgmt repariert keine Windows-Treiber und auch nicht allgemein die Treiberverwaltung. Die hier beschriebenen Befehle gehören zu Windows Management Instrumentation und betreffen WMI, das WMI-Repository oder – bei resyncperf – die Windows-Leistungsindikatoren.

Was ist Windows Management Instrumentation (WMI)?

Die Windows Management Instrumentation, kurz WMI, ist eine Verwaltungsinfrastruktur von Windows.

Über WMI können Windows, Programme, Skripte und Verwaltungswerkzeuge Informationen über das System abrufen und bestimmte Verwaltungsaufgaben durchführen. Dazu gehören beispielsweise Angaben über das Betriebssystem, Dienste, Prozesse, Hardware oder andere Windows-Komponenten.

Der Windows-Dienst, der WMI auf dem lokalen Computer bereitstellt, heißt Windows-Verwaltungsinstrumentation. Das zugehörige Werkzeug beziehungsweise der Dienst wird über winmgmt angesprochen.

Microsoft bezeichnet WMI als Kernkomponente von Windows.

Was ist das WMI-Repository?

Damit Windows und Programme WMI verwenden können, muss festgelegt sein, welche Informationen über WMI verfügbar sind und wie diese Informationen aufgebaut sind. Genau dafür gibt es unter anderem das WMI-Repository.

Vereinfacht gesagt ist das WMI-Repository eine von Windows verwaltete Datenbank für WMI. Darin befinden sich beispielsweise Definitionen von WMI-Klassen, Namespaces und Registrierungsinformationen für WMI-Anbieter.

Eine WMI-Klasse beschreibt dabei, welche Art von Information abgefragt werden kann. Das können beispielsweise Informationen über Prozesse, Dienste, Laufwerke oder das Betriebssystem sein.

Ein WMI-Anbieter (Provider) ist eine Windows-Komponente oder eine Komponente eines Programms, die solche Informationen für WMI bereitstellt.

Wichtig ist dabei: Das WMI-Repository enthält nicht einfach eine vollständige Kopie aller aktuellen Systeminformationen. Viele aktuelle Werte werden erst bei einer Abfrage von den jeweiligen WMI-Anbietern ermittelt. Im Repository befinden sich vor allem die dafür benötigten Definitionen und statischen Informationen. Microsoft beschreibt das Repository als einen Speicherbereich für WMI-bezogene statische Daten.

Man kann sich das vereinfacht wie ein Verzeichnis für die WMI-Verwaltungsinformationen vorstellen:

• Das Repository beschreibt, welche WMI-Klassen vorhanden sind.
• Es organisiert diese Klassen in sogenannten Namespaces.
• Es enthält Informationen, die WMI und seine Anbieter für die Bereitstellung von Verwaltungsdaten benötigen.
• Die eigentlichen aktuellen Daten können anschließend von den zuständigen WMI-Anbietern geliefert werden.

Zu den von Windows standardmäßig verwendeten WMI-Namespaces gehört beispielsweise:

root\cimv2

Dort befinden sich zahlreiche häufig verwendete Windows-Klassen.

Ist das WMI-Repository beschädigt oder inkonsistent, können diese Strukturen nicht mehr richtig zur Verfügung stehen. Eine Anwendung findet dann beispielsweise eine erwartete WMI-Klasse nicht mehr oder eine WMI-Abfrage schlägt fehl.

Das kann dazu führen, dass Verwaltungsprogramme, Skripte oder Windows-Komponenten bestimmte Systeminformationen nicht mehr korrekt abrufen können.

Ein beschädigtes WMI-Repository bedeutet jedoch nicht automatisch, dass Windows-Treiber oder die Hardware selbst beschädigt sind. WMI stellt lediglich eine Verwaltungs- und Informationsschnittstelle bereit.

Deshalb sollte bei einem vermuteten WMI-Problem zunächst geprüft werden, ob das Repository tatsächlich inkonsistent ist:

winmgmt /verifyrepository

Erst wenn Windows dabei eine Inkonsistenz feststellt, sollte eine Reparatur des Repositorys in Betracht gezogen werden.

Weitere technische Informationen zur WMI-Architektur findest du direkt bei Microsoft:

Microsoft Learn – WMI-Architektur

Woran kann man ein WMI-Problem erkennen?

Ein WMI-Problem kann sich sehr unterschiedlich bemerkbar machen.

Beispielsweise können Programme keine Systeminformationen mehr abrufen, WMI-Abfragen schlagen fehl oder Windows beziehungsweise eine Verwaltungssoftware meldet Fehler wie einen ungültigen Namespace, eine ungültige Klasse oder einen nicht verfügbaren WMI-Anbieter.

Auch Meldungen wie „WMI: Nicht gefunden“, „Generischer Fehler“ oder Fehler beim Zugriff auf bestimmte WMI-Klassen können auf ein Problem im WMI-Umfeld hinweisen.

Solche Fehler können in manchen Fällen durch ein beschädigtes WMI-Repository verursacht werden. Genau deshalb sollte zunächst dessen Konsistenz geprüft werden.

WMI-Fehler in der Ereignisanzeige prüfen

Bei der Fehlersuche kann auch die Windows-Ereignisanzeige helfen.

WMI-Aktivitäten findest du unter:

Ereignisanzeige
→ Anwendungs- und Dienstprotokolle
→ Microsoft
→ Windows
→ WMI-Activity
→ Operational

Dort können Hinweise auf fehlgeschlagene WMI-Abfragen, beteiligte Prozesse oder WMI-Anbieter zu finden sein.

Eingabeaufforderung als Administrator öffnen

Für die folgenden Befehle benötigst du Administratorrechte.

Öffne das Startmenü und gib

cmd

ein.

Klicke anschließend bei Eingabeaufforderung auf Als Administrator ausführen.

Bestätige gegebenenfalls die Abfrage der Benutzerkontensteuerung.

WMI-Repository mit verifyrepository überprüfen

Bevor etwas repariert wird, sollte zunächst geprüft werden, ob das WMI-Repository tatsächlich inkonsistent ist.

Gib dazu folgenden Befehl ein:

winmgmt /verifyrepository

und bestätige mit der Eingabetaste.

verifyrepository führt eine Konsistenzprüfung des aktuell von Windows verwendeten WMI-Repositorys durch.

Das Repository ist konsistent

Meldet Windows, dass das WMI-Repository konsistent ist, solltest du nicht einfach mit weiteren Repository-Reparaturen fortfahren.

Ein vorhandenes WMI-Problem kann dann eine andere Ursache haben.

In diesem Fall sollte zunächst genauer geprüft werden, welche Anwendung oder welcher WMI-Anbieter den Fehler verursacht und welche Meldungen in der Ereignisanzeige vorhanden sind.

Ein Zurücksetzen des Repositorys „auf Verdacht“ ist nicht empfehlenswert.

Das Repository ist inkonsistent

Wird das Repository dagegen als inkonsistent gemeldet, kann ein Reparaturversuch mit salvagerepository sinnvoll sein.

Inkonsistentes WMI-Repository reparieren

Gib in der als Administrator gestarteten Eingabeaufforderung folgenden Befehl ein:

winmgmt /salvagerepository

salvagerepository prüft das WMI-Repository ebenfalls auf Konsistenz.

Wird dabei eine Inkonsistenz festgestellt, erstellt Windows das Repository neu und versucht, die noch lesbaren Inhalte des bisherigen Repositorys in das neue Repository zu übernehmen. Zusätzlich werden dafür vorgesehene Auto-Recovery-MOF-Dateien wieder eingelesen.

Damit ist salvagerepository wesentlich gezielter als ein vollständiges Zurücksetzen des WMI-Repositorys.

Nach Abschluss solltest du erneut prüfen:

winmgmt /verifyrepository

Wird das Repository jetzt als konsistent gemeldet, ist keine weitere Repository-Reparatur erforderlich.

Ein Neustart von Windows ist anschließend sinnvoll, bevor du überprüfst, ob das ursprüngliche Problem noch besteht.

Was macht winmgmt /resetrepository?

Im Internet findet man häufig Anleitungen, die nach verifyrepository und salvagerepository direkt folgenden Befehl empfehlen:

winmgmt /resetrepository

Dieser Befehl existiert tatsächlich, sollte aber nicht als gewöhnlicher Reparaturschritt auf Verdacht verwendet werden.

Microsoft beschreibt seine Funktion eindeutig: Das WMI-Repository wird auf den Zustand zurückgesetzt, den es bei der ursprünglichen Installation des Betriebssystems hatte. Dafür vorgesehene Auto-Recovery-MOF-Dateien werden anschließend wieder eingelesen.

Warum ist das Zurücksetzen problematisch?

Das WMI-Repository enthält nicht nur Informationen des ursprünglichen Windows-Systems.

Im Laufe der Nutzung können auch Anwendungen, Dienste und andere Komponenten Informationen beziehungsweise eigene WMI-Anbieter registrieren.

Microsoft weist deshalb ausdrücklich darauf hin, dass ein vollständiger Neuaufbau des WMI-Repositorys dazu führen kann, dass solche über die Zeit hinzugekommenen Informationen verloren gehen.

Im aktuellen Microsoft-Troubleshooting wird deshalb davon abgeraten, das WMI-Repository einfach neu aufzubauen, sofern dies nicht im Rahmen einer gezielten Fehleranalyse erforderlich ist.

Unsere Empfehlung: Verwende winmgmt /resetrepository nicht als normalen dritten Reparaturschritt. Wenn salvagerepository ein tatsächlich inkonsistentes Repository nicht reparieren kann, sollte zunächst die genaue Ursache des WMI-Fehlers untersucht werden.

Vor weitergehenden Änderungen sollte außerdem eine aktuelle Sicherung wichtiger Daten vorhanden sein.

Was macht winmgmt /resyncperf?

Ein weiterer häufig genannter Befehl ist resyncperf. Er gehört ebenfalls zu winmgmt, hat jedoch einen völlig anderen Zweck als die Prüfung oder Reparatur des WMI-Repositorys.

Microsoft dokumentiert dafür folgende Syntax:

winmgmt /resyncperf <Prozess-ID-des-WMI-Dienstes>

resyncperf registriert die Leistungsbibliotheken des Computers bei WMI neu. Dabei muss die Prozess-ID des WMI-Dienstes angegeben werden.

Microsoft sieht diese Funktion nur für Fälle vor, in denen die über WMI bereitgestellten Performance-Monitor-Klassen keine zuverlässigen Ergebnisse liefern.

Der Befehl gehört deshalb nicht in die normale Prüfung oder Reparatur eines WMI-Repositorys.

Wenn Leistungsindikatoren beziehungsweise Performance Counter fehlen oder falsche Werte liefern, kann resyncperf im Rahmen einer gezielten Reparatur dieser Leistungsindikatoren relevant sein.

Bei einem inkonsistenten WMI-Repository oder einem gewöhnlichen Treiberproblem ist dieser Befehl dagegen nicht erforderlich.

WMI, Leistungsindikatoren und Treiber sind nicht dasselbe

Die Begriffe werden in älteren Anleitungen häufig miteinander vermischt.

WMI ist eine Windows-Verwaltungsinfrastruktur, über die Informationen abgefragt und Verwaltungsfunktionen bereitgestellt werden.

Das WMI-Repository speichert dafür benötigte Klassen, Definitionen und Registrierungsinformationen.

Leistungsindikatoren stellen Messwerte beispielsweise für Prozessor, Arbeitsspeicher, Datenträger, Dienste oder Anwendungen bereit. Einige dieser Informationen können über WMI abgefragt werden.

Ein Gerätetreiber ist dagegen Software, mit deren Hilfe Windows mit einem Hardwaregerät kommunizieren kann.

Die Geräte- und Treiberverwaltung erfolgt über andere Windows-Komponenten und Werkzeuge.

winmgmt ist daher kein allgemeines Reparaturwerkzeug für Windows-Treiber.

Wenn tatsächlich ein Treiber Probleme verursacht

Zeigt der Geräte-Manager ein Gerät mit einem Warnsymbol an, funktioniert ein Gerät seit einer Treiberaktualisierung nicht mehr oder fehlt ein Gerät vollständig, solltest du nicht mit einer WMI-Reparatur beginnen.

Für Treiberprobleme sind andere Werkzeuge vorgesehen.

Microsoft empfiehlt für normale Treiberaktualisierungen in erster Linie Windows Update. Treiber können außerdem über den Geräte-Manager aktualisiert, neu installiert oder – nach problematischen Updates – auf eine vorherige Version zurückgesetzt werden.

Treiber sollten möglichst über Windows Update oder direkt über die offizielle Supportseite des Geräte- beziehungsweise Computerherstellers bezogen werden.

Für eine genauere Diagnose steht außerdem das Windows-Werkzeug PnPUtil zur Verfügung.

Mit

pnputil /enum-devices /problem

lassen sich beispielsweise Geräte anzeigen, für die Windows einen Problemcode festgestellt hat.

Das ist eine tatsächliche Geräte- und Treiberdiagnose und damit etwas anderes als die Reparatur des WMI-Repositorys.

SFC und DISM bei beschädigten Windows-Systemkomponenten

Treten neben WMI-Problemen weitere Windows-Fehler auf oder besteht der Verdacht, dass Systemdateien beschädigt sind, können zusätzlich die Windows-Werkzeuge DISM und SFC sinnvoll sein.

DISM kann Beschädigungen des Windows-Komponentenspeichers reparieren:

DISM.exe /Online /Cleanup-Image /RestoreHealth

Anschließend können die geschützten Windows-Systemdateien überprüft werden:

sfc /scannow

Auch diese Befehle reparieren nicht direkt Gerätetreiber. Sie sind dafür vorgesehen, beschädigte oder fehlende Windows-Systemkomponenten beziehungsweise Systemdateien zu überprüfen und zu reparieren.

Hinweis zu einer früheren Fassung dieses Artikels

Eine frühere Version dieses Artikels trug sinngemäß den Titel „Treiberverwaltung reparieren – winmgmt“.

Diese Einordnung war fachlich zu pauschal.

Die beschriebenen winmgmt-Befehle gehören zur Windows Management Instrumentation (WMI). Sie reparieren nicht allgemein die Windows-Treiberverwaltung und können auch nicht gewährleisten, dass anschließend alle Gerätetreiber ordnungsgemäß funktionieren.

Wir haben den Artikel deshalb fachlich überarbeitet und die einzelnen Befehle ihrem tatsächlichen Einsatzzweck zugeordnet.

Fazit

winmgmt ist ein wichtiges Windows-Werkzeug zur Verwaltung und Fehlerbehandlung von Windows Management Instrumentation.

Bei Verdacht auf ein beschädigtes WMI-Repository sollte zunächst mit

winmgmt /verifyrepository

geprüft werden, ob überhaupt eine Inkonsistenz vorliegt.

Nur wenn Windows tatsächlich ein inkonsistentes Repository feststellt, ist

winmgmt /salvagerepository

ein sinnvoller Reparaturversuch.

winmgmt /resetrepository ist dagegen keine harmlose Standardreparatur und sollte nicht vorsorglich ausgeführt werden.

winmgmt /resyncperf hat wiederum einen anderen Zweck und dient der Synchronisation von Windows-Leistungsindikatoren mit WMI.

Der entscheidende Unterschied lautet daher:

winmgmt prüft und repariert WMI beziehungsweise das WMI-Repository – nicht pauschal die Windows-Treiberverwaltung.