Nyligen, på min Windows 8.1-dator, 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):
ånga hur man visar dolda spel
De applikationsspecifika behörighetsinställningarna ger inte lokal aktiveringstillstånd för COM-serverapplikationen med CLSID {9E175B6D-F52A-11D8-B9A5-505054503030} och APPID {9E175B9C-F52A-11D8-B9A5-505054503030} till användaren PCNAME Användarnamn SID S-1-5-21-81864976-3388411891-1937036257-1001 från adress LocalHost (använder LRPC) som körs i applikationsbehållaren Ej tillgänglig SID (S-1-15-2-1430448594-2639229838-973813799-439329657-1197984847-4069167804- 1277922394). Denna säkerhetstillstånd kan ändras med hjälp av administrationsverktyget Component Services.
Ett sådant komplicerat fel kan få oerfarna användare att kasta upp sig i frustration. De känner inte till denna terminologi. Dessutom är det svårt 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 det.
Annons
För dig som inte vet är COM Microsofts gamla objektorienterade kommunikationsteknik mellan processerna. En COM-server är en körbar (EXE eller DLL) som implementerar en uppsättning COM-objekt. Många Windows-komponenter implementeras som COM-objekt och följer vanliga 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 detta fel var att ta reda på vilken DCOM-komponent CLSID och APPID var relaterade till. Så starta registreringsredigeraren och gå till den här registernyckeln:
HKEY_CLASSES_ROOT CLSID {9E175B6D-F52A-11D8-B9A5-505054503030}Den här registernyckeln pekar också på samma AppID som felmeddelandet som är {9E175B9C-F52A-11D8-B9A5-505054503030}. Så, gå vidare 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 denna CLSID / AppID, de rätta lokala aktiveringsbehörigheterna som de 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. Expand Component Services -> Computer -> My Computer -> DCOM Config. Leta reda på '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 måste först ge mitt användarkonto full behörighet i registret. 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 (markera 'Ersätt ägare på underbehållare och objekt') och lägg sedan till ditt användarnamn och ge det fullständig kontroll. Därefter kan du ändra ägarskapet till det ursprungliga kontot (NT Service TrustedInstaller).
Att ta ägande och ge administratörsbehörighet är extremt enkelt med Winaero RegOwnershipEx app.
Nu öppnade jag igen Component Services (Dcomcnfg.exe) och gick till WSearch-egenskaper, fliken Säkerhet och kunde nu redigera säkerhetsbehörigheter vid start- och aktiveringsbehörigheter, som visas så här:
Genom säkerhetsgruppen Alla har mitt användarkonto redan lokala aktiviseringsbehörigheter, men det visas också 3 andra SID som inte är kända användarkonton eller grupper som deras ikon indikerar. De är Application SID och hänvisar till Applications. Händelseloggfelet sa också '... körs i applikationsbehållaren Ej tillgänglig SID (S-1-15-2-1430448594-2639229838-973813799-439329657-1197984847-4069167804-1277922394).
Nu verkar inte Windows-objektgränssnittsgränssnittet låta dig lägga till applikations-SID: er för säkerhetsprincipobjekt. Så efter att ha klickat på Lägg till klickade jag på Avancerat ... och sedan på Sök nu. Detta kommer att lista alla objekt. Men de flesta av dem var SID-konton. Jag märkte 'ALLA APPLICATIONSPAKETER' som som namnet antyder är förmodligen en grupp för alla applikationspaket, så jag valde det. Klicka på OK överallt för att lägga till det och ge det sedan lokal start och lokal aktivering.
windows 10 dölja aktivitetsfältet på andra skärmen
Nu när du klickar på OK och stänger användargränssnittet för Component Services, är felet borta 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 allmän guide för att hjälpa någon annan att felsöka DCOM-fel i händelseloggen på ett liknande sätt. Jag är fortfarande orolig varför Windows inte har ett verktyg ännu för att enkelt återställa rätt behörigheter för COM-objekt om de blir trassliga.
