Inoffizielles deutsches Xbase-Forum

Ich habe seit ein paar Tagen dieses Problem an meinem WIN 7 32bit PC:
Wenn ich an einem Programm schnitze kommt es ja vor, das ich es alle paar Minuten neu kompilieren muss. Jetzt passiert es mir immer wieder, dass ich ein Programm nicht linken kann, weil ich die EXE nicht überschreiben kann – obwohl das Programm nicht mehr läuft und auch im Taskmanager nicht auftaucht. Nach ein paar Minuten geht’s dann plötzlich. Windows hat es freigegeben oder was auch immer.

Der Linker meldet; ALINK: fatal error ALK4001: cannot open file “BLAH.EXE”

Da dieser Mist plötzlich auftritt vermute ich einen Zusammenhang mit einem Win-Update.
Kennt jemand das Problem und evtl. den richtigen Schalter aus den Untiefen des Systems ?
Danke
Ewald

Virenscanner ?

Hi Wolfgang,
habe ich soeben deaktiviert. Ist auch ein Teil was ich seit Jahren benutzt. Hat leider nicht geholfen.
Es dauert einen Tacken weniger als eine Minute, bevor ich das Programm nach dem Schließen erneut linken kann.
60 Sekunden in denen ich meine PIIIIEPS in den Pool hängen kann, um es mit den Worten eines bekannten Rennfahrers auszudrücken.

Igendwelche Ressourcen geladen, welche du nicht freigibst?

Hallo, habe das gleiche Problem, kommt relativ oft bei mir vor. Aber bei mir ist es als Prozess im Taskmanager sichtbar, jedoch nicht als Applikation. Hier lässt es sich dann beenden. Ist also relativ normales Verhalten denke ich.
Grüße
Rudolf

So, genug geärgert. Ich habe mich eines der besten Programme überhaupt (nach meinen ) bedient und meine C Partition vom 12.4. wieder zurückgeholt. Und mein Gefühl täuscht mich nicht. Da war das Problem noch nicht da. Sobald ich ein Programm beendet habe kann ich sofort wieder linken, löschen, überschreiben. Mal sehen, ob sich das durch die jetzt fälligen Updates wieder verschlechtert. Ich werde berichten. Danke

Hallo, Ewald -


das Problem kenne ich auch. Windows 7, 32bit, McAfee. Das eben gestartete (und meist abgestürzte) Programm lässt sich auch mittels "del" oder Explorer nicht löschen. Das einzige, was geht: umbennen von test.exe nach test1.exe etc. Nach einer Weile (ca. 15 Minuten oder so) lassen sich die Kopien dann löschen.

Da ich viel auf APIs zugreife, vermute ich das Problem dort.

Allerdings ist es bei mir in den letzten vier Wochen nicht mehr aufgetreten, zumindest erinnere ich mich an keinen Fall.

Glaube nicht, dass ein Umbenennen einer durch ds Betriebssystem benutzten Anwendung möglich ist. In diesem Fall ist die Anwendung bereits geschlossen.
Da ihr in Xbase gerne mit (viel zu vielen) Threads arbeitet: werden diese alle vor dem Quit richtig abgeschlossen?

Hallo, Herbert -


ganz dezent formuliert: was Du glaubst oder nicht, ist bei der Programmierung nicht unbedingt relevant.

Tatsache ist, dass in solchen Fällen ein delete nicht möglich ist, ein rename jedoch schon. Nachdem das Programm renamet wurde, kann es immer noch nicht gelöscht werden.

Weshalb die Umbenennung einer benutzten Datei nicht möglich sein soll, entzieht sich meiner Kenntnis. Der Name ist lediglich ein Label - während das Öffnen der Datei auf ihren Inhalt zugreift.

Ich kann Uli nur zustimmen, der NAME der EXE (wie auch einer DLL) spielt nur beim Starten eine Rolle, danach wird intern ein DWORD als Kennung verwendet.
Für automatische Updates habe ich schon DLLs umbenannt, andere haben dann die Umbenennung der EXE erwähnt und ich habe es probiert. Es geht.

Ich habe ja wie geschrieben eine 14 Tage alte Datensicherung der kpl. Systempartition c: zurückgeschrieben. Virenschutz und dergl. alles wie gestern, nur eben 14 Tage alt. Da war das Problem nicht vorhanden. Die EXE ist sofort nach dem Schließen frei und kann gelöscht bzw. überschrieben werden. Meine Befürchtung, das sich das durch die Updates von WIN 7 und dem Virenscanner wieder in Negative wendet hat, ist NICHT eingetreten. Auch heute, nachdem ich die 3 Millionen Updates der letzten 14 Tage eingespielt habe läuft alles noch wie gewünscht. Ich reihe das mal in die unendliche Serie der unklärbaren Vorfälle ein.

Kleine Anmerkung zum Umbenennen. EXE-Files die sich auf dem Server befinden und von einem User aufgerufen (in Arbeit) sind, lassen sich ja nicht überkopieren. Allerdings lassen auch sie sich umbenennen und man kann die EXE dann neu einkopieren. Das endet dann nur für den User irgendwann mit einer Fehlermeldung

Danke für eure Mithilfe
Ewald

brandelh hat geschrieben:Ich kann Uli nur zustimmen, der NAME der EXE (wie auch einer DLL) spielt nur beim Starten eine Rolle, danach wird intern ein DWORD als Kennung verwendet.
Für automatische Updates habe ich schon DLLs umbenannt, andere haben dann die Umbenennung der EXE erwähnt und ich habe es probiert. Es geht.

Ja, aber...
Es darf doch nicht sein, dass eine Anwendung mit laufendem Dienst einfach umbenannt werden kann? Man kann und sollte dies verhindern. Oder werden da Xbase-Schwächen offenbar?
Microsoft sperrt ja sogar (auch zu meinem Aerger) die Dateien, welche geöffnet sind (und damit auch eventuelle Seriebrief-Datenfiles).

Hallo, Herbert -


noch einmal: Microsoft sperrt die Anwendung, d.h. die Sammlung an Bytes, die auf der Platte stehen. Der Eintrag im Verzeichnis kann geändert werden. Das mache ich (wenn diese Problemphase mal wieder auftritt) mit den uralten Befehlen in der Befehlseingabe.

Ja, ich vermute irgendwelche Probleme in Xbase++, da diese Probleme meist nach einem Programmcrash auftreten. Aber lokalisieren konnte ich die Ursache bisher nicht. Und ich bin froh, dass es derzeit nicht auftritt.

Da hänge ich mich trotz [erledigt] noch mal rein.
Grade getestet. Ich habe MS-Word aufgerufen und dann problemlos MSWORD.EXE in _MSWORD.EXE umbenannt. Hat also mit XBase Anwendungen nichts zu tun.
@georg,
als ich damals (gestern ) das Problem bei mir akut hatte, hat es überhaupt keine Rolle gespielt, ob das Programm gecrasht ist, ganz normal oder mit ALT+C beendet wurde. Bin immer noch verwundert, das es weg ist.
ein Teufelskreis
Gruß
Ewald

Hallo Ewald,

der von Dir beschriebenen Effekt tritt bei mir immer dann auf, wenn es einen von der Applikation verursachten Fehler während des Einsatz von List&Label gibt.

Hallo, Ewald -


doch, es hat etwas mit Xbase zu tun.

Wir haben zwei Effekte: das Umbenennen eines Programms, das man nicht löschen kann (weil es wohl noch geöffnet ist) - das sollte geklärt sein.

Dass wir diesen Effekt haben, dass wir ein Xbase-Programm, das beendet (oder abgestürzt) ist, nicht löschen können, das liegt irgendwo an Xbase++. Irgendetwas wird nicht sauber geschlossen, und es dauerte (zumindest bei mir) so um die 15 bis 20 Minuten (gefühlt), ehe ich das (umbenannte) Programm löschen konnte.

Jetzt folgt reine Spekulation: der Garbage-Collector hat ein Problem, alles richtig zu beenden (eventuell ein Dll-Load) und nach einer gewissen Weile schafft er es oder bricht ab, und damit wird das Programm so freigegeben, dass man es löschen kann.

Andere Frage: verwendest Du OT4XB?

Hallo Georg,
otx4 benutze ich, da ich ja nach und nach meine gesamten Xbase++ Anwendungen an mysql hänge. Mit seinerzeit kräftiger Unterstützung aus der Eifel ...
Ich hatte ja auch den Garbage-Collector in Verdacht. Ich habe auch irgendwo schwach in Erinnerung, das es irgendwo die Möglichkeit gab, an der Schraube zu drehen wie lange ein Server eine EXE bzw, ein DLL nach Abschluss blockiert. Aber da habe ich Jahre nicht dran gedreht und das kann auf keinen Fall der Auslöser gewesen sein.
Und jetzt - ganz wichtig - ist das Problem bei mir weg. Die Programme sind nach Abschluss oder Absturz sofort frei. Seit ich eben eine 14 Tage alte Datensicherung der Systempartition zurückgeholt habe.

Ja, dieses Verhalten habe ich bei zwei, drei Kunden auch.
Lästig wird dies bei Einspielen von Updates.
Unter Windev kann tatsächlich ein geöffnetes .exe auch nicht umbenennt werden, was ich sehr gut finde.

versuch es mal mit ren von der Befehlszeile oder dem Explorer

Ewald hat geschrieben:Ich habe auch irgendwo schwach in Erinnerung, das es irgendwo die Möglichkeit gab, an der Schraube zu drehen wie lange ein Server eine EXE bzw, ein DLL nach Abschluss blockiert. Aber da habe ich Jahre nicht dran gedreht und das kann auf keinen Fall der Auslöser gewesen sein.

HKEY_CURRENT_USER\Control Panel\Desktop\HungAppTimeout
http://technet.microsoft.com/en-us/libr ... 78604.aspx

HKEY_CURRENT_USER\Control Panel\Desktop\WaitToKillAppTimeout
http://technet.microsoft.com/en-us/libr ... 78604.aspx

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WaitToKillServiceTimeout
http://support.microsoft.com/kb/839262

Frage : wo liegt die (gesperrte) EXE ? Server oder Lokal ?

brandelh hat geschrieben:versuch es mal mit ren von der Befehlszeile oder dem Explorer

Nein geht nicht

Hi Jimmi,
stimmt, als ich vor Jahren an der Schraube gedreht habe lagen die EXE's auf dem Server und wurden über das Netz aufgerufen. Damals wollte ich ab und zu Updates einspielen, aber obwohl alle User schon aus dem Büro waren, ging das teilweise nicht, da der Server die Programme noch blockiert hat. Irgendwann waren sie dann ohne mein weiteres Zutun frei.

Bei dem Problem das ich hier jetzt angerissen habe liegen die EXE's lokal und ich hätte erst mal eine Zusammenhang ausgeschlossen. Bis ich jetzt mal nachgeschaut habe und ich diese Reg-Einträge auch auf dem normalen Windows 7 Rechner finde.

Will sagen, das ich ja auch auf einen Server die EXE lokal aufrufen kann - genau so wie ich die EXE auf einem normalen WIN 7 Rechner auch über das Netz aufrufen kann.
Also könnten meiner Meinung nach Änderungen an diesen Reg-Einstellungen (gewollt oder ungewollt) auf einem Win 7 Rechner auch zu dem geschilderten Problem führen.

Kann ich aber alles nur vermuten, da sich das Problem bei mir erledigt hat. Sollte es wieder auftreten werde ich als erstes diese Reg-Einträge mal überprüfen.

Gruß
Ewald

Herbert hat geschrieben:

brandelh hat geschrieben:versuch es mal mit ren von der Befehlszeile oder dem Explorer

Nein geht nicht

Kann es sein, dass deine EXE in einem geschützen Programmverzeichnis liegt und du keine Adminrechte hast ?

Ich habe es eben mit einer PowerBasic EXE probiert (in c:\test\...) und ich konnte die EXE mit dem Explorer einfach umbenennen.

Nein, nichts von deinen Vermutungen. Es ist wie es ist, und das ist gut so.
Und was ums Himmels Willen ist Powerbasic

Herbert hat geschrieben:Und was ums Himmels Willen ist Powerbasic

Der Ursprung meiner PC Programmiersprachen ... TurboBasic (Verkauf durch Borland) umbenannt nach PowerBasic (DOS) nach dem Ausstieg von Borland und Rückkauf durch Entwickler.
(Heute Win32 Bit Entwicklungsumgebung. Kleine schnelle Programme)
Erst danach lernte ich Clipper => VO => Xbase++