Retting for hendelses-ID-feil 10016: DCOM-serveren har ikke lokale aktiveringstillatelser for PCNAME\Brukernavn SID

Nylig, på min Windows 8.1 PC, fra ingensteds, begynte jeg å få feil i hendelsesloggen etter å ha installert oppdateringer på en Patch Tuesday. Feilen var relatert til distribuert COM (DCOM):

De applikasjonsspesifikke tillatelsesinnstillingene gir ikke tillatelse til lokal aktivering for COM Server-applikasjonen med CLSID {9E175B6D-F52A-11D8-B9A5-505054503030} og APPID {9E175B9C-F52A-11D8-B9A5-505054503030} til brukeren PCNAME\Username SID S-1-5-21-81864976-3388411891-1937036257-1001 fra adressen LocalHost (bruker LRPC) som kjører i applikasjonsbeholderen Utilgjengelig SID (S-1-15-2-1430448594-2639229838-973813799-439329657-1197984847-4069167804-1277922394). Denne sikkerhetstillatelsen kan endres ved hjelp av det administrative verktøyet Component Services.

En så komplisert feil kan få uerfarne brukere til å kaste opp i frustrasjon. De er ikke kjent med denne terminologien. I tillegg er det vanskelig å feilsøke DCOM-feil, så jeg ignorerte det først, men hendelsesloggen var full av dem ettersom den skjedde hver time eller så. Fast bestemt på å fikse det, bestemte jeg meg for å undersøke.

For de av dere som ikke vet, er COM Microsofts gamle objektorienterte inter-prosess kommunikasjonsteknologi. En COM-server er en kjørbar fil (EXE eller DLL) som implementerer et sett med COM-objekter. Mange Windows-komponenter er implementert som COM-objekter og følger standard COM-regler for å kommunisere med hverandre. COM-servere er registrert i registeret og har en klasse-ID (CLSID) og en APPID.

Det første trinnet for å feilsøke denne feilen var å finne ut hvilken DCOM-komponent CLSID og APPID var relatert til. Så fyr opp Registerredigering og gå til denne registernøkkelen:

HKEY_CLASSES_ROOT\CLSID\{9E175B6D-F52A-11D8-B9A5-505054503030}

Denne registernøkkelen peker også til samme AppID som feilmeldingen som er {9E175B9C-F52A-11D8-B9A5-505054503030}. Så, neste gå til

HKCR\APPID\{9E175B9C-F52A-11D8-B9A5-505054503030}

Dette fortalte meg at komponenten var WSearch (et Windows Search COM-objekt).

Neste trinn var å tilordne denne CLSID/AppID, de riktige lokale aktiveringstillatelsene som den ønsket – av brukerens sikkerhets-ID (SID) og app-SID. For å gjøre det, tilbyr Windows et Component Services-verktøy som lar brukeren endre start- og aktiveringstillatelser, tilgangstillatelser og konfigurasjonsrettigheter på COM-servere.

Åpne Administrative verktøy -> Komponenttjenester. Utvid Komponenttjenester -> Datamaskin -> Min datamaskin -> DCOM-konfig. Finn 'WSearch' og høyreklikk den -> Egenskaper. Gå til fanen "Sikkerhet".

Da jeg gjorde dette, så jeg at alt var nedtonet (deaktivert) i kategorien Sikkerhet for dette COM-objektet, så jeg måtte gi brukerkontoen min fulle tillatelser i registeret først. Jeg åpnet Regedit igjen og gikk til den samme nøkkelen

HKEY_CLASSES_ROOT\AppID\{9E175B9C-F52A-11D8-B9A5-505054503030}

og endret tillatelsene. Først må du ta eierskap (sjekk 'Erstatt eier på underbeholdere og objekter'), og deretter legge til brukernavnet ditt og gi det Full kontroll. Etterpå kan du endre eierskapet tilbake til den opprinnelige kontoen (NT Service\TrustedInstaller).

Å ta eierskap og gi administratortillatelser er ekstremt enkelt med Winaero's RegOwnershipEx app.

Nå åpnet jeg Component Services (Dcomcnfg.exe) på nytt og gikk til WSearch-egenskaper, fanen Sikkerhet og var nå i stand til å redigere sikkerhetstillatelsene på start- og aktiveringstillatelser, som vises som dette:

Gjennom sikkerhetsgruppen Alle har brukerkontoen min allerede Local Activation-tillatelser, men det vises også 3 andre SID-er som ikke er kjente brukerkontoer eller grupper som ikonet deres indikerer. De er applikasjons-SID-er og refererer til applikasjoner. Hendelsesloggfeilen sa også "... kjører i applikasjonsbeholderen Utilgjengelig SID (S-1-15-2-1430448594-2639229838-973813799-439329657-1197984847-4069167804-1277922394).

Nå ser det ikke ut til at Windows-objektvelger-grensesnittet lar deg legge til applikasjons-SID-er for hovedsikkerhetsobjekter. Så etter å ha klikket Legg til, klikket jeg Avansert... og deretter Finn nå. Dette vil vise alle objektene. Men de fleste av dem var konto-SID-er. Jeg la merke til "ALLE APPLIKASJONSPAKKER" som som navnet tilsier sannsynligvis er en gruppe for alle applikasjonspakker, så jeg valgte den. Klikk OK overalt for å legge den til, og gi den deretter tillatelser for lokal start og lokal aktivering.

Når du nå klikker OK og lukker Component Services UI, er feilen borte fra hendelsesloggen, noe som betyr at WSearch COM-komponenten nå har de riktige lokale lanserings- og aktiveringstillatelsene.

Jeg skrev denne artikkelen som en generell guide for å hjelpe andre med å feilsøke DCOM-feil i hendelsesloggen deres på lignende måte. Jeg er fortsatt bekymret for hvorfor Windows ikke har et verktøy ennå for enkelt å gjenopprette de riktige tillatelsene til COM-objekter i tilfelle de blir rotete.