Naprawiono błąd identyfikatora zdarzenia 10016: serwer DCOM nie ma uprawnień do lokalnej aktywacji dla PCNAME\Username SID
Ostatnio na moim komputerze z systemem Windows 8.1, znikąd, zacząłem otrzymywać błędy w dzienniku zdarzeń po zainstalowaniu aktualizacji we wtorek z łatką. Błąd dotyczył rozproszonego COM (DCOM):
Ustawienia uprawnień specyficzne dla aplikacji nie przyznają uprawnienia do lokalnej aktywacji dla aplikacji COM Server z CLSID {9E175B6D-F52A-11D8-B9A5-505054503030} i APPID {9E175B9C-F52A-11D8-B9A5-505054503030} do użytkownika PCNAME\Username SID S-1-5-21-81864976-3388411891-1937036257-1001 z adresu LocalHost (Using LRPC) uruchomiony w kontenerze aplikacji Niedostępny identyfikator SID (S-1-15-2-1430448594-2639229838-973813799-439329657-1197984847-4069167804-1277922394). To uprawnienie bezpieczeństwa można modyfikować za pomocą narzędzia administracyjnego Component Services.
Tak skomplikowany błąd może sprawić, że niedoświadczeni użytkownicy zwymiotują z frustracji. Nie znają tej terminologii. Ponadto rozwiązywanie problemów z błędami DCOM jest uciążliwe, więc na początku je zignorowałem, ale dziennik zdarzeń był ich pełen, ponieważ występowały co godzinę. Zdeterminowany, aby to naprawić, postanowiłem zbadać sprawę.
Reklama
Dla tych z Was, którzy nie wiedzą, COM jest starą technologią komunikacji międzyprocesowej Microsoftu, zorientowaną obiektowo. Serwer COM to plik wykonywalny (EXE lub DLL), który implementuje zestaw obiektów COM. Wiele składników systemu Windows jest zaimplementowanych jako obiekty COM i komunikuje się ze sobą zgodnie ze standardowymi regułami COM. Serwery COM są zarejestrowane w Rejestrze i mają identyfikator klasy (CLSID) oraz APPID.
Pierwszym krokiem do rozwiązania tego błędu było ustalenie, z którym składnikiem DCOM są powiązane identyfikatory CLSID i APPID. Uruchom Edytor rejestru i przejdź do tego klucza rejestru:
HKEY_CLASSES_ROOT\CLSID\{9E175B6D-F52A-11D8-B9A5-505054503030}
Ten klucz rejestru wskazuje również na ten sam identyfikator aplikacji, co komunikat o błędzie, czyli {9E175B9C-F52A-11D8-B9A5-505054503030}. Więc przejdź do
HKCR\APPID\{9E175B9C-F52A-11D8-B9A5-505054503030}
To powiedziało mi, że komponentem był WSearch (obiekt COM wyszukiwania systemu Windows).
Następnym krokiem było przypisanie do tego identyfikatora CLSID/AppID prawidłowych uprawnień do aktywacji lokalnej, które chciał — mojego identyfikatora bezpieczeństwa użytkownika (SID) i identyfikatora SID aplikacji. W tym celu system Windows udostępnia narzędzie Component Services, które pozwala użytkownikowi modyfikować uprawnienia uruchamiania i aktywacji, uprawnienia dostępu i uprawnienia konfiguracyjne na serwerach COM.
Otwórz Narzędzia administracyjne -> Usługi składowe. Rozwiń Usługi składowe -> Komputer -> Mój komputer -> Konfiguracja DCOM. Zlokalizuj 'WSearch' i kliknij prawym przyciskiem myszy -> Właściwości. Przejdź do zakładki „Bezpieczeństwo”.
Po wykonaniu tej czynności zobaczyłem, że wszystko jest wyszarzone (wyłączone) na karcie Zabezpieczenia dla tego obiektu COM, więc najpierw musiałem nadać mojemu kontu użytkownika pełne uprawnienia w Rejestrze. Ponownie otworzyłem Regedit i poszedłem do tego samego klucza
HKEY_CLASSES_ROOT\AppID\{9E175B9C-F52A-11D8-B9A5-505054503030}
i zmienił uprawnienia. Najpierw musisz przejąć własność (zaznacz „Zamień właściciela w podkontenerach i obiektach”), a następnie dodaj swoją nazwę użytkownika i przekaż mu pełną kontrolę. Następnie możesz zmienić własność z powrotem na oryginalne konto (NT Service\TrustedInstaller).
Przejęcie własności i nadanie uprawnień administratora jest niezwykle łatwe dzięki Winaero RegWłasnośćEx aplikacja.
Teraz ponownie otworzyłem Component Services (Dcomcnfg.exe) i przeszedłem do właściwości WSearch, zakładki Security i był teraz w stanie edytować uprawnienia bezpieczeństwa w uprawnieniach uruchamiania i aktywacji, które są pokazane w następujący sposób ten:
Dzięki grupie bezpieczeństwa Wszyscy, moje konto użytkownika ma już uprawnienia do lokalnej aktywacji, ale są też pokazane 3 inne identyfikatory SID, które nie są znanymi kontami użytkowników lub grupami, jak wskazuje ich ikona. Są to identyfikatory SID aplikacji i odnoszą się do aplikacji. Błąd dziennika zdarzeń powiedział również „... uruchomiony w kontenerze aplikacji Niedostępny identyfikator SID (S-1-15-2-1430448594-2639229838-973813799-439329657-1197984847-4069167804-1277922394).
Teraz interfejs użytkownika selektora obiektów systemu Windows nie pozwala na dodawanie identyfikatorów SID aplikacji dla obiektów głównych zabezpieczeń. Więc po kliknięciu Dodaj, kliknąłem Zaawansowane... a następnie Znajdź teraz. Spowoduje to wyświetlenie listy wszystkich obiektów. Ale większość z nich to identyfikatory SID kont. Zauważyłem "WSZYSTKIE PAKIETY APLIKACJI", które jak sama nazwa wskazuje jest prawdopodobnie grupą dla wszystkich pakietów aplikacji, więc ją wybrałem. Kliknij OK wszędzie, aby go dodać, a następnie nadaj mu uprawnienia Lokalne uruchamianie i Lokalna aktywacja.
Teraz po kliknięciu OK i zamknięciu interfejsu Component Services błąd znika z dziennika zdarzeń, co oznacza, że składnik WSearch COM ma teraz prawidłowe uprawnienia do lokalnego uruchamiania i aktywacji.
Napisałem ten artykuł jako ogólny przewodnik, aby pomóc każdemu w podobny sposób rozwiązywać błędy DCOM w ich dzienniku zdarzeń. Nadal jestem zaniepokojony, dlaczego system Windows nie ma jeszcze narzędzia do łatwego przywracania prawidłowych uprawnień do obiektów COM na wypadek, gdyby się popsuły.
