[GELÖST] Automation blockiert durch zweiten Client???

[beno]

Guten Morgen,

Seit 3 Tagen suchen wir eine Lösung für ein Automation-Problem!

Der Kunde hat ein Windows 2008 Server und NAV 5.0 SP1 Update 2. Auf dem Server laufen 1 Database Server, 1 Client und der NAS.
Bis vor 3 Tagen lief der NAS-Dienst auf diesem Server problemlos (wie bei 60 anderen Kunden mit identischem Objektstand auch).
Dann gab es plötzlich Probleme mit der DLL NATHASH.DLL. Wir erhalten immer die Fehlermeldung "...Es konnte keine Instanz erstellt werden...".
Wir haben dann den NAS-Dienst mal beendet und eine kleine Codeunit geschrieben, welche nur einen CLEAR und einen CREATE dieser Automation durchführt.
Auch hier erhalten wir dieselbe Fehlermeldung.

Auf dem Server läuft noch ein zweiter Client, welcher zeitgesteuert Jobs durchführt.
Wir haben nun herausgefunden, dass die kleine Test-Codeunit einwandfrei funktioniert,wenn nur 1 Client aktiv ist?!?
Sobald 2 Clients aktiv sind (z.B. derjenige, welche zeitgesteuerte Jobs durchführt und ein weiterer Client zum Testen der Codeunit),
dann funktioniert der CLEAR/CREATE der Automation nicht mehr (Fehler "...Es konnte keine Instanz erstellt werden...").

Ich gehe davon aus, dass genau dies auch beim NAS-Dienst dann das Problem ist.

Nun kann ich diesen zeitgesteuerten Client aber nicht einfach nicht mehr starten. Der muss dort laufen. Und er lief bis vor ein paar Tagen einwandfrei.

Habt ihr eine Ahnung, was der Grund dieser Probleme sein könnte?

Wir haben den Client und auch den NAS schon neu installiert, die DLL mit Regsvr32 unregistered und wieder registered. Alles half nichts.
Oder könnte es am Microsoft Patchday von letzter Woche liegen? Wir sind zwar als Benutzer mit Administratoren-Rechten angemeldet, aber wer weiss..? Berechtigungen?

Vielen Dank für Eure rasche Hilfe!
Wir wissen nicht mehr weiter und der IT-Partner scheinbar auch nicht!

Beno

Zuletzt geändert von beno am 3. April 2014 17:25, insgesamt 1-mal geändert.

Hallo Beno,

eine Lösung habe ich nicht direkt, aber eventuell einen Analyseansatz.

Erstell bitte mal eine .NET Anwendung, in der du die DLL als Referenz interlegst und dort ebenfalls eine Instanz erzeugst. Passiert da das selbe? Was genau steht in der Exception bzw. der InnerException? Gibt es dort mehr Informationen?

Hallo Carsten,

vielen Dank für Deine Unterstützung. Mein Kollege hat kurz ein Programm geschrieben, mit folgendem Resultat:

************** Ausnahmetext **************
System.UnauthorizedAccessException: Eine Instanz der COM-Komponente mit der CLSID {30E9A1F9-9B22-4D26-91CF-C6CC2D9BC2D9} konnte aufgrund des folgenden Fehlers nicht von der IClassFactory erstellt werden: 80070005.
bei System.RuntimeTypeHandle.CreateInstance(RuntimeType type, Boolean publicOnly, Boolean noCheck, Boolean& canBeCached, RuntimeMethodHandleInternal& ctor, Boolean& bNeedSecurityCheck)
bei System.RuntimeType.CreateInstanceSlow(Boolean publicOnly, Boolean skipCheckThis, Boolean fillCache, StackCrawlMark& stackMark)
bei System.RuntimeType.CreateInstanceDefaultCtor(Boolean publicOnly, Boolean skipCheckThis, Boolean fillCache, StackCrawlMark& stackMark)
bei System.Activator.CreateInstance(Type type, Boolean nonPublic)
bei System.Activator.CreateInstance(Type type)
bei DimabTextExe.Form1.button1_Click(Object sender, EventArgs e)
bei System.Windows.Forms.Control.OnClick(EventArgs e)
bei System.Windows.Forms.Button.OnClick(EventArgs e)
bei System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
bei System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
bei System.Windows.Forms.Control.WndProc(Message& m)
bei System.Windows.Forms.ButtonBase.WndProc(Message& m)
bei System.Windows.Forms.Button.WndProc(Message& m)
bei System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
bei System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
bei System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

Sieht nach einem Zugriffsproblem bei der Verwendung der NATHASH.DLL aus, oder?
Aber was sage ich nun einem externen IT-Partner, welcher für den Server verantwortlich ist?
Mit Dynamics NAV hat dies sicher nichts zu tun.

Vielen Dank für Deine Antwort, Beno

Jetzt wäre dann wohl der Process Monitor die richtige Wahl, um die genaue Zugriffsverletzung zu ermitteln. Vielleicht funktioniert das ja: http://technet.microsoft.com/de-de/sysi ... 96645.aspx

Kurz vorher löschen, dann einmal Fehler provozieren und Aufzeichnung stoppen. Ggf. filtern und nach Fehlern Ausschau halten.

Das hatten wir schon im Vorfeld gemacht (Process Monitor), aber nichts Verdächtiges gefunden.

Gefunden haben wir aber einen Unterschied in der Registry:

Bei 59 Kunden (wo es auch funktioniert) steht Folgendes in der Registry:

Code:

HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{30E9A1F9-9B22-4D26-91CF-C6CC2D9BC2D9}
  HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{30E9A1F9-9B22-4D26-91CF-C6CC2D9BC2D9}\InprocServer32

    Name                 Typ               Daten
    (Standard)           REG_SZ            C:\Program Files (x86)\Microsoft Dynamics NAV\CSIDE Client\NATHash.dll
    (InProcServer32)     REG_MULTI_SZ      !!!!!0cCgAR!!!!hwKilNavisionSolutions>dl0bn{$w{8'Vg&d8r0Dp
    (ThreadingModel)     REG_SZ            Standard


Beim Kunde mit dem Problem steht Folgendes in der Registry:

Code:

HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{30E9A1F9-9B22-4D26-91CF-C6CC2D9BC2D9}
  HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{30E9A1F9-9B22-4D26-91CF-C6CC2D9BC2D9}\InprocServer32

    Name                 Typ               Daten
    (Standard)           REG_SZ            C:\Program Files (x86)\Microsoft Dynamics NAV\CSIDE Client\NATHash.dll
    (ThreadingModel)     REG_SZ            Standard


Unter dem Schlüssel "HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{30E9A1F9-9B22-4D26-91CF-C6CC2D9BC2D9}\InprocServer32" fehlt der Eintrag InProcServer32 mit dem Typ REG_MULTI_SZ und den Daten !!!!!0cCgAR!!!!hwKilNavisionSolutions>dl0bn{$w{8'Vg&d8r0Dp.

Könnte dies ev. das Problem mit dem Blockieren verursaschen?
Komisch ist nur, dass wir eine komplette Deinstallation/Installation des Clients und NAS sowie auch das Deregistrieren und Registrieren der NATHASH.DLL vorgenommen haben.
Dann müssten doch die Registry Einträge genau gleich aussehen wie bei den restlichen 59 Kunden!?!

Gruss, Beno

Nachtrag:

der Process Monitor zeigt im Unterschied zu den anderen Kunden Folgendes:

Code:

Operation         Path                                                                     Result
ReadFile          C:\Program Files (x86)\Microsoft Dynamics NAV\CSIDE Client\NATHash.dll   FAST IO DISALLOWED
ReadFile          C:\Program Files (x86)\Microsoft Dynamics NAV\CSIDE Client\NATHash.dll   FAST IO DISALLOWED
ReadFile          C:\Program Files (x86)\Microsoft Dynamics NAV\CSIDE Client\NATHash.dll   FAST IO DISALLOWED
ReadFile          C:\Program Files (x86)\Microsoft Dynamics NAV\CSIDE Client\NATHash.dll   FAST IO DISALLOWED
ReadFile          C:\Program Files (x86)\Microsoft Dynamics NAV\CSIDE Client\NATHash.dll   FAST IO DISALLOWED
ReadFile          C:\Program Files (x86)\Microsoft Dynamics NAV\CSIDE Client\NATHash.dll   FAST IO DISALLOWED
ReadFile          C:\Program Files (x86)\Microsoft Dynamics NAV\CSIDE Client\NATHash.dll   FAST IO DISALLOWED
ReadFile          C:\Program Files (x86)\Microsoft Dynamics NAV\CSIDE Client\NATHash.dll   FAST IO DISALLOWED
ReadFile          C:\Program Files (x86)\Microsoft Dynamics NAV\CSIDE Client\NATHash.dll   FAST IO DISALLOWED
ReadFile          C:\Program Files (x86)\Microsoft Dynamics NAV\CSIDE Client\NATHash.dll   FAST IO DISALLOWED
ReadFile          C:\Program Files (x86)\Microsoft Dynamics NAV\CSIDE Client\NATHash.dll   FAST IO DISALLOWED
ReadFile          C:\Program Files (x86)\Microsoft Dynamics NAV\CSIDE Client\NATHash.dll   FAST IO DISALLOWED
ReadFile          C:\Program Files (x86)\Microsoft Dynamics NAV\CSIDE Client\NATHash.dll   FAST IO DISALLOWED
ReadFile          C:\Program Files (x86)\Microsoft Dynamics NAV\CSIDE Client\NATHash.dll   FAST IO DISALLOWED
ReadFile          C:\Program Files (x86)\Microsoft Dynamics NAV\CSIDE Client\NATHash.dll   FAST IO DISALLOWED
ReadFile          C:\Program Files (x86)\Microsoft Dynamics NAV\CSIDE Client\NATHash.dll   FAST IO DISALLOWED
ReadFile          C:\Program Files (x86)\Microsoft Dynamics NAV\CSIDE Client\NATHash.dll   FAST IO DISALLOWED
ReadFile          C:\Program Files (x86)\Microsoft Dynamics NAV\CSIDE Client\NATHash.dll   FAST IO DISALLOWED
CreateFileMapping C:\Program Files (x86)\Microsoft Dynamics NAV\CSIDE Client\NATHash.dll   FILE LOCKING WITH ONLY READERS
QueryOpen         C:\Program Files (x86)\Microsoft Dynamics NAV\CSIDE Client\DES\fin.etx   FAST IO DISALLOWED


Bei den 59 Kunden wo es funktioniert, wird erstens nicht 18 Mal ein ReadFile durchgeführt und zweitens tritt auch kein QueryOpen der fin.etx auf.

Das CreateFileMapping mit FILE LOCKING WITH ONLY READERS tritt bei allen auf und scheint kein Problem zu sein.

Irgendeine Ahnung? Registry? fin.etx? Berechtigungen?

VIELEN DANK,
Beno

So auf Anhieb hab ich keine Idee mehr. Sind denn die Registry-Zugriffe die gleichen in beiden Fällen?

Leider gab es keine Lösung. Es hätte wohl der Server neu installiert werden müssen, da auch der IT-Partner nichts gefunden hat.
Meine Analyse hat aber ergeben, dass die NATHASH.DLL (resp. die Methode BSTR) eigentlich nicht mehr benötigt wird.
Als Umgehungslösung habe ich dies nun deaktiviert. Eine zufriedenstellende Lösung ist dies jedoch nicht, da die Ursache immer noch unklar ist!