Einfache & pragmatische Lösung:
- mache eben wie "gewollt" das Programm ohne besondere
PE Flags
- binde die EXE als Resource in ein zusätzliches kleines "FullfileLoaderProgramm" ein
- kopiere also im Loaderprogramm einfach nur 1x die Resource in z.B. das lokale "ProgrammData" Verzeichnis, starte die EXE dort "lokal" via ShellExecute und beende das Loaderprogramm
So startet dein Chef bei ja aktivem Netzwerk problemlos das "LoaderProgramm", es lädt wegen Zugriff auf die riesige Resource definitiv 1x komplett vom Netzwerk auf den PC(wie er ja unbedingt will) und ab da läuft es dann wie er ja auch will lokal...
=> Chefe hat seinen Willen und Programm funktioniert
So einfach wird es nicht sein. Die Kollegen scheinen sich ja sehr genau anzuschaun was da innerhalb des Programms getrieben wird. So wie die ticken, wird ein solches Vorgehen als ein weiterer Beleg für die Unfähigkeit des Programmierers gewertet dieses Problem in den Griff zu bekommen. Schon das Setzen des
PE-Flags wird ja als Workaround gewertet. Die Gegenfrage ist doch eigentlich, weshalb gibt es dieses Flag überhaupt, wenn es doch nicht notwendig ist.
Kennt jemand vielleicht ein Tool, dass so eine Art Speicherauszug erzeugt. Es wäre ja schön, wenn man zeigen könnte, welche Teile des Programms tatsächlich im
RAM liegen und welche Teile sich nur auf dem Netzwerklaufwerk befinden und bei Bedarf von dort nachgeladen werden.
Alternativ würde ich versuchen das Fehlerbild mit einem aufwändigen Versuchsaufbau zu reproduzieren. Dazu ist es zunächst notwendig den Speicherort der Exe und den
SQL-Server auf unterschiedlichen Netzwerkrechnern zu halten. Nun würde ich versuchen durch Trennen der Netzwerkverbindung des "Exe-Hosts" den Swap-Fehler zu provozieren. Wenn das möglich ist, zeigt mir das, dass der Fehler
nicht dadurch hervorgerufen wird, dass die Netzwerkverbindung zum
SQL-Server abbricht, sondern dass es nur etwas mit den auslagerten Teilen der ausführbaren Datei zu tun hat.