Rette til hændelses-id-fejl 10016: DCOM-serveren har ikke lokale aktiveringstilladelser for PCNAME\Brugernavn SID
For nylig, på min Windows 8.1 pc, ud af ingenting, begyndte jeg at få fejl i hændelsesloggen efter installation af opdateringer på en patch tirsdag. Fejlen var relateret til distribueret COM (DCOM):
De applikationsspecifikke tilladelsesindstillinger giver ikke lokal aktiveringstilladelse til COM Server-applikationen 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 adressen LocalHost (bruger LRPC), der kører i applikationsbeholderen Utilgængelig SID (S-1-15-2-1430448594-2639229838-973813799-439329657-1197984847-4069167804-1277922394). Denne sikkerhedstilladelse kan ændres ved hjælp af det administrative værktøj Component Services.
Sådan en kompliceret fejl kan få uerfarne brugere til at kaste op i frustration. De er ikke bekendt med denne terminologi. Plus, fejlfinding af DCOM-fejl er en smerte, så jeg ignorerede det i starten, men hændelsesloggen var fuld af dem, da den opstod hver time eller deromkring. Fast besluttet på at rette op på det, besluttede jeg at undersøge det.
Reklame
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 et APPID.
Det første skridt til at fejlfinde denne fejl var at finde ud af, hvilken DCOM-komponent CLSID'et og APPID'et var relateret til. Så start registreringseditoren og gå til denne registreringsnøgle:
HKEY_CLASSES_ROOT\CLSID\{9E175B6D-F52A-11D8-B9A5-505054503030}
Denne registreringsnøgle peger også på det samme AppID som fejlmeddelelsen, som er {9E175B9C-F52A-11D8-B9A5-505054503030}. Så gå næste gang til
HKCR\APPID\{9E175B9C-F52A-11D8-B9A5-505054503030}
Dette fortalte mig, at komponenten var WSearch (et Windows Search COM-objekt).
Næste trin var at tildele denne CLSID/AppID de korrekte lokale aktiveringstilladelser, som den ønskede - af mit brugersikkerheds-ID (SID) og app-SID. For at gøre det tilbyder Windows et Component Services-værktøj, som lader brugeren ændre start- og aktiveringstilladelser, adgangstilladelser og konfigurationstilladelser på COM-servere.
Åbn Administrative værktøjer -> Komponenttjenester. Udvid Component Services -> Computer -> My 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 var nødt til at give min brugerkonto fulde tilladelser i registreringsdatabasen først. 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 tage ejerskab (tjek 'Erstat ejer på underbeholdere og objekter'), og derefter tilføje dit brugernavn og give det fuld kontrol. Bagefter kan du ændre ejerskabet tilbage til den oprindelige konto (NT Service\TrustedInstaller).
At tage ejerskab og give administratortilladelser er ekstremt nemt 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 sikkerhedstilladelserne på start- og aktiveringstilladelser, som vises som det her:
Gennem sikkerhedsgruppen Alle har min brugerkonto allerede lokale aktiveringstilladelser, men der er også vist 3 andre SID'er, som ikke er kendte brugerkonti eller grupper, som deres ikon angiver. De er applikations-SID'er og henviser til applikationer. Hændelseslogfejlen sagde også "... kører i applikationsbeholderen Utilgængelig SID (S-1-15-2-1430448594-2639229838-973813799-439329657-1197984847-4069167804-1277922394).
Nu ser det ikke ud til, at Windows objektvælger-brugergrænsefladen giver dig mulighed for at tilføje applikations-SID'er til hovedsikkerhedsobjekter. Så efter at have klikket på Tilføj klikkede jeg på Avanceret... og derefter Find nu. Dette vil vise alle objekterne. Men de fleste af dem var konto-SID'er. Jeg lagde mærke til "ALL APPLICATION PACKAGES", 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.
Når du nu klikker på OK og lukker Component Services UI, er fejlen væk fra hændelsesloggen, hvilket betyder, at WSearch COM-komponenten nu har de korrekte lokale lancerings- og aktiveringstilladelser.
Jeg skrev denne artikel som en generel guide til at hjælpe andre med at fejlfinde 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.
