Get-WmiObject nie działa – wyjątek COM

Get-WmiObject nie działa z wyjątkiem COM wskazuje na uszkodzone repozytorium WMI — naprawia się je poleceniem winmgmt /resetrepository.

Czym jest problem „Get-WmiObject nie działa – wyjątek COM”

Get-WmiObject to starszy mechanizm programu PowerShell służący do odczytywania informacji zarządzania systemem Windows za pośrednictwem technologii WMI, czyli Windows Management Instrumentation. Polecenie może zwracać dane o sprzęcie, usługach, procesach, sterownikach, systemie operacyjnym oraz konfiguracji komputera. Gdy podczas jego uruchamiania pojawia się wyjątek COM, oznacza to, że PowerShell nie zdołał prawidłowo nawiązać komunikacji z komponentem odpowiedzialnym za obsługę żądania WMI.

Sam komunikat COM nie wskazuje jeszcze jednej, konkretnej przyczyny. Może wiązać się z niesprawnością usługi Windows Management Instrumentation, błędem dostępu do określonej przestrzeni nazw, problemem z dostawcą WMI albo niespójnością lokalnego magazynu danych. W niektórych przypadkach awaria ujawnia się dopiero przy odwołaniu do konkretnej klasy, na przykład informacji o systemie, dyskach lub urządzeniach Plug and Play. Dlatego nie powinno się traktować każdego wyjątku COM jako jednoznacznego dowodu uszkodzenia całego repozytorium.

Rozpoznanie problemu wymaga odczytania pełnej treści błędu, numeru HRESULT, nazwy przestrzeni nazw oraz polecenia, które wywołało wyjątek. Znaczenie ma także to, czy błąd występuje na lokalnym komputerze, czy podczas łączenia ze zdalnym systemem. Inaczej postępuje się przy problemie z lokalną usługą WMI, inaczej przy ograniczeniach uprawnień, a jeszcze inaczej przy błędzie konkretnego dostawcy sprzętowego.

Kontekst techniczny i porównanie z nowszym podejściem

WMI działa jako warstwa pośrednia pomiędzy narzędziami administracyjnymi a elementami systemu Windows. Get-WmiObject korzysta z interfejsów COM oraz starszego modelu komunikacji DCOM. Oznacza to, że powodzenie polecenia zależy nie tylko od samego PowerShella, lecz także od dostępności odpowiedniej usługi, poprawności rejestracji komponentów, uprawnień użytkownika i odpowiedzi dostawcy WMI.

W nowszych skryptach administracyjnych częściej stosuje się polecenia z rodziny Get-CimInstance. Korzystają one z modelu CIM i zazwyczaj lepiej pasują do współczesnych mechanizmów zarządzania systemami. Nie oznacza to jednak, że zamiana jednego polecenia na drugie zawsze rozwiąże problem. Jeżeli przyczyną jest uszkodzona klasa, niedostępna przestrzeń nazw, wadliwy sterownik albo niesprawna usługa, podobny problem może wystąpić również przy użyciu nowszego interfejsu.

W pierwszej kolejności można sprawdzić stan usługi WMI poleceniem Get-Service -Name winmgmt. Przydatne bywa także wykonanie prostego zapytania do podstawowej przestrzeni nazw, na przykład:

Get-CimInstance -Namespace root\cimv2 -ClassName Win32_OperatingSystem

Jeśli takie zapytanie działa, a błąd pojawia się tylko przy jednej klasie, bardziej prawdopodobny staje się problem z konkretnym dostawcą lub danymi tej klasy. Jeżeli nie działa nawet podstawowe odwołanie, należy rozszerzyć diagnostykę o usługę WMI, dzienniki zdarzeń, uprawnienia oraz stan składników systemu.

Polecenie winmgmt /verifyrepository pozwala sprawdzić spójność repozytorium WMI. W razie wykrycia niespójności można rozważyć działania naprawcze, w tym mechanizmy dostępne w narzędziu winmgmt. Reset repozytorium nie powinien być wykonywany automatycznie, ponieważ może usunąć lub odtworzyć dane dostawców zainstalowanych przez programy i sterowniki. Przed taką operacją warto ustalić, czy istnieje kopia zapasowa, punkt przywracania oraz dokumentacja używanego oprogramowania.

Typowe problemy i błędy wywołujące wyjątek COM

Jedną z częstszych przyczyn jest zatrzymana albo niestabilna usługa Windows Management Instrumentation. W takim przypadku zapytania mogą kończyć się błędem mimo poprawnej składni polecenia. Niekiedy usługa działa, lecz nie odpowiada prawidłowo, ponieważ zależne składniki systemu zostały zatrzymane albo wystąpiło chwilowe przeciążenie. Pomocne może być sprawdzenie statusu usługi, jej zależności oraz zdarzeń zapisanych w Podglądzie zdarzeń.

Inny scenariusz dotyczy uszkodzonych lub niekompletnych danych repozytorium WMI. Objawem bywa błąd dotyczący tylko wybranych klas, brak informacji o urządzeniach albo komunikaty pojawiające się po instalacji lub usunięciu sterownika. Taką sytuację należy odróżnić od zwykłego braku uprawnień, ponieważ naprawa repozytorium nie usunie ograniczeń konta użytkownika.

Przy połączeniach zdalnych dodatkowe znaczenie mają zasady DCOM, zapora systemowa, konfiguracja usługi WinRM, uprawnienia administracyjne oraz dostęp do odpowiedniej przestrzeni nazw. Błąd COM w takim środowisku może wynikać z braku komunikacji między komputerami, a nie z lokalnego uszkodzenia WMI. Warto więc sprawdzić, czy ten sam skrypt działa bez parametru zdalnego komputera i czy problem powtarza się na innym koncie.

Wyjątek może być również skutkiem błędnego dostawcy WMI powiązanego z konkretnym sterownikiem lub aplikacją. Dotyczy to między innymi narzędzi monitorujących, programów do zarządzania sprzętem oraz komponentów dodających własne klasy WMI. W takich przypadkach warto ustalić, jakie zapytanie uruchamia błąd, od kiedy problem występuje i czy pojawił się po aktualizacji sterownika, instalacji programu albo zmianie konfiguracji systemu.

Przed użyciem poleceń naprawczych zaleca się zapisanie pełnego komunikatu błędu, wykonanie kopii ważnych danych oraz sprawdzenie, czy problem dotyczy jednego konta, jednego skryptu czy całego systemu. Nie powinno się usuwać katalogów repozytorium WMI ręcznie ani kasować jego zawartości bez rozpoznania zależności. Takie działanie może spowodować kolejne błędy aplikacji korzystających z usług zarządzania Windows.

Kiedy warto zgłosić sprzęt do serwisu - Get-WmiObject nie działa – wyjątek COM

Zgłoszenie do serwisu jest uzasadnione, gdy wyjątek COM powtarza się po ponownym uruchomieniu komputera, pojawia się w kilku niezależnych narzędziach albo uniemożliwia odczyt podstawowych informacji o systemie. Szczególnej uwagi wymaga sytuacja, w której razem z błędem WMI występują problemy ze sterownikami, niestabilność usług, nieprawidłowe działanie aplikacji administracyjnych lub komunikaty o uszkodzeniu składników Windows.

Przed przekazaniem urządzenia warto przygotować nazwę polecenia, pełny tekst wyjątku, informację o wersji Windows oraz opis czynności wykonanych bezpośrednio przed pojawieniem się usterki. Ułatwia to odróżnienie problemu z repozytorium od błędu uprawnień, dostawcy lub komunikacji zdalnej. W razie potrzeby można również wskazać, czy awaria występuje w PowerShellu uruchomionym z uprawnieniami administratora oraz czy dotyczy wszystkich klas WMI.

W Warszawie takie przypadki można przekazać do „Warszawskiego Pogotowia Komputerowego 24/7”, gdzie dostępna jest darmowa diagnoza LAPTOPA. Podczas sprawdzania można zweryfikować usługę WMI, spójność repozytorium, dzienniki systemowe, zależności sterowników i poprawność wykonywania zapytań, a następnie dobrać działanie o możliwie małym wpływie na pozostałe elementy systemu.

Nie każda awaria wymaga resetowania repozytorium. Czasem wystarcza przywrócenie działania usługi, naprawa składników systemu, korekta uprawnień albo usunięcie wadliwego dostawcy. Jeżeli jednak błąd dotyczy wielu klas i utrzymuje się mimo podstawowych czynności diagnostycznych, potrzebne może być szersze sprawdzenie systemu przed wykonaniem operacji naprawczej.