MFC-Anwendung erzeugt DEP-Ausnahme nur in einem Verzeichnis

[nina63]

Hallo,
ich bin bei einem Kunden mit einem unklaren Fehler konfrontiert: Meine MFC-Anwendung wird dort von einem Server (2008R2) gestartet und läuft auf den PCs ohne Probleme. Von einem RDP-Server aus stoppt DEP die Anwendung jedoch. Was ich nicht verstehe: wenn ich das Programmpaket 1:1 in ein anderes Verzeichnis kopiere, kann diese Kopie auch vom RDP-Server gestartet werden. Hat jemand eine Idee?

Gruß
Nina

[Martin Richter]

Werden andere Komponenten geladen, wenn die Anwendung in einem anderen Verzeichnis liegt?

Wo tritt die Exception auf? Man müsste das doch debuggen können.

[Nina63]

Hallo,
die Anwendung läuft auf dem Server des Kunden -- ich darf dort nicht debuggen. Es handelt sich um die gleichen Exe- und DLL-Files, die lediglich umkopiert werden und in dem zweiten Ordner korrekt ausgeführt werden.
Gruß
Nina

[Martin Richter]

Dump erzeugen lassen und den Debuggen.

[Ein ehemaliger Benutzer]

Hallo,
ich kann zwar keine Lösung nennen, aber ich hatte auch einen merkwürdigen Effekt, der möglicherweise in die gleiche Richtung geht:

- ich habe mein EXE kompiliert zu ABCDE.EXE
das läuft bei uns in der Firma auf mehreren Rechnern.

- kopiere ich das EXE zum Kunden läuft es nicht mehr: DEP

- rename ich ABCDE.EXE nach ABCDE1.EXE läufts wieder (im gleichen Directory)
????????????

Wär für einen aufhellenden Tipp ebenfalls dankbar!!!

[hustbaer]

Es gibt einige Dinge die Windows anhand des .exe Namens macht. Darunter z.B. auch Kompatilitäts-Spezialbehandlungen für bestimmte Programme.
Bei "nicht sehr spezifischen" .exe Namen kanns einen da schnell erwischen.

Google mal nach dem Namen deiner .exe -- vielleicht heisst ein Programm eines anderen Herstellers genau so, das bekanntermassen Probleme auf neueren Windows Versionen macht.
Und such mal in der Registry des Kunden nach dem Namen deiner .exe.
z.B. unter
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options
und
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Image File Execution Options

Und guck in C:\Windows\AppCompat\Programs nach - da sollte ein grosses .XML File liegen.

Wenn dein .exe Name da irgendwo auftaucht kanns leicht sein dass deine .exe eine Spezialbehandlungen bekommt die sie gar nicht bekommen sollte. Weil eine .exe eines anderen Herstellers halt gleich heisst.

Ansonsten:
* Rebuild-All
* Danach auf diesem PC *nichts* mehr an der Solution ändern (=keine Source Files, keine Builds mehr ausführen etc.)
* .exe zum Kunden spielen
* Crash-Dump beim Kunden erzeugen
* Crash-Dump auf dem PC wo die .exe gebaut wurde in Visual Studio als Projekt aufmachen und auf "Play" drücken
=> Tadaa, eine "eingefrohrene" Debug-Session mit genau dem Zustand in dem das Programm beim Kunden gecrasht ist.

[nina63]

Hallo,
zunächst einmal herzlichen Dank für Eure Antworten. In der Registry und in der XML-Datei war weder der Programmname noch eine der zahlreichen DLLs zu finden.

Kurioserweise funktioniert die Software fehlerfrei, wenn ich eine Kopie des Startprogramms unter anderem Namen anlege und diese starte.

Gruß
Nina

[hustbaer]

Kurioserweise funktioniert die Software fehlerfrei, wenn ich eine Kopie des Startprogramms unter anderem Namen anlege und diese starte.

Also anderer Name, selbes Verzeichnis, und auch sonst alles gleich?
Das ist komisch...

Geht es auch wenn du die Datei umbenennst statt eine Kopie zu erzeugen? Wenn nicht, dann könnte es an den File-Berechtigungen liegen. Die werden nämlich beim Kopieren neu anhand der Berechtigungen des Verzeichnisses erstellt (beim Umbenennen bleiben sie aber erhalten). Wäre einen Versuch wert.

Oder liegen im selben Verzeichnis vielleicht auch andere Files mit dem selben Namen wie die .exe, nur andere Extension? Vielleicht ein .manifest File oder sowas?

Sonst fällt mir im Moment nix mehr ein, d.h. ich würde vermutlich als nächstes mal versuchen an einen Crash-Dump zu kommen.

[nina63]

Hallo,
es hat etwas gedauert aber nun konnte ich die Ursache für die DEP-Ausnahme finden. Die Anwendung läuft auf mehreren Servern ohne Probleme aber kann nicht von den Benutzern des Terminalservers gestartet werden (wobei das Programmverzeichnis auf einem weiteren Server liegt). Das Ganze funktioniert sobald man Exe und DLLs in ein anderes Verzeichnis kopiert. Nach einem Update in der letzten Woche hat auch das nicht mehr funktioniert, sodass ich schließlich ein drittes Verzeichnis angelegt habe etc. – sofort hat alles geklappt.

Die Ursache lies sich nach dem Crash-Dump (Danke an hustbaer) erahnen: Die RDP-Anwender starten die neuere Exe mit den DLLs der Vorgänger-Version, die sich noch im Cache befindet – was nicht gehen kann.

Das Installationsskript zeigt, wenn eine Datei offen gehalten wird und deshalb nicht aktualisiert werden kann, es bekommt aber nicht mit, wenn ich DLLs überschreibe, die im Speicher bzw. Cache gehalten werden.
Ich ging davon aus, dass das Betriebssystem über Hashcodes Versionsunterschiede feststellt, dem scheint aber nicht so zu sein. Möglicherweise orientiert sich das System an den in den Ressourcen hinterlegten Versionsinformationen. Ich muss dazu sagen, dass wir eigene Versionsnummern verwenden, die z.T. von Subversion bezogen werden und die eigentlichen Versionsangaben nur bei großen Releasewechseln anpassen: vielleicht muss ich hier umdenken.
Wir lösen die Sache so, dass der Terminalserver nach dem Update neu gestartet wird: der Test mit em Update letzte Nacht hat gezeigt, dass das funktioniert.

Ich möchte mich sehr für Eure Anregungen bedanken.
Nina

[hustbaer]

Mit dem Terminal Server darf das mMn. nichts zu tun haben.
Eher mit

wobei das Programmverzeichnis auf einem weiteren Server liegt

D.h. ein möglicher Workaround wäre auch die Anwendung auf ein lokales Laufwerk zu kopieren.

Oder, aber das ist dir sicher auch selbst klar, einfach ein eigenes Unterverzeichnis pro Version auf dem Netzlaufwerk erstellen. Und die Anwendung dann per Link oder Batchfile starten (wobei man den Link bzw. das Batchfile nach dem Kopieren der neuen Version dann auf den neuen Pfad "verbiegt").

[nina63]

Hallo,

die Anwendung liegt mit ihren DLLs, der DB etc. auf einem eigenen Server, der nur hierfür vorgesehen ist. Die Workstations (ca. 70) starten die Anwendung vom Server, führen sie aber lokal aus. Der Zugriff erfolgt auch über das VPN und eben über den Terminalserver. An einem anderen Standort macht die identische Konfiguration keinen Ärger. Da das Umkopieren relativ aufwendig ist und ich solche Redundanzen nicht besonders mag, scheint der automatische nächtliche Neustart des Terminalservers die einfachste Lösung.
Viele Grüße
Nina