Поправка за грешка с идентификатор на събитие 10016: DCOM сървърът няма разрешения за локално активиране за PCNAME\Username SID

Наскоро на моя компютър с Windows 8.1 от нищото започнах да получавам грешки в дневника на събитията, след като инсталирах актуализации във вторник за корекция. Грешката беше свързана с разпределен COM (DCOM):

Настройките за разрешение за специфични за приложението не дават разрешение за локално активиране за приложението COM сървър с CLSID {9E175B6D-F52A-11D8-B9A5-505054503030} и APPID {9E175B9C-F52A-11D8-B9A5-505054503030} към потребителя PCNAME\Username SID S-1-5-21-81864976-3388411891-1937036257-1001 от адрес LocalHost (Използвайки LRPC), работещ в контейнера на приложението Недостъпен SID (S-1-15-2-1430448594-2639229838-973813799-439329657-1197984847-4069167804-1277922394). Това разрешение за сигурност може да бъде променено с помощта на административния инструмент на Component Services.

Такава сложна грешка може да накара неопитни потребители да повърнат от разочарование. Те не са запознати с тази терминология. Плюс това, отстраняването на грешки в DCOM е мъка, така че в началото го игнорирах, но дневникът на събитията беше пълен с тях, тъй като се случваше на всеки час или нещо повече. Решен да го поправя, реших да проуча.

За тези от вас, които не знаят, COM е старата обектно-ориентирана междупроцесна комуникационна технология на Microsoft. COM сървърът е изпълним файл (EXE или DLL), който реализира набор от COM обекти. Много компоненти на Windows са имплементирани като COM обекти и следват стандартните COM правила, за да комуникират един с друг. COM сървърите са регистрирани в регистъра и имат Class ID (CLSID) и APPID.

Първата стъпка за отстраняване на тази грешка беше да се установи с кой DCOM компонент са свързани CLSID и APPID. Затова стартирайте редактора на системния регистър и отидете на този ключ на системния регистър:

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

Този ключ на системния регистър също сочи към същия AppID като съобщението за грешка, което е {9E175B9C-F52A-11D8-B9A5-505054503030}. Така че, следващо отидете на

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

Това ми каза, че компонентът е WSearch (COM обект за търсене на Windows).

Следващата стъпка беше да присвоя на този CLSID/AppID правилните разрешения за локално активиране, които иска - на моя потребителски идентификатор за сигурност (SID) и SID на приложението. За да направи това, Windows предоставя инструмент за компонентни услуги, който позволява на потребителя да променя разрешенията за стартиране и активиране, разрешенията за достъп и разрешенията за конфигурация на COM сървърите.

Отворете Административни инструменти -> Компонентни услуги. Разгънете Компонентни услуги -> Компютър -> Моят компютър -> DCOM Config. Намерете 'WSearch' и щракнете с десния бутон върху него -> Свойства. Отидете в раздела "Сигурност".

След като направих това, видях, че всичко е затъмнено (деактивирано) в раздела Защита за този COM обект, така че първо трябваше да дам на потребителския си акаунт пълни разрешения в системния регистър. Отново отворих Regedit и отидох на същия ключ

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

и промени разрешенията. Първо трябва да поемете собствеността (отметнете „Замяна на собственика на подконтейнери и обекти“), след което да добавите потребителското си име и да му дадете пълен контрол. След това можете да промените собствеността обратно към оригиналния акаунт (NT Service\TrustedInstaller).

Поемането на собственост и даване на администраторски разрешения е изключително лесно с Winaero's RegOwnershipEx ап.

Сега отворих отново компонентните услуги (Dcomcnfg.exe) и отидох в свойствата на WSearch, раздела за сигурност и вече можеше да редактира разрешенията за сигурност при разрешенията за стартиране и активиране, които са показани като това:

Чрез групата за сигурност Всеки, моят потребителски акаунт вече има разрешения за локално активиране, но са показани и 3 други SID, които не са известни потребителски акаунти или групи, както показва тяхната икона. Те са SID на приложения и се отнасят до приложения. Грешката в регистъра на събитията също казва "... работи в контейнера на приложението Недостъпен SID (S-1-15-2-1430448594-2639229838-973813799-439329657-1197984847-4069167804-1277922394).

Сега изглежда, че потребителският интерфейс на Windows за избор на обекти не ви позволява да добавяте SID на приложения за главни обекти за защита. Така че след като щракнах Добавяне, щракнах Разширени... и след това Намери сега. Това ще изброи всички обекти. Но повечето от тях бяха SID на акаунти. Забелязах „ВСИЧКИ ПАКЕТИ НА ПРИЛОЖЕНИЕТО“, което, както подсказва името, вероятно е група за всички пакети на приложения, затова го избрах. Щракнете върху OK навсякъде, за да го добавите и след това му дайте разрешения за локално стартиране и локално активиране.

Сега, след като щракнете върху OK и затворите потребителския интерфейс на Component Services, грешката е изчезнала от дневника на събитията, което означава, че компонентът WSearch COM вече има правилните локални разрешения за стартиране и активиране.

Написах тази статия като общо ръководство, за да помогна на всеки друг да отстранява грешки в DCOM в своя регистър на събитията по подобен начин. Все още съм загрижен защо Windows все още няма инструмент за лесно възстановяване на правилните разрешения за COM обекти, в случай че се объркат.