DCOM Ereignis 10016 auf Windows per Script fixen

Das eigentliche Problem ist älter, aber mit Windows 10 leider immer noch nicht beseitigt: die Ereignisanzeige meldet nach jedem Systemstart ein oder mehrere Events mit der ID 10016 und einem seltsamen Fehler aus Richtung DCOM.

Unbenannt

Auch wenn die Meldung keinerlei merkbare Auswirkungen hat, ist es doch merkwürdig, dass hier immer wieder solche Meldungen auftauchen.

Genauso lange wie den Fehler gibt es auch schon verschiedene Anleitungen, wie man ihn beseitigen kann. Kurz gesagt, man setzt ein paar Registry-Berechtigungen und gibt dann in der DCOM Konfiguration dem Nutzer “Lokaler Dienst” die Rechte zum Ausführen.

Das kann man machen, aber spätestens, wenn man die gleiche Meldung auf dutzenden PCs oder mehr hat, ist das nicht mehr praktikabel. Ein Script muss her!

Ich habe einige vorhandene Scripte bzw. Teile daraus genutzt, die sich im Netz auf verschiedenen Seiten finden, da man das Rad ja nicht ständig neu erfinden muss. Zudem ist das Script nicht wirklich “schön”. Es gibt z.B. keine Fehlerbehandlung. Getestet wurde bisher auch nur auf wenigen PCs. Ich garantiere also für nichts.

Nutzung

Das Script in einen Ordner entpacken, dann eine Powershell mit lokalen Adminrechten starten und das Script aus diesem Ordner aufrufen. Dabei aus der Ereignismeldung die dort genannte CLSID und AppID als Parameter dem Script übergeben. Wichtig: die Anführungszeichen bitte nicht vergessen!

Für die Meldung aus dem Screenshot oben sieht der Aufruf dann also so aus:

.\FixDCOM.ps1 „{6B3B8D23-FA8D-40B9-8DBD-B950333E2C52}“ „{4839DDB7-58C2-48F5-8283-E1D1807D0D7D}“

Das Blog bricht das hier um, in der Powershell muss natürlich alles in eine Zeile. Falls mehrere Meldungen mit unterschiedlichen IDs gemeldet werden, ist ein Aufruf für jede neue ID notwendig.

Das Script kann außerdem per GPO als Systemstartscript ausgeführt werden, um eine größere Anzahl von Rechnern zu beackern.

Falls die Powershell die Ausführung des Scripts verweigert, ist beim Heimnutzer noch die Ausführung von Scripten überhaupt zu erlauben. Hierzu ist in der als Admin gestarteten Powershell einmalig dies einzugeben:

Set-ExecutionPolicy -ExecutionPolicy unrestricted

Für die Ausführung per GPO empfiehlt sich, das Script mit den eigenen Zertifikaten zu signieren, so denn eine eigene CA oder öffentliche Codesigning-Zertifikate zur Verfügung stehen.

Ich freue mich über Kommentare zu Erfolg oder Misserfolg.


Download

Das Script steht hier zum Download bereit.

Systemvoraussetzungen

Das Script erwartet Powershell 4.0 oder aktueller.
Es wurde ausschließlich auf Windows 10 entwickelt und getestet.

Vermutlich wird es auf älteren Windows Versionen genauso funktionieren.

Quellenverzeichnis

http://www.leeholmes.com/blog/2010/09/24/adjusting-token-privileges-in-powershell/
https://gallery.technet.microsoft.com/Set-DCOM-ACL-with-650fa48d
https://powertoe.wordpress.com/2010/08/28/controlling-registry-acl-permissions-with-powershell/

Dieser Beitrag wurde unter Allgemein veröffentlicht. Setze ein Lesezeichen auf den Permalink.

21 Antworten zu DCOM Ereignis 10016 auf Windows per Script fixen

  1. Martin schreibt:

    Vielen Dank!

  2. Reinhold schreibt:

    Interessantes Script, das mir die Hoffnung gegeben hat, den DCOM-Fehler loszuwerden. Leider gibt es bei mir mehrfache Fehlermeldungen „Die Eigenschaft „DACL“ wurde für dieses Objekt nicht gefunden“ und weitere Folgemeldungen.
    Bei meinem Notebook löst der DCOM-Fehler nach ca. 3 Min Untätigkeit dauernd den Energie-Sparmodus aus (zumindest findet man danach dann immer das besagte Ereignis), was ziemlich lästig ist (Entsperren des Lock-Screens …). Ich habe Windows 10 Home 1703 mit i5-7200U.

    • Ingo schreibt:

      Du verwechselst da Ursache und Wirkung. Ich schrieb es schon im Artikel selber: die Meldung hat keinerlei merkbare Auswirkungen.

      Das Problem mit den Fehlermeldungen hatte ich auf 1703 noch nicht. Auf 1709 allerdings scheint es hier eine Änderung gegeben zu haben. Der Registry-Zugriff schlägt mit „Der angeforderte Registrierungszugriff ist unzulässig.“ fehl. Muss ich mir die Tage mal in Ruhe anschauen.

  3. scholle1309 schreibt:

    Moin,

    danke für das Script wie auch die Person vor mir, bekomme ich die Fehler.
    Ganz ohne Auswirkungen komme auch ich bei dem DCOM Fehler nicht aus, denn bei jedem DCOM Fehler, startet sich mein PC neu. Auf die Sekunde genau, kann man ja im Ereignismonitor nachschauen =/. Habe bereits alle Scripts im Internet durch, nix hat geholfen…

  4. Michael schreibt:

    Hallöchen, sitze seit ein paar Tagen an dem genau selben Problem, hab schon alles versucht auch dein Script hier, da sagt der mir aber trotz rechte das er den Skript nicht ausführen kann.

  5. Ulf Zimmermann schreibt:

    Guten Tag
    ich habe die 1709 und habe die Meldung nicht erhalten sondern zum Schluss nur ein Done gehe davon aus das es vielleicht doch funktioniert hat.

    PS C:\temp> .\FixDCOM.ps1 “{6B3B8D23-FA8D-40B9-8DBD-B950333E2C52}” “{4839DDB7-58C2-48F5-8283-E1D1807D0D7D}”
    This script will now try to fix the access rights in registry and DCOM.
    Setting Local Service rights for ShellServiceHost
    Done.
    ich hatte gestern wegen dem Fehler die Microsoft Hotline im Chat der schob den Fehler auf defekte Hardware, und schloss den Chat ohne Komentar!!

    Eine Frage zum Verständnis, im Scipt sind diese Einträge
    $LocalAdminSID = “S-1-5-32-544” # local Administrators
    $LocalServiceSID = “S-1-5-19” # Local Service
    kann ich diese erweitern um z.B. da auch hier dieser Fehler (Eintrag in der Ereignissanzeige ) auftritt
    SID: S-1-5-21-2095235210-3255187326-64059177-1001

    Danke

    Geosulf

    • Ingo schreibt:

      Nein, die entsprechenden SIDs, die im Script hinterlegt sind, sind die SIDs der Gruppen, die in den Berechtigungen hinzugefügt werden. Deine genannte SID dürfte damit nichts zu tun haben und vermutlich auch nicht im Zusammenhang mit dem hier im Beitrag behandelten Event auftauchen, oder?

  6. Norbert schreibt:

    Gibt es eine Möglichkeit in den Registry Schlüsseln den ursprünglichen Eigentümer in der Regel “NT Service\TrustedInstaller” wieder zu setzen?

  7. Marcel schreibt:

    Hallo, ich habe das gleiche Problem wie „scholle1309“ und „Reinhold“. Mein PC friert im Zusammenhang mit diesem Fehler ständig ein und stürzt dann ab (Bluescreen). Ich habe Windows 10 Pro 64bit Version 1709 installiert, da das Update auf 1803 leider auch immer fehlschlägt.

    Das Skript löst die Fehler „DACL“ und andere Fehler aus. Gibt es schon neue Möglichkeiten?

    Ich wäre sehr dankbar, für eine Lösung.

  8. thiesy schreibt:

    Hallo, ich habe das Script leider auf „Windows Server 2016“ mit Terminalserver losgelassen. Jetzt treten mehrmals in der Minute bei verschiedenen angemeldeten Benutzern DCOM-Fehler mit der ID 10010 auf. Klartext: „Der Server „{D63B10C5-BB46-4990-A94F-E40B9D520160}“ konnte innerhalb des angegebenen Zeitabschnitts mit DCOM nicht registriert werden.“ Die Anmeldungen der Terminalserver-Session dauern ewig und die Sessions sind alle träge. Erzeugt das Script eine Log-Datei, so dass ich nachvollziehen kann, welche CLSID / APPID ich bearbeitet habe? Danke für eine Info.

    • Ingo schreibt:

      Nein, außer der Bildschirmausgabe gibtves keine weiteren Berichte.

    • Epixx schreibt:

      Habe leider genau das gleiche Problem, gibt es hierzu schon einen Lösungsansatz?
      Habe die Berechtigungen schon soweit wie möglich zurück gestellt, es hat aber noch keine Änderung gebracht.
      Die Windows-Suche hängt sich auch auf, sowie Programme wie Task-Manager und alles was eine UAC erfordert dauern ewig zum starten.

  9. thiesy schreibt:

    OK, die Liste der IDs könnte ich mit etwas Aufwand erstellen. Dann sind es doch nur Änderungen in der Registry, die ich manuell zustückstellen muss, richtig?

    • Ingo schreibt:

      Der Zweck des Scripts ist die Änderung der Berechtigungen in der DCOM Konfiguration. Die Änderungen in der Registry werden nur vorgenommen, damit man dort überhaupt die entsprechenden Punkte bearbeiten kann. Ansonsten hat nämlich nur das System Zugriff. Diese Berechtigungen wieder zu entziehen könnte den originalen Zustand wiederherstellen. Schau an einem zweiten Server, wie die Berechtigungen der einzelnen Punkte exakt gesetzt sind. Die genannte ID ist der Runtime Broker.

  10. Carsten schreibt:

    Hi,
    leider habe ich vor dem Starten des Scripts auf einem Windows 2016 Server den Blog nicht zu Ende gelesen und habe jetzt die gleichen Symptome mit dem Ereignis „Der Server „{D63B10C5-BB46-4990-A94F-E40B9D520160}“ konnte innerhalb des angegebenen Zeitabschnitts mit DCOM nicht registriert werden.“ Komme einfach nicht weiter. Gibt es schon eine Lösung?
    Danke

  11. Onkl schreibt:

    Hallo, der Scriptdownload funktioniert nicht mehr.

    • Ingo schreibt:

      Ich hatte den letztens rausgenommen, allerdings den Beitrag bisher noch nicht aktualisiert.
      Die Problematik als solche wird von Microsoft mittlerweile ja sehr deutlich mit einem KB Artikel als „rein optisch, keinerlei Einschränkungen“ bewertet. Auf der anderen Seite gab es allerdings bei der Beseitigung der Meldungen hin und wieder mal teils massive Probleme. Es steht in keinem Verhältnis, für die Beseitigung einer völlig harmlosen Meldung Risiken einzugehen. Insofern habe ich das Script letztens offline genommen. Wer die Meldungen hat, möge damit einfach leben.

  12. Max schreibt:

    Guten Abend ist das Skript den noch aktuell?

Hinterlasse einen Kommentar

Diese Seite verwendet Akismet, um Spam zu reduzieren. Erfahre, wie deine Kommentardaten verarbeitet werden..