Fix för händelse-ID-fel 10016: DCOM-servern har inte lokala aktiveringsbehörigheter för PCNAMEUsername 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 applikationsspecifika behörighetsinställningarna ger inte lokal aktiveringsbehörighet för COM-serverapplikationen med CLSID {9E175B6D-F52A-11D8-B9A5-505054503030} och APPID {9E175B9C-F52A-11D8-B9A4-50505-användarnamnet PCU5-50505-användarnamnet PCU5050}s S-1-5-21-81864976-3388411891-1937036257-1001 Från adress localhost (med LRPC) som körs i applikationscontainern Otillgänglig SID (S-15-15-14304448544-26392983838-97381379999999999999999999999999999999999999999999999999999999999999999999999999997 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.

Annons

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:

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

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

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 ServiceTrustedInstaller).

Att ta ägarskap och ge administratörsbehörigheter är extremt enkelt med Winaeros RegOwnershipEx-app.

snapchat-filter som fungerar på hundar

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

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 programbehållaren Ej tillgängligt SID (S-1-15-2-1430448594-2639229838-973813799-439329657-1197984847-4069167804-129479).

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 på 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.

exempel på familjeåterföreningsprogram

Stöd oss

Winaero är mycket beroende av ditt stöd. Du kan hjälpa webbplatsen att fortsätta ge dig intressant och användbart innehåll och programvara genom att använda dessa alternativ:

Om du gillar den här artikeln, vänligen dela den med knapparna nedan. Det kommer inte att ta mycket från dig, men det kommer att hjälpa oss att växa. Tack för ditt stöd!

Annons

Författare:Gaurav Kale

Gaurav är en mjukvaruentusiast från Indien och Classic Shell-testare och UX-konsult. Han började med Windows 95 och är bra på att testa mjukvaran. Han är övertygad om att användarupplevelsen är lika viktig som mjukvarans kodkvalitet och arkitektur för att mjukvara ska bli framgångsrik. Visa alla inlägg av Gaurav Kale