Remediere pentru eroarea ID eveniment 10016: serverul DCOM nu are permisiuni de activare locală pentru PCNAME\Username SID
Recent, pe PC-ul meu cu Windows 8.1, de nicăieri, am început să primesc erori în jurnalul de evenimente după ce am instalat actualizări într-un Patch Tuesday. Eroarea a fost legată de COM distribuit (DCOM):
Setările de permisiuni specifice aplicației nu acordă permisiunea de activare locală pentru aplicația COM Server cu CLSID {9E175B6D-F52A-11D8-B9A5-505054503030} și APPID {9E175B9C-F52A-11D8-B9A5-505054503030} către utilizatorul PCNAME\Username SID S-1-5-21-81864976-3388411891-1937036257-1001 de la adresa LocalHost (folosind LRPC) care rulează în containerul aplicației SID indisponibil (S-1-15-2-1430448594-2639229838-973813799-439329657-1197984847-4069167804-1277922394). Această permisiune de securitate poate fi modificată utilizând instrumentul administrativ Component Services.
O astfel de eroare complicată ar putea face utilizatorii fără experiență să vomite de frustrare. Ei nu sunt familiarizați cu această terminologie. În plus, depanarea erorilor DCOM este o durere, așa că am ignorat-o la început, dar jurnalul de evenimente era plin de ele, deoarece au avut loc la fiecare oră sau cam asa ceva. Hotărât să o repar, am decis să investighez.
Pentru cei dintre voi care nu știu, COM este vechea tehnologie de comunicare inter-procese orientată pe obiecte a Microsoft. Un server COM este un executabil (EXE sau DLL) care implementează un set de obiecte COM. Multe componente Windows sunt implementate ca obiecte COM și urmează reguli COM standard pentru a comunica între ele. Serverele COM sunt înregistrate în Registry și au un ID de clasă (CLSID) și un APPID.
Primul pas pentru a depana această eroare a fost aflarea de ce componentă DCOM au fost legate CLSID și APPID. Deci, porniți Editorul de Registry și mergeți la această cheie de Registry:
HKEY_CLASSES_ROOT\CLSID\{9E175B6D-F52A-11D8-B9A5-505054503030}
Această cheie de registry indică, de asemenea, același AppID ca și mesajul de eroare, care este {9E175B9C-F52A-11D8-B9A5-505054503030}. Așadar, următorul acces la
HKCR\APPID\{9E175B9C-F52A-11D8-B9A5-505054503030}
Acest lucru mi-a spus că componenta a fost WSearch (un obiect Windows Search COM).
Următorul pas a fost să atribui acestui CLSID/AppID permisiunile corecte de activare locală pe care le dorea - ale ID-ului meu de securitate (SID) și SID-ului aplicației. Pentru a face acest lucru, Windows oferă un instrument de servicii de componente care permite utilizatorului să modifice permisiunile de lansare și activare, permisiunile de acces și permisiunile de configurare pe serverele COM.
Deschideți Instrumente administrative -> Servicii componente. Extindeți Component Services -> Computer -> My Computer -> DCOM Config. Găsiți „WSearch” și faceți clic dreapta -> Proprietăți. Accesați fila „Securitate”.
După ce am făcut acest lucru, am văzut că totul era dezactivat (dezactivat) în fila Securitate pentru acest obiect COM, așa că trebuia să acord mai întâi permisiuni complete contului meu de utilizator în Registry. Am deschis Regedit din nou și am trecut la aceeași cheie
HKEY_CLASSES_ROOT\AppID\{9E175B9C-F52A-11D8-B9A5-505054503030}
și a schimbat permisiunile. Mai întâi trebuie să preia proprietatea (bifați „Înlocuiți proprietarul pe subcontainere și obiecte”), apoi adăugați numele de utilizator și acordați-i control total. Ulterior, puteți schimba proprietatea înapoi la contul original (NT Service\TrustedInstaller).
Preluarea dreptului de proprietate și acordarea permisiunilor de administrator este extrem de ușor cu Winaero RegOwnershipEx aplicația.
Acum am redeschis Serviciile componente (Dcomcnfg.exe) și am mers la proprietățile WSearch, fila Securitate și a putut acum să editeze permisiunile de securitate privind permisiunile de lansare și activare, care sunt afișate ca acest:
Prin grupul de securitate Toată lumea, contul meu de utilizator are deja permisiuni de activare locală, dar sunt afișate și alte 3 SID-uri care nu sunt conturi de utilizator sau grupuri cunoscute, așa cum indică pictograma lor. Sunt SID-uri de aplicație și se referă la Aplicații. Eroarea jurnalului de evenimente a mai spus „... rulează în containerul aplicației SID indisponibil (S-1-15-2-1430448594-2639229838-973813799-439329657-1197984847-4069167804-1277922394).
Acum, interfața de utilizare a selectorului de obiecte Windows nu pare să vă permită să adăugați SID-uri de aplicație pentru obiectele principale de securitate. Deci, după ce am făcut clic pe Adăugare, am făcut clic pe Avansat... și apoi Găsește acum. Aceasta va lista toate obiectele. Dar majoritatea erau SID-uri de cont. Am observat „TOATE PACHELE DE APLICARE” care, după cum sugerează și numele, este probabil un grup pentru toate pachetele de aplicații, așa că l-am selectat. Faceți clic pe OK peste tot pentru a-l adăuga și apoi acordați-i permisiunile de Lansare locală și Activare locală.
Acum, după ce faceți clic pe OK și închideți UI Component Services, eroarea a dispărut din Jurnalul de evenimente, ceea ce înseamnă că componenta WSearch COM are acum permisiunile de lansare și activare locale corecte.
Am scris acest articol ca ghid general pentru a ajuta pe oricine altcineva să depaneze erorile DCOM din jurnalul de evenimente într-un mod similar. Sunt încă îngrijorat de ce Windows nu are încă un instrument pentru a restabili cu ușurință permisiunile corecte pentru obiectele COM în cazul în care acestea se încurcă.
