Onlangs kreeg ik op mijn Windows 8.1-pc uit het niets fouten in het gebeurtenislogboek na het installeren van updates op een patchdinsdag. De fout had betrekking op gedistribueerde COM (DCOM):
hoe terug te gaan naar het oude google chrome
De applicatiespecifieke machtigingsinstellingen verlenen geen lokale activeringstoestemming voor de COM Server-toepassing met CLSID {9E175B6D-F52A-11D8-B9A5-505054503030} en APPID {9E175B9C-F52A-11D8-B9A5-505054503030} aan de gebruiker PCNAME Username SID S-1-5-21-81864976-3388411891-1937036257-1001 vanaf adres LocalHost (met LRPC) draait in de applicatiecontainer Niet beschikbaar SID (S-1-15-2-1430448594-2639229838-973813799-439329657-1197984847-4069167804- 1277922394). Deze veiligheidsmachtiging kan worden gewijzigd met het Component Services-beheerprogramma.
Zo'n gecompliceerde fout kan onervaren gebruikers doen overgeven van frustratie. Ze zijn niet bekend met deze terminologie. Bovendien is het oplossen van DCOM-fouten vervelend, dus ik negeerde het in eerste instantie, maar het gebeurtenislogboek zat er vol mee omdat het ongeveer elk uur voorkwam. Vastbesloten om het te repareren, besloot ik het te onderzoeken.
Advertentie
Voor degenen onder u die het niet weten: COM is de oude objectgeoriënteerde communicatietechnologie tussen processen van Microsoft. Een COM-server is een uitvoerbaar bestand (EXE of DLL) dat een set COM-objecten implementeert. Veel Windows-componenten zijn geïmplementeerd als COM-objecten en volgen standaard COM-regels om met elkaar te communiceren. COM-servers zijn geregistreerd in het register en hebben een klasse-ID (CLSID) en een APPID.
De eerste stap om deze fout op te lossen, was uitzoeken aan welke DCOM-component de CLSID en APPID gerelateerd waren. Dus start de Register-editor en ga naar deze registersleutel:
HKEY_CLASSES_ROOT CLSID {9E175B6D-F52A-11D8-B9A5-505054503030}Deze registersleutel verwijst ook naar dezelfde AppID als het foutbericht, namelijk {9E175B9C-F52A-11D8-B9A5-505054503030}. Dus ga vervolgens naar
HKCR APPID {9E175B9C-F52A-11D8-B9A5-505054503030}Dit vertelde me dat het onderdeel WSearch was (een Windows Search COM-object).
De volgende stap was om aan deze CLSID / AppID de juiste lokale activeringsmachtigingen toe te wijzen die het wilde - van mijn gebruiker Security ID (SID) en de app-SID. Om dat te doen, biedt Windows een Component Services-tool waarmee de gebruiker start- en activeringsrechten, toegangsrechten en configuratiemachtigingen op COM-servers kan wijzigen.
Open Systeembeheer -> Component Services. Vouw Component Services -> Computer -> Deze computer -> DCOM-configuratie uit. Zoek 'WSearch' en klik er met de rechtermuisknop op -> Eigenschappen. Ga naar het tabblad 'Beveiliging'.
Toen ik dit deed, zag ik dat alles grijs was (uitgeschakeld) op het tabblad Beveiliging voor dit COM-object, dus ik moest mijn gebruikersaccount eerst volledige machtigingen in het register geven. Ik opende Regedit opnieuw en ging naar dezelfde sleutel
HKEY_CLASSES_ROOT AppID {9E175B9C-F52A-11D8-B9A5-505054503030}en veranderde de machtigingen. Eerst moet u het eigendom overnemen (vink 'Eigenaar van subcontainers en objecten vervangen' aan), en vervolgens uw gebruikersnaam toevoegen en deze Volledige controle geven. Daarna kunt u het eigendom terugzetten naar het oorspronkelijke account (NT Service TrustedInstaller).
Eigendom nemen en beheerdersrechten geven is buitengewoon eenvoudig met Winaero's RegOwnershipEx app.
Nu heb ik de Component Services (Dcomcnfg.exe) opnieuw geopend en ging ik naar WSearch-eigenschappen, het tabblad Beveiliging en kon nu de Beveiligingsmachtigingen voor Start- en activeringsrechten bewerken, die als volgt worden weergegeven:
Via de beveiligingsgroep Everyone heeft mijn gebruikersaccount al lokale activeringsrechten, maar er worden ook 3 andere SID's weergegeven die geen bekende gebruikersaccounts of groepen zijn, zoals hun pictogram aangeeft. Het zijn applicatie-SID's en verwijzen naar applicaties. De gebeurtenislogboekfout zei ook '... wordt uitgevoerd in de applicatiecontainer Niet beschikbaar SID (S-1-15-2-1430448594-2639229838-973813799-439329657-1197984847-4069167804-1277922394).
Nu lijkt het erop dat de gebruikersinterface van de Windows-objectkiezer u geen toepassings-SID's voor beveiligings-principal-objecten laat toevoegen. Dus nadat ik op Toevoegen had geklikt, klikte ik op Geavanceerd ... en vervolgens op Nu zoeken. Hiermee worden alle objecten weergegeven. Maar de meeste waren account-SID's. Ik merkte 'ALLE APPLICATIEPAKKETTEN' op die, zoals de naam al aangeeft, waarschijnlijk een groep is voor alle applicatiepakketten, dus heb ik deze geselecteerd. Klik overal op OK om het toe te voegen en geef het vervolgens machtigingen Lokaal starten en Lokaal activeren.
bekijk alle YouTube-opmerkingen die je hebt gemaakt
Als u nu op OK klikt en de Component Services-gebruikersinterface sluit, is de fout verdwenen uit het gebeurtenislogboek, wat betekent dat de WSearch COM-component nu de juiste lokale start- en activeringsrechten heeft.
Ik heb dit artikel geschreven als algemene gids om iemand anders te helpen DCOM-fouten in hun gebeurtenislogboek op een vergelijkbare manier op te lossen. Ik maak me nog steeds zorgen waarom Windows nog geen tool heeft om gemakkelijk de juiste machtigingen voor COM-objecten te herstellen voor het geval ze in de war raken.
