MFC-Programm kann nicht immer von Netzwerklaufwerk gestartet werden



  • Guten Tag

    Ich habe ein simples Programm geschrieben welches für den Benutzer Dokumente sucht und öffnet.

    Der aktuelle Stand:
    Programmierumgebung: Visual Studio 2005
    Betriebsystem: Win7

    Das Programm läuft zur selben Zeit auf ca. 150 bis 200 Rechnern.
    Davon sind ca. 60 bis 70% Citrix / Igel Rechner.

    Das Programm befindet sich in einem Netzwerklaufwerksordner auf dem alle Nutzer Lese-/Ausführungsrechte besitzen aber so gut wie niemand Schreibrechte.
    Die Einstellungen werden in einer ini-Datei gespeichert, die sich auf einem dem Nutzer zugewiesenen Netzwerklaufwerk befindet.

    Das Programm verwendet statisch gelinkte DLL's (mit Schalter /MT) und verwendet außer die standard MFC-DLL's keine anderen DLL's oder Bibleotheken.

    Zum Problem:

    Das Programm ist in der aktuellen Version über 2 Jahre lang ohne Probleme gelaufen.
    Doch seit ein paar Monaten gibt es das Problem das immer mehr Benutzer die Meldung: "Das Programm kann nicht gestartet werden" bekommen.
    Dabei wird das Programm überhaupt nicht gestartet.
    Ich kann also nicht ermitteln welcher Fehler auftritt.

    Dieser Fehler trat zuerst auf Citrix / Igel Rechnern auf.
    Jetzt sind aber auch PC's betroffen.

    Wenn ich das Programm ein wenig ändere und neu kompiliere funktioniert alles wieder, tritt aber nach ein oder zwei Wochen wieder auf.

    Wenn das Programm auf einen lokalen Ordner kopiert wird, funktioniert es wieder ohne Probleme.
    Diese Methode steht aber nicht zur Verfügung, da es ein Alptraum währe, alle Programme zu aktualisieren wenn ich etwas ändern muss.

    Hat jemand eine Idee was so einen Fehler verursachen könnte?
    Ich weis langsam nicht mehr wo ich noch nach Fehler suchen könnte.

    mfg Bernhard



  • Nachtrag:
    Es werden alle Fehler & Exceptions protokolliert.
    Bei den betroffenen Benutzern wurden aber keine Fehler aufgezeichnet.



  • Du könntest den kostenlosen "Dependency Walker" nutzen, dort das Programm öffnen und dann "Profile" > "Start Profilinig". Es werden dir alle geladenen DLLs usw. angezeigt (siehe Fehler im Fenster ganz unten).



  • Danke für den Hinweis.

    Mir wird gemeldet das 2 DLL's fehlen und dass bei einer DLL ein Modulfehler vorliegt.

    Die Fehlenden DLL's sind:
    Gpsvc.dll
    IEshims.dll

    Die DLL mit der Warnung ist:
    IEFrame.dll

    Das Merkwürdige ist aber, dass ich bei meinem Programm garnichts mit dem Internetexplorer mache.

    Soweit ich die Googlefunde zu dem Thema verstehe, sind das aber falschpositive Funde.
    Ansonsten werden keine Fehler aufgezeigt.

    Wie kann ich jetzt weiter vorgehen?



  • Kannst du ein Start-Script verwenden statt das Programm direkt zu starten?
    Wenn ja, dann bau ein Skript das das Programm erstmal mit robocopy /MIR runterlädt und dann die lokale Kopie startet.
    Falls es dann immer noch "kann nicht gestartet werden" Probleme gibt weisst du zumindest dass es nicht am Netzwerk liegt.

    Und es entlastet das Netzwerk - das Programm wird dann nur neu runtergeladen wenn es sich wirklich geändert hat (Änderung des "last write date").



  • Ja, wenn ich das Programm auf einen lokalen Ordner kopiere, startet das Programm.

    Ich kann ein Startskript verwenden.
    Ich wollte es zwar vermeiden, aber wie es aussieht geht es nicht anders.



  • Leider spielt der Admin bei der ganzen Sache nicht mit.
    Er will, dass das Programm zentral auf dem Ordner bleibt.

    Kann es sein das es bei Windows-Servern eine Begrenzung gibt, wie oft ein Programm von einem Netzwerlaufwerk geöffnet werden kann?


  • Mod

    Nein. Solch eine Begrenzung gibt es nicht.





  • Danke für den Tipp mit dem Internetexplorer.

    Wie es aussieht haben alle betroffenen Rechner den IE11 installiert.
    Ich werde jetzt einmal schaun ob da den Fehler beheben kann.



  • Der Internetexplorer wars leider nicht.

    Eine andere Frage, muss man alle Timer vor dem Beenden des Programms "killen" oder werden die automatisch beendet?

    Es könnte sein das der ein oder andere Timer nicht beendet wird wenn as Programm (Dialogfeldbasierend) geschlossen wird.


  • Mod

    Nein. Das spielt keine Rolle.

    Die Timer sind komplett prozess- und fensterbezogen.


Anmelden zum Antworten