Fix för händelse-ID-fel 10016: DCOM-servern har inte lokala aktiveringsbehörigheter för PCNAME\Username SID

Nyligen, på min Windows 8.1 PC, från ingenstans, började jag få fel i händelseloggen efter att ha installerat uppdateringar på en patch tisdag. Felet var relaterat till distribuerad COM (DCOM):

De programspecifika behörighetsinställningarna ger inte lokal aktiveringsbehörighet för COM Server-applikationen med CLSID {9E175B6D-F52A-11D8-B9A5-505054503030} och APPID {9E175B9C-F52A-11D8-B9A5-505054503030} till användaren PCNAME\Username SID S-1-5-21-81864976-3388411891-1937036257-1001 från adressen LocalHost (Använder LRPC) som körs i applikationsbehållaren Ej tillgängligt SID (S-1-15-2-1430448594-2639229838-973813799-439329657-1197984847-4069167804-1277922394). Denna säkerhetsbehörighet kan ändras med hjälp av det administrativa verktyget Component Services.

Ett så komplicerat fel kan få oerfarna användare att spy av frustration. De är obekanta med denna terminologi. Dessutom är det jobbigt att felsöka DCOM-fel så jag ignorerade det först men händelseloggen var full av dem eftersom det inträffade varje timme eller så. Fast besluten att fixa det bestämde jag mig för att undersöka.

För er som inte vet är COM Microsofts gamla objektorienterade interprocesskommunikationsteknologi. En COM-server är en körbar fil (EXE eller DLL) som implementerar en uppsättning COM-objekt. Många Windows-komponenter är implementerade som COM-objekt och följer standard COM-regler för att kommunicera med varandra. COM-servrar är registrerade i registret och har ett klass-ID (CLSID) och ett APPID.

Det första steget för att felsöka det här felet var att ta reda på vilken DCOM-komponent som CLSID och APPID var relaterade till. Så starta registerredigeraren och gå till denna registernyckel:

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

Denna registernyckel pekar också på samma AppID som felmeddelandet som är {9E175B9C-F52A-11D8-B9A5-505054503030}. Så, nästa gå till

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

Detta berättade för mig att komponenten var WSearch (ett Windows Search COM-objekt).

Nästa steg var att tilldela detta CLSID/AppID, de korrekta lokala aktiveringsbehörigheterna som den ville ha – av mitt användarsäkerhets-ID (SID) och app-SID. För att göra det tillhandahåller Windows ett Component Services-verktyg som låter användaren ändra start- och aktiveringsbehörigheter, åtkomstbehörigheter och konfigurationsbehörigheter på COM-servrar.

Öppna Administrativa verktyg -> Komponenttjänster. Expandera Komponenttjänster -> Dator -> Den här datorn -> DCOM Config. Leta upp 'WSearch' och högerklicka på den -> Egenskaper. Gå till fliken "Säkerhet".

När jag gjorde detta såg jag att allt var nedtonat (inaktiverat) på fliken Säkerhet för detta COM-objekt så jag behövde ge mitt användarkonto fullständiga behörigheter i registret först. Jag öppnade Regedit igen och gick till samma nyckel

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

och ändrade behörigheterna. Först måste du ta äganderätten (kryssa för "Ersätt ägare på underbehållare och objekt") och sedan lägga till ditt användarnamn och ge det Full kontroll. Efteråt kan du ändra äganderätten tillbaka till det ursprungliga kontot (NT Service\TrustedInstaller).

Att ta ägarskap och ge administratörsbehörigheter är extremt enkelt med Winaero's RegOwnershipEx app.

Nu öppnade jag igen Component Services (Dcomcnfg.exe) och gick till WSearch-egenskaper, fliken Säkerhet och kunde nu redigera säkerhetsbehörigheterna för start- och aktiveringsbehörigheter, som visas som detta:

Genom säkerhetsgruppen Alla har mitt användarkonto redan lokal aktiveringsbehörighet, men det visas även 3 andra SID: n som inte är kända användarkonton eller grupper som deras ikon indikerar. De är Application SIDs och hänvisar till Applications. Händelseloggfelet sa också "... körs i applikationsbehållaren Ej tillgängligt SID (S-1-15-2-1430448594-2639229838-973813799-439329657-1197984847-4069167804-1277922394).

Nu verkar inte Windows-objektväljarens användargränssnitt låta dig lägga till applikations-SID: n för huvudsäkerhetsobjekt. Så efter att ha klickat på Lägg till klickade jag på Avancerat... och sedan Hitta nu. Detta kommer att lista alla objekt. Men de flesta av dem var konto-SID. Jag lade märke till "ALLA APPLIKATIONSPAKET" som som namnet antyder förmodligen är en grupp för alla applikationspaket, så jag valde den. Klicka på OK överallt för att lägga till den och ge den sedan behörighet för lokal start och lokal aktivering.

När du nu klickar på OK och stänger Component Services UI, försvinner felet från händelseloggen, vilket innebär att WSearch COM-komponenten nu har rätt lokala start- och aktiveringsbehörigheter.

Jag skrev den här artikeln som en allmän guide för att hjälpa någon annan att felsöka DCOM-fel i deras händelselogg på liknande sätt. Jag är fortfarande oroad över varför Windows inte har ett verktyg ännu för att enkelt återställa de korrekta behörigheterna till COM-objekt om de skulle bli trassliga.