Absturz ohne Fehlermeldung

[AUGE_OHR]

Was sonst überall läuft, nur bei dieser einen Installation eben nicht.

heisst das jetzt 1 Workstation oder bei einem Kunden ?
p.s. die XppFatal.log wird nicht unbedingt im EXE Directory erzeugt ... also "allgemein" auf allen Laufwerken mal suchen.

Nein, beim Kunden, egal auf welcher Arbeitsstation. Xppfatal entsteht garantiert nicht. Leider.

dann muss es ja ein (Citrix) Server Problem sein

[brandelh]

Frage, kannst du im aktuellen Verzeichnis (also mit fcreate()) eine Datei erzeugen oder ist das schreibgeschützt (EXE Verzeichnis auf Servern, das kommt vor).
Ich setze mit CurDir() das aktuelle Verzeichnis auf mein Datenverzeichnis, damit ich an die Fehlermeldungen komme.

[Herbert]

Hallo Hubert
Nein, bei dieser Installation ist alles in "meiner" Ordnerstruktur mit korrekten Rechten. Das ist hier in Ordnung.

[Herbert]

Die Stack-Einstellung hat das Problem leider nicht gelöst.
Immerhin habe ich zwischenzeitlich Fehlermeldungen erhalten, welche beim Schreiben in eine Datei, welche exklusiv für den User offen ist (Fensterposition abfragen/holen) erscheint. Unbekannter Feldtyp.Regelmässigkeit haben wir keine feststellen können.
Ein anderer Ansatz ist, dass bei Klick auf einer Toolbar das Problem vermeintlich schneller reproduzieren lässt. Bei öffnen desselben Fensters über das Menü und nicht über die toolbar provozierte keinen Absturz. Der Absturz ereignet sich beim Schliessen eines Fensters also nicht einfach so alleine. Aber ohne XppFatal und ohne sonstige Meldungen.
Ich suche noch weiter, das Problem einzugrenzen. Einfach scheint mir die Sache nicht zu sein.

[UliTs]

Bei mir vermute ich, dass es mit Active-X-Componenten zu tun hat.
Das Ändern des Stack bewirkte bei mir, dass vor dem Schließen ohne XppFatal mehr Zeit verging. In dieser Zeit hatte man den Eindruck, dass das Programm hängt.
Deshalb vermute ich, dass bei dem Problem durch eine rekursive Endlosschleife der Stack bis zum Absturz vollgeschrieben wird.
-
Vielleicht hat eine der Active-X-Componenten eine andere Version als sonst...
-

Uli

[Herbert]

Ist zu befürchten. Habe mit dem Systemverantwortlichen nun einen Termin fixiert.

[Tom]

Bei mir verursachte eine AX-Komponente große Probleme, der VSPDFViewer von VisageSoft. o:UserEvents := .F. beseitigte diese. Sie traten vor allem auf, wenn anschließend andere Komponenten oder Funktionen aus Fremd-DLLs (beispielsweise List&Label) aufgerufen wurden. Absturz mit XppFatal.

[Werner_Bayern]

Servus Herbert,

trifft es zwar nicht ganz genau, aber könnte in die Richtung gehen:
http://www.alaska-software.com/scripts/ ... PDRID=6289

[Herbert]

Ja, interessanter Hinweis. Allerdings habe ich keine XppFatal.
Mal sehen, ob ich die Programme lokal nehmen kann.

[Werner_Bayern]

sicherlich ein Test wert. Wenn die Verbindungen - was wir unter VMware auch schon hatten - zwischendrin mal weg sind, kann auch keine xppfatal.log mehr erzeugt werden.

[Tom]

"Abstürze ohne Fehlermeldung" (und ohne XppFatal) gehen nach meiner Erfahrung zu mehr als 80 Prozent auf implizite QUITs zurück, die versehentlich ausgelöst wurden. Ich würde mal jede Stelle, an der ein AppExit oder ähnliches ausgelöst wird, mit einem Log-File verknüpfen. Oder alles in einer Funktion bündeln und die standardmäßig loggen.

[brandelh]

Man kann auch eine EXIT Funktion anlegen und den Callstack in eine Protokolldatei ausgeben (so mache ich das auf dem Web-Server mit meinen CGI EXEs)

Code: Alles auswählen

EXIT PROCEDURE LogEnde()
   local x := 0, cTxt := "", cFile := "LogDatei.txt"
   DO WHILE ! Empty( ProcName(x) )
      cTxt += str(x,4)+". "+ ProcName(x) + " ("+alltrim(str(ProcLine(x)))+")" + chr(13)+chr(10)
      x++
   ENDDO
   memowrit( cFile , cTxt)
RETURN

Die Ziffern in Klammern sind die Zeilennummern im Quellcode

[Herbert]

"Abstürze ohne Fehlermeldung" (und ohne XppFatal) gehen nach meiner Erfahrung zu mehr als 80 Prozent auf implizite QUITs zurück, die versehentlich ausgelöst wurden. Ich würde mal jede Stelle, an der ein AppExit oder ähnliches ausgelöst wird, mit einem Log-File verknüpfen. Oder alles in einer Funktion bündeln und die standardmäßig loggen.

Ich verwende eine AppQuit()-Funktion.
Diese wird beim erwähnten Absturz nicht durchlaufen. Andere Quits existieren nicht.
Zudem stürzt dasselbe Programm nur bei einer von rund 100 Installationen derart ab.

[Herbert]

Man kann auch eine EXIT Funktion anlegen und den Callstack in eine Protokolldatei ausgeben (so mache ich das auf dem Web-Server mit meinen CGI EXEs)

Code: Alles auswählen

EXIT PROCEDURE LogEnde()
   local x := 0, cTxt := "", cFile := "LogDatei.txt"
   DO WHILE ! Empty( ProcName(x) )
      cTxt += str(x,4)+". "+ ProcName(x) + " ("+alltrim(str(ProcLine(x)))+")" + chr(13)+chr(10)
      x++
   ENDDO
   memowrit( cFile , cTxt)
RETURN

Die Ziffern in Klammern sind die Zeilennummern im Quellcode

Tia, falls eine xbpFatal nicht mehr geschrieben werden kann (falls das System dies noch möchte), würde auch diese Datei nicht mehr erscheinen. Ich habe beim Kunden in meine AppQuit()-Funktion eine Meldung eingebaut, die aber nicht erscheint.

[brandelh]

Da hast du natürlich Recht, wenn z.b. ein Stackfehler die Ursache ist, ist alles zu spät.
Ein Schreibschutz könnte man z.B. aber über einen Pfadnamen zum temp Verzeichnis "umlenken".

[Tom]

Hallo, Herbert.

Bist Du eigentlich sicher, dass keine XppFatal entsteht? Hast Du mal eine vollständige Suche über das Kundensystem laufen lassen? Ich habe hier ja - zuweilen recht erstaunt - davon gelesen, dass Apps programmiert werden, die ihre Laufzeit-/Arbeitsverzeichnisse wechseln. Es ist mir zwar noch nicht gelungen, das nachzustellen, aber es wäre denkbar, dass die XppFatal woanders entsteht. Ein weiterer Grund, warum sie möglicherweise überhaupt nicht erzeugt wird, könnte darin bestehen, dass der angemeldete Benutzer keine Schreibrechte im Ausführungsverzeichnis der Applikation hat, was unter bestimmten Bedingungen standardmäßig der Fall ist (Windows 7: Installation in "program files"). Dann kann die Runtime natürlich auch nix schreiben, obwohl sie vielleicht will. Man könnte auch mal - wenn der Fehler halbwegs nachstellbar/wiederholbar ist - die PROCMON.EXE aus den Sysinternals-Tools mitlaufen lassen, begrenzt auf die jeweilige EXE. Da sähest Du dann wenigstens, was zuletzt passiert ist oder versucht wurde.

[Herbert]

Hallo, Herbert.

Bist Du eigentlich sicher, dass keine XppFatal entsteht? Hast Du mal eine vollständige Suche über das Kundensystem laufen lassen? Ich habe hier ja - zuweilen recht erstaunt - davon gelesen, dass Apps programmiert werden, die ihre Laufzeit-/Arbeitsverzeichnisse wechseln. Es ist mir zwar noch nicht gelungen, das nachzustellen, aber es wäre denkbar, dass die XppFatal woanders entsteht. Ein weiterer Grund, warum sie möglicherweise überhaupt nicht erzeugt wird, könnte darin bestehen, dass der angemeldete Benutzer keine Schreibrechte im Ausführungsverzeichnis der Applikation hat, was unter bestimmten Bedingungen standardmäßig der Fall ist (Windows 7: Installation in "program files"). Dann kann die Runtime natürlich auch nix schreiben, obwohl sie vielleicht will. Man könnte auch mal - wenn der Fehler halbwegs nachstellbar/wiederholbar ist - die PROCMON.EXE aus den Sysinternals-Tools mitlaufen lassen, begrenzt auf die jeweilige EXE. Da sähest Du dann wenigstens, was zuletzt passiert ist oder versucht wurde.

Nein, leider nicht. Der betreffende Kunde ist von meiner Seite her einfach: Alles ist in einem eigenen Verzeichnis mit entsprechenden Unterverzeichnissen, worauf der Benutzer die Rechte hat die er benötigt. Ein "normaler" Fehler wird korrekt in der Fehlerroutine (im aktuellen Arbeitsunterverzeichnis) dokumentiert. Ein xbpFatal gabs letztes Jahr offenbar auch schon mal und steht auch dort.
Das Procmon ist eine gute Idee!

[brandelh]

Einige PDF Druckertreiber wechseln den aktuellen Pfad, genauso wie XbpFileDialog() ohne :restoreDir := .t.

[Tom]

Ja, aber nicht das Arbeitsverzeichnis der Applikation. Das ist schon ein bisschen komplizierter.

[brandelh]

Hi Tom,

es ist zwar schon etwas her, aber ich meine dass ich damals Fehlermeldungen wie "Datei nicht gefunden" in meiner Anwendung hatte,
nachdem ich im PDF Druckertreiber das Zielverzeichnis gewählt hatte. Sicher bin ich aber, dass XppFileDialog() das aktuelle Verzeichnis verstellt hat.
Daher verwende ich schon länger nur eigene Funktionen die XppFileDialog() kapseln und die Verzeichnisse wieder herstellen.

Daher verwende ich beim Öffnen der Datendateien immer komplette Pfade, notfalls nach Ergänzung eines relativen Pfades.

[Tom]

Hallo, Hubert.

In meinen Anwendungen sorgen SET PATH und SET DEFAULT dafür, dass Tabellen und Indexe gefunden werden. Wenn es eine Verzeichnisstruktur (in der Regel unterhalb des "SET PATH") gibt, werden bei Dateierzeugungen (und nur dann) vollständige Pfadnamen angegeben. Dieses System kollidiert mit keinem XbpFileDialog und übrigens auch nicht mit DirChange oder ähnlichem. Und selbst _SymSave() (SAVE TO ... ALL LIKE usw.) reflektiert diese Pfade. Bei Low-Level-Funktionen und direkten Dateizugriffen können hierdurch allerdings sehr wohl Probleme entstehen. In diesen Fällen sollte man entweder, wie Du skizziert hast, die Pfade anschließend restaurieren (was nach meiner Beobachtung nicht ganz einfach bzw. verlässlich ist), oder immer mit vollständigen Pfadangaben arbeiten.

[Herbert]

Da bin ja gut bedient. Ich arbeite immer mit kompletten Pfadangaben.

[Tom]

Übrigens ist sich auch die Xbase++-Doku etwas uneinig darüber, was mit "aktuelles Verzeichnis" gemeint ist, obwohl die Formulierung sehr häufig verwendet wird. Liest man die Abschnitte zu SET PATH und SET DEFAULT (und auch zu CurDir()), scheint es stimmig, aber wenn man dann in den Bereich "Standard-Fehlerbehandlung" kommt, findet man das hier:

Wenn eine Fehlerbedingung eintritt, die nicht durch das Standard-Fehlerbehandlungssystem behoben werden kann, erzeugt der Xbase++ Runtime Kernel die Datei XPPFATAL.LOG im aktuellen Verzeichnis.

Das ist definitiv unrichtig. Die Runtime versucht immer, die XppFatal.LOG im Arbeitsverzeichnis ("Ausführen in ...") der Applikation zu erzeugen.

[Koverhage]

Ich hatte öfters den Fall das Daten die in einem Unterverzeichnis gesichert / kopiert werden sollten
plötzlich im Root Directory oder sonst wo standen. Unter Win 7 (als User mit Administrator Rechten)
bekomme ich z.B. mit WinZip eine Fehlermeldung das ich keine Rechte habe diese im Root zu erstellen.
Wenn der Anwender mehrere Fenster offen hat ganz besonders schlimm war Outlook, etc.
In der Routine hatte ich mit CurDir() gearbeitet (lang ist es her).

[UliTs]

Wenn eine Fehlerbedingung eintritt, die nicht durch das Standard-Fehlerbehandlungssystem behoben werden kann, erzeugt der Xbase++ Runtime Kernel die Datei XPPFATAL.LOG im aktuellen Verzeichnis.

Das ist definitiv unrichtig. Die Runtime versucht immer, die XppFatal.LOG im Arbeitsverzeichnis ("Ausführen in ...") der Applikation zu erzeugen.

Tom,
Ich glaube Du irrst Dich!
Die xppfatal.log wird IMMER in's aktuelle Verzeichnis geschrieben!
Die einzige Möglichkeit, das Verzeichnis für die xppfatal.log vorzugeben, ist das aktuelle Verzeichnis zu ändern!
Mit aktuellem Verzeichnis wird das Verzeichnis gemeint, welches Windows bei fehlender Pfadangabe nimmt .

Uli