DCOM Server konnte nicht registriert werden

Question

Ich erhalte folgende Fehlermeldung

Quelle: DCOM
Ereignis_ID: 10010

"Der Server {6FC4FDAE-96C8-11D3-9F9C-005004053207} hat sich bei DCOM nicht innerhalb der erforderlichen Zeitspanne registriert."

Dies ist für eine bestimmte Exe, die, wenn sie als lokales System ausgeführt wird, gut funktioniert, aber wenn sie unter einem nicht eingebauten Administrator ausgeführt wird, schlägt sie fehl. Ich brauche die Exe, um unter dem nicht eingebauten Administrator zu laufen.

Zurzeit habe ich dieses Problem auf einem Win 2k3 Rechner mit Citrix.

Allerdings hatte ich dieses Problem auch schon bei einem XP-Rechner.

Gibt es Tipps zur Lösung des Problems?

Answer 1

Da ich den Zusammenhang nicht ganz verstehe... Hier sind ein paar Tipps, die Ihnen helfen, Probleme zu lösen... Es ist hilfreich, sowohl auf dem Ursprungs- als auch auf dem Zielcomputer Administratorrechte zu haben....(zumindest für die Konfiguration und Überprüfung)

DCOM kann verwirrend sein. Beim Umgang mit DCOM über Rechnergrenzen hinweg liegt das Problem höchstwahrscheinlich in der Sicherheit durch widersprüchliche und/oder fehlende Credentials, Firewalls und DCOM-Einstellungen für den lokalen Rechner und die Anwendung. Was das 80/20-Prinzip anbelangt, so gibt es einige einfache Regeln, die Ihnen helfen sollen, den Überblick zu behalten.

Erstens: Sicherheit sichtbar machen: Starten Sie SecPol.MSC auf Ihrem Ausgangsrechner, suchen Sie Local Policies/Audit Policy und schalten Sie die Überwachung für jeden Ereignistyp ein. Sie tun gut daran, dies auch auf dem Zielrechner zu tun.

Starten Sie auch die DCOM-Ereignisprotokollierung. Folgen Sie diesen Anweisungen http://support.microsoft.com/kb/892500

Ändern Sie zweitens eine Standard-Arbeitsgruppeneinstellung, die dafür bekannt ist, DCOM zu stören: Stellen Sie sicher, dass die einfache Dateifreigabe (auch bekannt als reine Gastauthentifizierung) sowohl auf dem Ausgangs- als auch auf dem Zielcomputer deaktiviert ist. Wenn beide in einer Domäne sind, ist sie wahrscheinlich deaktiviert. Andernfalls... secpol.msc \security Einstellungen \security Optionen \network Zugang: Gemeinsame Nutzung als Sicherheitsmodell für lokale Konten (auf klassisch eingestellt)

Drittens: Verschaffen Sie sich einen Überblick über die erforderliche Sicherheit...

Wenn beide Rechner in verschiedenen Domänen sind oder einer (oder beide) in einer Arbeitsgruppe sind, verstehen Sie die erforderliche gemeinsame Sicherheit, d.h. die Anmeldeinformationen müssen auf beiden Rechnern gemeinsam oder synchronisiert sein. Das heißt, für die Anmeldung, die den Prozess auf dem Ursprungscomputer ausführt, müssen auf dem Zielcomputer identische Anmeldedaten vorhanden sein. Wenn beide in derselben Domäne sind, müssen Sie sich keine Sorgen machen, da die domänenbasierten Anmeldeinformationen für den einen Rechner die gleichen sind wie für den anderen.

Viertens: Schaffen Sie die Firewall aus dem Weg, wenn Sie können.

Deaktivieren Sie es vorübergehend, aber nur, wenn es sicher ist. Andernfalls nehmen Sie für netbios Ports und Ihre Anwendungen per exename (135/139udp) an. Bei den verwendeten Ports handelt es sich um eine Annahme, d.h. sie können nicht richtig sein.

Fünftens, bevor es zu komplex wird... Versuchen Sie einfach, den Fehler herbeizuführen (führen Sie das Programm aus) und überprüfen Sie die System- und Sicherheitsprotokolle auf beiden Rechnern. Wenn es sich um ein Sicherheitsproblem handelt, wird es wie ein böser Daumen auffallen und Sie können entsprechend reagieren.

Wenn nicht, wird dcomcnfg Ihr Freund sein. Die DCOM-Einstellungen für eine bestimmte Komponente werden in der folgenden Reihenfolge aufgelöst: CODE EXECUTED, PROGRAM SETTINGS und DEFAULT MACHINE SETTINGS. Dcomcnfg hilft Ihnen, die beiden letzteren zu lösen. Eine genauere (aber vereinfachte) Anleitung finden Sie unter http://www.opcfoundation.org/DownloadFile.aspx?RI=326

Weiterverfolgung, wenn Sie steckenbleiben....

Answer 2

Probleme mit Berechtigungen bei der Verwendung von DCOM können einem das Leben schwer machen... Sie fallen in den Zuständigkeitsbereich des Systemadministrators und des Programmierers, und solange der eine nicht genug über den Part des anderen weiß, können sie ziemlich schwer zu lösen sein.

Was Ihr spezielles Problem angeht, so ist die Ursache für diese Fehlermeldung ein zu langer Serverstart, der den Aufruf von CoRegisterClassObject bis nach Ablauf der Zeitüberschreitung verzögert. Ich würde nach der Ursache des Problems in Ihrem Server-Startup suchen, bevor ich mich mit COM befassen würde. Überprüfen Sie alle Initialisierungen, die Sie durchführen (Konstruktoren für globale Variablen usw.), und stellen Sie sicher, dass keine Ausnahme geworfen wird oder so. Ein Benutzerwechsel kann dazu führen, dass auf einige Verzeichnisse oder Registry-Hives nicht mehr zugegriffen werden kann, wodurch die Initialisierung möglicherweise unterbrochen wird.

Ich würde zunächst die Serveraktivität mit ProcMon . Dies würde die Suche nach Problemen mit verweigertem Zugriff erleichtern und Ihnen den entsprechenden Stack-Trace zeigen. Wenn eine Fehlersuche erforderlich ist, können Sie den Debugger anhängen, sobald die Exe wie folgt gestartet wird diese Anleitungen . Wenn das Problem auf einem Rechner ohne VS auftritt, können Sie mit WinDBG um den Prozess zu debuggen.

Answer 3

In meinem Fall wurde das XP auf meinem Rechner von den IT-Mitarbeitern meines Unternehmens geändert. So hatten sie durch eine Gruppenrichtlinie den Zugriff auf bestimmte DCOM-Einstellungen sogar für die Administratorgruppe verweigert.

Die Abhilfe bestand darin, die DCOM-Server manuell in einer Eingabeaufforderung zu registrieren, die mit den Anmeldeinformationen des integrierten Administratorkontos geöffnet wurde.