For nylig begyndte jeg på min Windows 8.1-pc ud af ingenting at få fejl i hændelsesloggen efter installation af opdateringer på en patch-tirsdag. Fejlen var relateret til Distribueret COM (DCOM):
windows 10 bsod memory_management
De applikationsspecifikke tilladelsesindstillinger giver ikke lokal aktiveringstilladelse til COM-serverapplikationen med CLSID {9E175B6D-F52A-11D8-B9A5-505054503030} og APPID {9E175B9C-F52A-11D8-B9A5-505054503030} til brugeren PCNAME Brugernavn SID S-1-5-21-81864976-3388411891-1937036257-1001 fra adresse LocalHost (ved hjælp af LRPC), der kører i applikationsbeholderen Ikke tilgængelig SID (S-1-15-2-1430448594-2639229838-973813799-439329657-1197984847-4069167804- 1277922394). Denne sikkerhedstilladelse kan ændres ved hjælp af administrationsværktøjet Component Services.
En sådan kompliceret fejl kan få uerfarne brugere til at kaste op i frustration. De kender ikke denne terminologi. Plus, fejlfinding af DCOM-fejl er en smerte, så jeg ignorerede det først, men hændelsesloggen var fuld af dem, da det skete hver time eller deromkring. Fast besluttet på at ordne det besluttede jeg at undersøge det.
Annoncering
For dem af jer, der ikke ved det, er COM Microsofts gamle objektorienterede inter-proces kommunikationsteknologi. En COM-server er en eksekverbar (EXE eller DLL), der implementerer et sæt COM-objekter. Mange Windows-komponenter er implementeret som COM-objekter og følger standard COM-regler for at kommunikere med hinanden. COM-servere er registreret i registreringsdatabasen og har et klasse-id (CLSID) og en APPID.
Det første trin til fejlfinding af denne fejl var at finde ud af, hvilken DCOM-komponent CLSID og APPID var relateret til. Så affyr registreringseditoren, og gå til denne registreringsnøgle:
HKEY_CLASSES_ROOT CLSID {9E175B6D-F52A-11D8-B9A5-505054503030}Denne registreringsnøgle peger også på den samme AppID som fejlmeddelelsen, der er {9E175B9C-F52A-11D8-B9A5-505054503030}. Så gå videre til
HKCR APPID {9E175B9C-F52A-11D8-B9A5-505054503030}Dette fortalte mig, at komponenten var WSearch (et Windows Search COM-objekt).
Det næste trin var at tildele denne CLSID / AppID, de korrekte lokale aktiveringstilladelser, som den ønskede - af min brugersikkerheds-id (SID) og appens SID. For at gøre dette leverer Windows et Component Services-værktøj, der lader brugeren ændre start- og aktiveringstilladelser, adgangstilladelser og konfigurationstilladelser på COM-servere.
Åbn administrative værktøjer -> Komponenttjenester. Udvid komponenttjenester -> Computer -> Min computer -> DCOM Config. Find 'WSearch' og højreklik på det -> Egenskaber. Gå til fanen 'Sikkerhed'.
Da jeg gjorde dette, så jeg, at alt var nedtonet (deaktiveret) på fanen Sikkerhed for dette COM-objekt, så jeg havde først brug for at give min brugerkonto fuld tilladelse i registreringsdatabasen. Jeg åbnede Regedit igen og gik til den samme nøgle
HKEY_CLASSES_ROOT AppID {9E175B9C-F52A-11D8-B9A5-505054503030}og ændrede tilladelserne. Først skal du overtage ejerskabet (afkryds 'Udskift ejer på undercontainere og objekter') og derefter tilføje dit brugernavn og give det fuld kontrol. Derefter kan du ændre ejerskabet tilbage til den oprindelige konto (NT Service TrustedInstaller).
At tage ejerskab og give admin tilladelser er ekstremt let med Winaero's RegOwnershipEx app.
Nu genåbnede jeg Component Services (Dcomcnfg.exe) og gik til WSearch egenskaber, fanen Sikkerhed og var nu i stand til at redigere sikkerhedstilladelser ved start- og aktiveringstilladelser, som vises som denne:
Gennem sikkerhedsgruppen Alle har min brugerkonto allerede lokale aktiveringstilladelser, men der vises også 3 andre SID'er, som ikke er kendte brugerkonti eller grupper, som deres ikon indikerer. De er Application SID'er og henviser til Applications. Begivenhedslogfejlen sagde også '... kører i applikationsbeholderen Utilgængelig SID (S-1-15-2-1430448594-2639229838-973813799-439329657-1197984847-4069167804-1277922394).
Nu ser det ud til, at Windows-objektvælgergrænsefladen ikke giver dig mulighed for at tilføje applikations-SID'er til sikkerhedshovedobjekter. Så efter at have klikket på Tilføj, klikkede jeg på Avanceret ... og derefter Find nu. Dette viser alle objekterne. Men de fleste af dem var konto-SID'er. Jeg bemærkede 'ALLE ANVENDELSESPAKKER', som som navnet antyder sandsynligvis er en gruppe for alle applikationspakker, så jeg valgte den. Klik på OK overalt for at tilføje det, og giv det derefter tilladelser til lokal start og lokal aktivering.
hvordan man sørger for, at chauffører er opdaterede
Nu ved at klikke på OK og lukke Component Services UI, er fejlen væk fra hændelsesloggen, hvilket betyder, at WSearch COM-komponenten nu har de korrekte lokale start- og aktiveringstilladelser.
Jeg skrev denne artikel som en generel guide til at hjælpe andre med at foretage fejlfinding af DCOM-fejl i deres hændelseslog på en lignende måde. Jeg er stadig bekymret over, hvorfor Windows endnu ikke har et værktøj til nemt at gendanne de korrekte tilladelser til COM-objekter, hvis de bliver rodet.
