Windows Cache beim Laden der EXE spinnt...oder?

[haentschman]

Hallöle...:P

Ich habe eine Exe die auf dem Server im lokalen Netz gespeichert ist. Die Clients laden die EXE von da. Bis jetzt ist es nichts außergewöhnliches...:wink:

PROBLEM:
An verschiedenen Arbeitsstationen wird eine alte Version, trotz Neustart der EXE, im Arbeitsspeicher gehalten. Das Dateidatum = EXE Datum (im Menü angezeigt) lautet aber auf die letzte Version.

Beispiel:
1. EXE Datum 10.06.2021 10:00, kein Button auf der Form.
2. Button auf Form hinzugefügt
3. Neustart der EXE vom Server
4. EXE Datum 11.06.2021 07:00, kein Button auf der Form. :shock:
5. Neustart des gesamten Computers. (mehrfacher Neustart der EXE bringt es nicht)
6. EXE Datum 11.06.2021 07:00, Button auf der Form. :thumb:

Ich habe das Gefühl, daß das immer die gleichen Arbeitsstationen sind, wo die EXE nicht "ausgetauscht" wird.

Kann man das irgendwie Prüfen? Eher Server oder Arbeitsstation?
Auch unser EDV Fuzzi ist ratlos...:?

Danke für Infos...:P

Crosspost: https://en.delphipraxis.net/topic/51...ing-the-exeor/

[CCRDude]

Manchmal führen Bugs ja dazu, dass Prozesse nicht komplett "schließen". Dann ist die UI schon weg, aber der Prozess läuft bzw. hängt noch. In so einem Fall hätte der PE Loader die exe ja schon im Speicher und würde sie u.U. nicht neu laden. Also als Idee: im Task Manager prüfen, ob wirklich alle Instanzen beendet sind.

[haentschman]

Zitat:

Also als Idee: im Task Manager prüfen, ob wirklich alle Instanzen beendet sind.

...sind definitiv alle weg. :?

Zitat:

u.U. nicht neu laden.

...warum stimmt dann die geladene EXE (Datum neuestes) nicht mit der Form (Inhalt) überein? :gruebel:

[haentschman]

Nachtrag Info:
Früher mußte ich auf dem Server alle Instanzen "abschießen" um eine neue Version einzuspielen. Bei 15+ Nutzern ist das tagsüber schlecht...:?

Deshalb habe einen "Finalbuilder Light" erstellt der über ein Tool die aktuelle EXE umbenennt und in einen Order verschiebt der die Versionskennzeichnung hat. Das hat keine Auswirkung auf die Laufzeit. Über ein anderes Tool wird geprüft noch ein User Zugriff hat...wenn nicht, wird der Ordner entfernt.

Damit kann ich jederzeit die Version tauschen und muß nicht alle abschießen. :thumb:

Mit der Kopie kann es eigentlich nichts zu tun haben, weil immer nur die aktuelle EXE geladen wird...oder? :gruebel:

[jaenicke]

Zitat:

Zitat von haentschman (Beitrag 1490994)

Mit der Kopie kann es eigentlich nichts zu tun haben, weil immer nur die aktuelle EXE geladen wird...oder? :gruebel:

Windows leitet intern die Zugriffe auf die umbenannte Version um. Nur deshalb kannst du diese auch im laufenden Betrieb umbenennen. Wie das genau funktioniert, weiß ich nicht, aber ich vermute der Server muss damit etwas zu tun haben, denn dort wird die Exe ja schließlich trotz Zugriffs umbenannt.

Eine ganz einfache Lösung, die wirklich immer zuverlässig funktioniert:
Ein Loader (der kann ja wie die ursprüngliche Exe heißen) startet die jeweils aktuelle Exe, die unter einem Namen mit Versionsnummer, wie du es ja schon für alte Versionen hast, gespeichert wird. Der Loader kann die neueste vorhandene Exe nehmen, die korrekte aus einer .ini lesen, wie auch immer.

[haentschman]

Zitat:

Ein Loader (der kann ja wie die ursprüngliche Exe heißen) startet die jeweils aktuelle Exe

...den habe ich schon. Der lädt immer die aktuelle EXE. Im Menü (Bild) wurde auch die richtige Version angezeigt, aber der "Inhalt" der EXE war falsch. :?

[jaenicke]

Zitat:

Zitat von haentschman (Beitrag 1490997)

Zitat:

Ein Loader (der kann ja wie die ursprüngliche Exe heißen) startet die jeweils aktuelle Exe

...den habe ich schon. Der lädt immer die aktuelle EXE.

Der sollte aber eine Exe mit der Versionsnummer im Namen laden, das meine ich. Dann muss nichts umbenannt werden und das ganze Problem kann nicht mehr auftreten.

Du hast übrigens zwar die Dateinamen verpixelt, nicht aber den vermutlich gleichnamigen Ordnernamen oben.

[Redeemer]

Ich möchte nochmal folgenden Satz hervorheben:

Zitat:

Zitat von jaenicke (Beitrag 1490996)

Windows leitet intern die Zugriffe auf die umbenannte Version um.

Genau das ist das Problem (aber nur, wenn die Datei zum Zeitpunkt der Umbenennung gesperrt ist). Da kommst du auch nicht drum rum. Möglicherweise PE-Flag NET_RUN_FROM_SWAP (oder wie das heißt) ausmachen, das verhält sich aber sowieso total seltsam und ist auch keine gute Idee.

Mein Hauptprojekt hat im LAN daher für den LAN-Start einen kleinen Launcher, der die neuste Version sucht und startet. Es kann alternativ in %LOCALAPPDATA% kopiert werden und läuft dann mit einem Updater.

[haentschman]

Danke an alle...:P

Zitat:

Der sollte aber eine Exe mit der Versionsnummer im Namen laden, das meine ich.

keine schlechte Idee. :P

Zitat:

Mein Hauptprojekt hat im LAN daher für den LAN-Start einen kleinen Launcher, der die neuste Version sucht und startet. Es kann alternativ in %LOCALAPPDATA% kopiert werden

auch eine Alternative. :P

[Bernhard Geyer]

Wurde auch der Server schon neu gestartet?
Der client wurde ja schon.

Hatten bei uns mal den Fall das der Virenscanner auf dem Server komplett im Wald und schein dafür gesorgt hat das irgendwelche Dateifragmente ausgeliefert wurden.

[Papaschlumpf73]

Ich würde auch eher auf den Virenscanner des Clients tippen.

[zeras]

Wir hatten (haben) auch ein ähnliches Problem, Exe liegt auf Server und Clients sarten diese.
Vor nicht allzulanger Zeit konnte ich keine neue Exe überschreiben, wenn noch ein Client das Programm offen hatte.
Das geht jetzt mittlerweile. Vielleicht gab es da ein Windows Update (Server, oder Desktop).
Jetzt kommt es aber vor, dass ich eine neue Exe auf den Server lege und die Kollegen berichten, dass immer noch die alte Version aktiv wäre.
Erklären kann ich mir das bis jetzt nicht.

[haentschman]

Hallöle...:P

Ich bin nicht allein und noch nicht komplett verrückt...:cheer:

Persönlich habe ich mich gestern entschieden die Exe mit dem Timstamp im Namen zu versehen. Da ist es dann eindeutig.
Aber:
Ich hatte das Programm ausschließlich in der TNA. Was passiert? Durch den neuen Namen wächst die Liste mit jedem neuen Update an und der User muß das Programm wieder "einblenden". :? Darum habe ich das in der TNA entfernt und einen Standard, und pinbaren, Button wieder erstellt...man hat ja sonst nichts zu tun. :roll:

Nachtrag:
Auch über den Launcher ist der Dateiname logischerweise immer anders...deshalb funktioniert auch das Anpinnen nicht wirklich! :evil:

Und nun? :roll:
Es soll entweder nur ein pinbarer Button oder der immer eingeblendete TNA Eintrag zu sehen sein...oder beides...und aktuell. :?

Frage:
Ich habe nicht immer bei jedem Update die Versionsinformationen geändert. Würde das was bringen jedes mal z.b. Die Buildnummer zu erhöhen? :gruebel: Liest Windows die Versionsinformationen beim Laden und entscheidet...Cache oder nicht? :gruebel:

Hat jemand einen Account da? Da soll eine Lösung sein.
https://www.experts-exchange.com/que...directory.html

Tante:
https://www.google.de/search?q=windo...YgKCI8Q4dUDCA0

https://social.technet.microsoft.com...m=winservergen
...kann das jemand erklären was zu machen ist? :oops:

[Bernhard Geyer]

Zitat:

Zitat von zeras (Beitrag 1491037)

Wir hatten (haben) auch ein ähnliches Problem, Exe liegt auf Server und Clients sarten diese.
Vor nicht allzulanger Zeit konnte ich keine neue Exe überschreiben, wenn noch ein Client das Programm offen hatte.
Das geht jetzt mittlerweile. Vielleicht gab es da ein Windows Update (Server, oder Desktop).

Das ändert MS des öfteren.
Es ware schon 3-4x der fall das es Monate/Jahrelang ging, dann wieder Monate/Jahrelang nicht und dann doch wieder

Zitat:

Zitat von zeras (Beitrag 1491037)

Jetzt kommt es aber vor, dass ich eine neue Exe auf den Server lege und die Kollegen berichten, dass immer noch die alte Version aktiv wäre. Erklären kann ich mir das bis jetzt nicht.

Server neu starten?
Wir hatten schon den Fall das der Server (zusammen mit Virenscanner auf Server) "im Wald" war und nur defekte Exes ausgeliefert hat.
Nach Reboot hat alles wieder geklappt.

[dummzeuch]

Nur so als Idee: Könntest Du nicht ein einfaches Programm vorschalten, das sich im Prinzip nie ändert? Es sucht die neueste Version es eigentlichen Programms (nach Datum im Dateinamen) und startet sie. Dieses Executable kann man dann wo auch immer als Shortcut oder Menüeintrag verwenden.

Wo ich so drüber nachdenke: Das sollten wir bei uns vielleicht auch mal so implementieren. Wir haben nämlich ein ähnlich gelagertes Problem.

[haentschman]

Hallöle...:P

Zitat:

Könntest Du nicht ein einfaches Programm vorschalten, das sich im Prinzip nie ändert?

Wie meinst du das? ShellExecute? Das habe ich mit dem Loader.

Die Probleme die mir so einfallen:
1. Auch wenn du das über das Programm startest hast du immer noch den Prozess mit dem Namen.
2. Ein Klick auf den "Programm" Button in der Taskleiste holt das eigentliche Programm nicht in den Vordergrund.
3. TNA wie 1.

Ich hatte schon überlegt, auf dem Server die geöffnete Datei mit dem Namen für ausschließlich diesen entsprechenden Computer/Owner abzuschießen. Dann erst laden. :gruebel:

[blawen]

Zitat:

Zitat von dummzeuch (Beitrag 1491045)

Nur so als Idee: Könntest Du nicht ein einfaches Programm vorschalten, das sich im Prinzip nie ändert? Es sucht die neueste Version es eigentlichen Programms (nach Datum im Dateinamen) und startet sie. Dieses Executable kann man dann wo auch immer als Shortcut oder Menüeintrag verwenden.

Wo ich so drüber nachdenke: Das sollten wir bei uns vielleicht auch mal so implementieren. Wir haben nämlich ein ähnlich gelagertes Problem.

Ich habe es ähnlich gelöst.

Ein Loader Programm vergleicht jeweils die Clientversion mit der Serverversion. Sofern eine neuere vorhanden ist, wird die Serverversion im Client lokal gespeichert und anschliessend vom Loader gestartet. Sofern ein Task mit dem gleichen Namen läuft, melde ich dies und der User kann entscheiden, ob der Prozess abgeschossen werden soll und danach das Update eingespielt wird oder ob die veraltete Version gestartet werden soll.

Den Loader habe ich gleichzeitig mit einer Autoupdate-Funktion versehen so dass ich auch jeweils den Loader automatisch ersetzen kann.
So ist alles aktuell und ich habe bisher keine Komplikationen feststellen können.

In meinem Fall starte ich vom Loader aus mehrere Programme
Anhang 54091

[haentschman]

Hallöle...:P

Zitat:

Sofern eine neuere vorhanden ist

1. Wie prüfst du das? Größe? Versionsinformationen?
2. Haben alle Dateien im Dateinamen die Versionsinformationen?
3. Wie prüfst du, das die Datei vom Inhalt neu ist? (bei mir EXE Version neu, Inhalt alt! :evil:)

Zitat:

Ein Loader Programm vergleicht jeweils die Clientversion mit der Serverversion

Da sind wir uns alle einig. Das löst aber nicht das Caching Problem...:?

[jaenicke]

Irgendwie verstehe ich das Problem nicht:
- Auf dem Server liegen die Exen jeweils mit Versionsinfo im Namen
- Ein Loader kopiert die jeweils aktuelle auf den lokalen PC und benennt sie da um (ohne Versionsinfo im Namen)
- Und dann kann der Loader diese immer gleich benannte lokale Datei starten

Weder kann da das Caching des Servers die falsche Exe liefern noch kann in der TNA oder anderswo ein Problem durch anders benannte Exen entstehen.

[Papaschlumpf73]

Ich würde gerne noch mal von vorne anfangen. Unsere Software läuft bei zig Kunden. Die exe-Datei liegt auf irgendeiner Netzwerkfreigabe und alle Clients starten sie von dort über einen Startmenüeintrag. Die Updates machen wir auch mit Umbenennen der alten exe und kopieren der neuen exe, da wo die alte vorher war – selber Name usw. Dabei haben die Kunden gefühlt alle nur denkbaren Windows-Versionen auf ihren Servern und Clients im Einsatz. Dieses Problem hatten wir jedoch noch nie. Möglicherweise haben wir ja (versehentlich) etwas eingebaut, das Windows oder die Anti-Viren-Software davon überzeugt, die neue exe sauber an den Client zu übertragen:
In den Projektoptionen ist eingestellt, dass die Versionsinformationen in die exe übernommen werden. Jede neue Version bekommt hier auch ihre eigene Versionsnummer.
Mit den folgenden Einstellungen konnten wir auch schon einige, unregelmäßig auftretende Fehler beheben:
{$SetPEFlags IMAGE_FILE_NET_RUN_FROM_SWAP}
{$SetPEOptFlags IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE}

Könnt ihr ja mal ausprobieren; kann ja nicht schaden…

[haentschman]

Moin...:P

Zitat:

Ein Loader kopiert die jeweils aktuelle auf den lokalen PC und benennt sie da um

Zum Programm gehört nicht nur die EXE. Die EXE und DLL sollen da bleiben. Ich will nicht an jedem Arbeitsplatz die komplette Installation pflegen müssen. :?

Zitat:

Und dann kann der Loader diese immer gleich benannte lokale Datei starten

Da bin ich dann bei einer lokalen Installation mit Updater. :?

Zitat:

Mit den folgenden Einstellungen konnten wir auch schon einige, unregelmäßig auftretende Fehler beheben

...hab ich schon drin. {$SetPEFlags IMAGE_FILE_REMOVABLE_RUN_FROM_SWAP or IMAGE_FILE_NET_RUN_FROM_SWAP}

Zitat:

Jede neue Version bekommt hier auch ihre eigene Versionsnummer

Diese Frage hatte ich schon ein paar Threads vorher im Kopf. :wink: Ich werde mal jede Version über die Buildnummer automatisch "eindeutig" machen und das Ganze beobachten.

[HolgerX]

Hmm..

a) Ihr dreht euch im Kreis.. ;)

b) Wenn ein Update einer EXE aufgespielt werden soll, dann geht dies nur 'sauber' wenn diese Exe von keinem client mehr 'geöffnet' ist.
Unter Windows selber wird nach dem 'öffnen' mit Dateinamen diese nur noch per Handle angesprochen. Deshalb funktioniert das umbenennen und ablegen mit gleichem Namen, da das Handle immer noch auf das andere File zeigt. Da helfen auch die PE-Flags nicht, da diese erst beim Öffnen der neuen EXE greifen!

Bei einigen Windows-Versionen, gerade bei den Serverversionen, geht diese Umbenennung, bei anderen nicht, dass hängt auch davon ab, mit was für einem Client auf das Share/die EXE zugegriffen wird.
Auch ist es so, dass per Share noch auf die alte, umbenannte (durch einen Client noch geöffnete) EXE zugegriffen wird, bis auch der letzte Client diese 'freigegeben' hat. Da wird von Windows einfach nur eine Handle-Kopie der geöffneten weiter gereicht.

Wenn Du Sicherstellen willst, dass 'wirklich' alle Clients mit der neuen Version arbeiten, dann müss vor dem Update die Exe auf allen Clients beendet werden. Dies kannst Du auf dem Server prüfen unte Verwaltung/Freigaben/Geöffnete Dateien.

( Dies basiert auf meinen Erfahrungen mit Windows-Servern und EXE von Share starten ;))

[haentschman]

Zitat:

dann müss vor dem Update die Exe auf allen Clients beendet werden. Dies kannst Du auf dem Server prüfen unte Verwaltung/Freigaben/Geöffnete Dateien.

...dann wäre ich auf dem Stand von vor 2 Jahren. :roll: Ich konnte damals nur ein Update einspielen nach 21:00. Wenn mal was schief gelaufen ist, tagsüber alle rausschmeißen bei 365/24 Betrieb. Never zurück. :thumb:

[Sinspin]

Zitat:

Zitat von haentschman (Beitrag 1491066)

...dann wäre ich auf dem Stand von vor 2 Jahren. :roll: Ich konnte damals nur ein Update einspielen nach 21:00. Wenn mal was schief gelaufen ist, tagsüber alle rausschmeißen bei 365/24 Betrieb. Never zurück. :thumb:

Du arbeitest direkt mit Programm das vom Share gestartet wird?
Eine lokale Kopie macht wenigstens nicht bei allen Probleme.

Ginge es, mit einem Loader zu arbeiten und das eigentliche Programm als dll zu liefern? Dann bleibt der Loader(die exe) immer gleich. Die Systray Einstellungen ändern sich dann auch nicht.
Und die Dll könntest Du jedesmal mit einem neuen Namen (Name + Buildnummer??) erzeugen.

[himitsu]

Nja, für langsame PC/Netzwerke hatte ich hier mal eine kleine Batch geschrieben, die hat beim Start die Dateien von einem Netzlaufwerk in einem lokalen Verzeichnis aktulaisiert (XCOPY) und dann die EXE gestartet.
Also statt der EXE wird dann die CMD aufgerufen, als ersten Parameter der Netzwerkpfad und dann die weiteren Parameter an die EXE durchgereicht.
Auf langsamem Rechner mit langsamen/instabilem WLAN dauert es ewig, bis gefühlt 2 Millionen DLL/BPL von DevExpress und Co. geladen sind und das Ladefortschrittsfenster der Anwendung endlich auftaucht.
(inzwischen wurde die Funktion in eine LoaderEXE verschoben)

Pervers finde ich immernoch, dass {$SetPEFlags IMAGE_FILE_REMOVABLE_RUN_FROM_SWAP or IMAGE_FILE_NET_RUN_FROM_SWAP} in der EXE definiert nicht auch für "alle" DLL/BPL gilt.
Vor allem bei Fremdkompilaten ist das echt blödsinnig. (man kann ja nicht alles selbst kompilieren und es ist auch nicht immer möglich überall nachträglich ab deb Bits der PEFlags rumzupfuschen)
Soeine Option gehört auch garnicht in jede DLL, denn die kann garnicht wissen, wie/wo sie mal verwendet wird. (abgesehn davon seh ich keinen Grund soeine Funktion nicht standardmäßig im OS zu aktivieren)

[haentschman]

Info aus der eDP:

Zitat:

To bypass offline files add $NOCSC$ after the server name: ex \\server.domain.com$NOCSC$\share. 

https://blog.wisefaq.com/2016/01/26/...-side-caching/

Zitat:

it causes the local computer to bypass the local file cache, and to grab the file from the file server.

...probiere ich mal aus. :P