WMI-Problembehandlung
Beim Zugriff auf lokale WMI- oder Remotedaten in einer Anwendung oder einem Skript können Fehler auftreten, die von fehlenden Klassen bis hin zu verweigerten Zugriff reichen. Anbieter verfügen auch über Debugoptionen und Problembehandlungsklassen.
Hinweis
Die Informationen in diesem Thema richten sich an Entwickler und IT-Administratoren. Wenn Sie ein Endbenutzer sind, bei dem eine Fehlermeldung zu WMI aufgetreten ist, besuchen Sie Microsoft-Support, und suchen Sie nach dem Fehlercode, der in der Fehlermeldung angezeigt wird. Weitere Informationen zur Behandlung von Problemen mit WMI-Skripts und dem WMI-Dienst finden Sie unter WMI funktioniert nicht!
WMI-Diagnosehilfsprogramm
Wichtig
Die WMI-Diagnosehilfsprogramm (WMIDiag.exe
) wird ab Windows 8 und Windows Server 2012 nicht mehr unterstützt.
Windows 7, Windows Server 2008 R2, Windows Vista und Windows Server 2008:
Wenn WMI Fehlermeldungen zurückgibt, sollten Sie beachten, dass diese möglicherweise nicht auf Probleme im WMI-Dienst oder in WMI-Anbietern hinweisen. Fehler können aus anderen Teilen des Betriebssystems stammen und über WMI als Fehler auftreten. Auf keinen Fall sollten Sie das WMI-Repository als ersten Schritt löschen. da das Löschen des Repositorys zu Schäden am System oder an installierten Anwendungen führen kann.
Um weitere Informationen zur Ursache des Problems zu erhalten, konnten Sie zuvor das WMI-Diagnosehilfsprogramm Diagnosebefehlszeilentool herunterladen und ausführen. Dieses Tool hat einen Bericht erstellt, der in der Regel die Ursache des Problems isolieren und Anweisungen zum Beheben des Problems bereitstellt. Der Bericht hat auch die Microsoft-Supportdienste bei der Unterstützung unterstützt. Die WMI-Diagnosehilfsprogramm war zuvor im Download Center verfügbar.
Als Anbieterautor treten möglicherweise auch Debugprobleme auf, es sei denn, Sie schreiben einen entkoppelten Anbieter. Weitere Informationen finden Sie unter Debuggen von Anbietern.
Protokollierung und Nachverfolgung
Die WMI-Protokolldateien sind nicht mehr vorhanden. Sie wurden durch die Ereignisablaufverfolgung für Windows (ETW) ersetzt. Weitere Informationen finden Sie unter Ablaufverfolgung von WMI-Aktivitäten, Protokollierung von WMI-Aktivitäten und WMI-Protokolldateien.
Problembehandlung in Skripts und Anwendungen
WMI enthält eine Reihe von Klassen für die Problembehandlung Clientanwendungen, die WMI-Anbieter verwenden. Weitere Informationen finden Sie unter Problembehandlung für WMI-Clientanwendungen.
Wie Anbieterautoren WMI-Probleme verhindern können
Anbieterautoren können viele Probleme verhindern (die in Fehlermeldungen über WMI angezeigt werden), indem sie die folgenden Aktionen ausführen:
- Korrektes Registrieren Ihres Anbieters. Weitere Informationen finden Sie unter Registrieren eines Anbieters.
- Hinzufügen der #pragma autorecover-Anweisung zu der MOF-Datei (Managed Object Format), die Ihre Anbieterklassen definiert.
Weitere Informationen finden Sie unter Debuggen von Anbietern, Bereitstellen von Daten für WMI und Anbieterkonfigurations- und Problembehandlungsklassen.
Zugriff verweigert.
Zugriff verweigerte Fehler, die von Skripts und Anwendungen gemeldet werden, die auf WMI-Namespaces und -Daten zugreifen, fallen in der Regel in drei Kategorien. In der folgenden Tabelle sind die drei Fehlerkategorien zusammen mit Problemen aufgeführt, die diese Fehler verursachen können. Zudem werden mögliche Lösungen angegeben.
Fehler | Mögliche Probleme | Lösung |
---|---|---|
0x800706BA HRESULT_FROM_WIN32(RPC_S_SERVER_UNAVAILABLE) Firewallproblem oder Server nicht verfügbar. |
Der Computer ist nicht vorhanden, oder die Windows-Firewall blockiert die Verbindung. |
Herstellen einer Verbindung mit Vista: netsh advfirewall firewall set rule group="windows management instrumentation (wmi)" new enable=yes Verbinden mit früheren Versionen: Lassen Sie die Regel „Remoteverwaltung“ in der Windows-Firewall zu. |
0x80070005 E_ACCESS_DENIED Zugriff durch DCOM-Sicherheit verweigert. |
Benutzer*in hat keinen Remotezugriff auf den Computer über DCOM. In der Regel treten DCOM-Fehler auf, wenn eine Verbindung mit einem Remotecomputer mit einer anderen Betriebssystemversion hergestellt wird. |
Erteilen Sie dem Benutzer/der Benutzerin Remotestart- und Remoteaktivierungsberechtigungen in dcomcnfg. Klicken Sie mit der rechten Maustaste auf „Arbeitsplatz“ > „Eigenschaften“. Klicken Sie unter „COM-Sicherheit“ für beide Abschnitte auf „Grenzwerte bearbeiten“. Gewähren Sie dem/der betreffenden Benutzer*in die Berechtigung für Remotezugriff, Remotestart und Remoteaktivierung. Wechseln Sie dann zu DCOM-Konfiguration, suchen Sie nach „Windows-Verwaltungsinstrumentation“, und gewähren Sie dem/der betreffenden Benutzer*in die Berechtigung für Remotestart und Remoteaktivierung. Weitere Informationen finden Sie unter Herstellen einer Verbindung zwischen verschiedenen Betriebssystemen. |
0x80041003 WBEM_E_ACCESS_DENIED Zugriff von einem Anbieter verweigert |
Benutzer*in verfügt nicht über ausreichende Berechtigungen zum Durchführen des Vorgangs in WMI. Dies kann vorkommen, wenn Sie bestimmte Klassen als Benutzer*in mit niedrigen Rechten abfragen, tritt aber am häufigsten auf, wenn Sie als Benutzer*in mit niedrigen Rechten versuchen, Methoden aufzurufen oder WMI-Instanzen zu ändern. Der Namespace, mit dem Sie eine Verbindung herstellen, ist verschlüsselt, und der/die Benutzer*in versucht, eine unverschlüsselte Verbindung herzustellen. |
Gewähren Sie dem/der Benutzer*in Zugriff über das WMI-Steuerelement. (Stellen Sie sicher, dass Remote_Access auf TRUE festgelegt ist.) Stellen Sie eine Verbindung über einen Client her, der die Verschlüsselung unterstützt. |
In der Regel treten DCOM-Fehler auf, wenn eine Verbindung mit einem Remotecomputer mit einer anderen Betriebssystemversion hergestellt wird.
Anbieter können auch den Zugriff auf Daten in bestimmten Namespaces verweigern oder bestimmte Ebenen der Verbindungssicherheit erfordern. Weitere Informationen finden Sie unter Festlegen der Sicherheit des Clientanwendungsprozesses und unter Anbieterhosting und Sicherheit.
Zugriffsverweigerungsfehler bei ICF-Änderungen (Internet Connection Firewall).
Weitere Informationen finden Sie unter Herstellen einer Verbindung über die Windows-Firewall.
Wenn ein Client mit niedriger Integritätsebene versucht, auf WMI zuzugreifen, wird von der DCOM-Sicherheit ein Zugriffsverweigerungsfehler zurückgegeben. Beispielsweise hat ein ActiveX-Steuerelement, das in Internet Explorer mit auf „niedrig“ festgelegter Sicherheitsstufe ausgeführt wird, keinen Zugriff auf lokale WMI-Vorgänge.
Windows 7: Benutzer*innen mit niedriger Integritätsebene verfügen über Schreibschutzberechtigungen für lokale WMI-Vorgänge.
Informationen zu Fehlern
Wenn Sie eine Fehlermeldung von WMI erhalten, können Sie die Meldung in WMI-Fehlerkonstanten oder (zur Skripterstellung) in WbemErrorEnum suchen. Die durch den Fehler bereitgestellten Informationen allein reichen jedoch in der Regel nicht aus, um die Ursachen zu bestimmen. Eine Beschädigung des WMI-Repositorys kann als nicht gefundene Klassen oder Instanzen angegeben werden.
Weitere Informationen zu WMI-Fehlern:
- Die WMI-Protokolle verfolgen Ereignisse innerhalb des WMI-Kerns und über Anbieter nach. Weitere Informationen finden Sie unter Protokollieren der WMI-Aktivität.
- Verwenden Sie die WMI-Problembehandlungsklassen, um interne WMI-Status zu überprüfen oder Benachrichtigungen über Anbieter- oder WMI-Dienstereignisse zu erhalten. Weitere Informationen finden Sie unter Anbieterkonfigurations- und Problembehandlungsklassen und unter Problembehandlung für WMI-Clientanwendungen.