Наскоро на моя компютър с Windows 8.1, от нищото, започнах да получавам грешки в дневника на събитията, след като инсталирах актуализации в кръпка във вторник. Грешката е свързана с разпределен COM (DCOM):
как да продавам игра на пара
Настройките за разрешения, специфични за приложението, не дават разрешение за локално активиране на приложението COM сървър с CLSID {9E175B6D-F52A-11D8-B9A5-505054503030} и APPID {9E175B9C-F52A-11D8-B9A5-505054503030} на потребителя PCNAME Потребителско име 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 Search).
Следващата стъпка беше да се присвоят на този CLSID / AppID правилните разрешения за локално активиране, които той искаше - на моя потребителски идентификационен номер за сигурност (SID) и SID на приложението. За целта Windows предоставя инструмент Component Services, който позволява на потребителя да променя разрешенията за стартиране и активиране, разрешения за достъп и разрешения за конфигуриране на COM сървъри.
Отворете Административни инструменти -> Услуги за компоненти. Разгънете Компонентни услуги -> Компютър -> Моят компютър -> DCOM Config. Намерете „WSearch“ и щракнете с десния бутон върху него -> Properties. Отидете в раздела „Сигурност“.
При това видях, че всичко е било сиво (деактивирано) в раздела „Защита“ за този COM обект, така че първо трябваше да дам на потребителския си акаунт пълни разрешения в системния регистър. Отворих Regedit отново и отидох до същия ключ
HKEY_CLASSES_ROOT AppID {9E175B9C-F52A-11D8-B9A5-505054503030}и смениха разрешенията. Първо трябва да вземете собствеността (поставете отметка „Замяна на собственика на подконтейнери и обекти“) и след това добавете потребителското си име и му дайте пълен контрол След това можете да промените собствеността обратно към първоначалния акаунт (NT Service TrustedInstaller).
Поемането на собствеността и даването на администраторски разрешения е изключително лесно с Winaero's RegOwnershipEx ап.
Сега отворих отново услугите за компоненти (Dcomcnfg.exe) и отидох до свойствата на WSearch, раздел „Защита“ и вече можех да редактирам разрешенията за защита при разрешения за стартиране и активиране, които са показани по следния начин:
Чрез групата за сигурност Всеки, моят потребителски акаунт вече има разрешения за локално активиране, но също така са показани 3 други SID, които не са известни потребителски акаунти или групи, както показва иконата им. Те са SID на Application и се отнасят до Applications. Грешката в дневника на събитията също казва „... работи в контейнера за приложения Недостъпен SID (S-1-15-2-1430448594-2639229838-973813799-439329657-1197984847-4069167804-1277922394).
Сега потребителският интерфейс за избор на обекти на Windows изглежда не ви позволява да добавяте SID на приложението за основните обекти на защитата. Така че, след като щракнах върху Добавяне, щракнах върху Разширени ... и след това Намери сега. Това ще изброи всички обекти. Но повечето от тях бяха SID за акаунти. Забелязах „ВСИЧКИ ПАКЕТИ ЗА ПРИЛОЖЕНИЕ“, което, както подсказва името, вероятно е група за всички пакети за приложения, затова го избрах. Щракнете ОК навсякъде, за да го добавите и след това му дайте разрешения за локално стартиране и локално активиране
ако тогава изявления в google листове
След като щракнете върху OK и затворете потребителския интерфейс на Component Services, грешката е изчезнала от дневника на събитията, което означава, че компонентът WSearch COM вече има правилните разрешения за локално стартиране и активиране.
Написах тази статия като общо ръководство, за да помогна на някой друг да отстрани грешките на DCOM в своя регистър на събития по подобен начин. Все още съм загрижен защо Windows все още няма инструмент за лесно възстановяване на правилните разрешения за COM обекти, в случай че се объркат.
