Ich habe ein Programm, was von mehreren Kollegen genutzt wird. Deshalb liegt das auf einem Filesever, damit man es im Falle eines Updates nicht immer ausrollen muss. Das klappt ganz gut, nur meldete letztens ein Kollege eine Zugriffsverletzung, siehe Bild.
Ich hatte dies selten auch, nur war dann immer kurz die Netzwerkverbindung weg. Damit hatte ich mir das erklärt.
Kann es auch anderen Ursachen haben?

Hallo
Bau dir eine MadExcept-Version.

Zitat von zeras:

Ich hatte dies selten auch, nur war dann immer kurz die Netzwerkverbindung weg. Damit hatte ich mir das erklärt.
Kann es auch anderen Ursachen haben?

Wenn es an der Netzwerkverbindung liegt, füge folgenden Code in die Projektdatei ein:

{$SetPEFlags IMAGE_FILE_NET_RUN_FROM_SWAP + IMAGE_FILE_REMOVABLE_RUN_FROM_SWAP}

Alternativ kannst Du ja auch ein Loaderprogramm einsetzen, welches die Programmversion lokal kopiert (sofern notwendig) und dann von da aus startet.

Zitat von hoika:

Hallo
Bau dir eine MadExcept-Version.

Danke für die Info.
Mein Programm ist zwar kostenlos, wird aber in einer Firma mit Umsatz genutzt.
Daher weiß ich nicht, wie das

Zitat:

free for non-commercial usage, inexpensive for commercial usage

gewertet werden soll.
Ich werde mich erst einmal auf die andere Antwort konzentrieren.

Zitat von blawen:

{$SetPEFlags IMAGE_FILE_NET_RUN_FROM_SWAP + IMAGE_FILE_REMOVABLE_RUN_FROM_SWAP}

Das werde ich probieren.

Zitat von blawen:

Alternativ kannst Du ja auch ein Loaderprogramm einsetzen, welches die Programmversion lokal kopiert (sofern notwendig) und dann von da aus startet.

Wo muss denn das Loaderprogramm laufen?

Statt MAD-Except kannst Du auch die entsprechende Fehlerbehandlung aus der JCL nutzen.

Sie steckt in den Units JclDebug, JclHookExcept, ...

Beispiele findest Du unter .\jcv\windows\examples\debug\.

Alternativ mit der Suchmaschine Deiner Wahl nach delphi jcl debug site:delphipraxis.net suchen.

Zitat von zeras:

Zitat von blawen:

{$SetPEFlags IMAGE_FILE_NET_RUN_FROM_SWAP + IMAGE_FILE_REMOVABLE_RUN_FROM_SWAP}

Das werde ich probieren.

Ich habe meine Unterlagen noch einmal durchgeschaut und gesehen, dass ich diese Flags schon einmal drin hatte.
Da das Projekt schon mit Delphi (Urzeiten) erstellt wurde, hatte ich vor einiger Zeit das Projekt neu angelegt. Daher waren die Flags weg.
Diese sind nun wieder drin und ich werde sehen, ob es immer noch Probleme gibt.
Vielleicht ist auch die Zipmaster DLL schuld, da diese auch auf dem Server liegt und von dort geladen wird.
Wenn das nicht klappt, werde ich die anderen Informationen umsetzen.

Danke für eure Tipps.

Du solltest dir generell eine saubere Exceptionbehandlung angewöhnen. Es ist nie gut, wenn ein Programm statt einer sauberen Fehlermeldung mit Log und Stacktrace usw. nur die Standard-Messagebox anzeigt, die weder dir noch dem Benutzer etwas sagt...

Den Stacktrace bekommst du über die genannte JclDebug z.B. gut, wenn du eine eigene Exceptionbehandlung bauen möchtest.

Zitat von jaenicke:

Du solltest dir generell eine saubere Exceptionbehandlung angewöhnen. Es ist nie gut, wenn ein Programm statt einer sauberen Fehlermeldung mit Log und Stacktrace usw. nur die Standard-Messagebox anzeigt, die weder dir noch dem Benutzer etwas sagt...

Den Stacktrace bekommst du über die genannte JclDebug z.B. gut, wenn du eine eigene Exceptionbehandlung bauen möchtest.

Ich dachte, dass wenn das Netz kurzzeitig zusammenbricht, dass man da garnichts machen kann.
Wenn man aber trotzdem etwas machen kann, muss ich sehen, dass die o.g. Infos einbaue.

Wenn ich micht recht erinnere, haben das zur gleichen Zeit mehrere Kollegen an einem Standort berichtet. Am anderen Standort gab es keine Reklamation. Deshalb meine Idee mit dem Netzwerkausfall, da das ab und zu einmal vorkommt.

Der Grund des Problemes ist doch eigentlich egal, 'ne nichtssagende Meldung über eine Zugriffsverletzung sollte der Anwender nicht zu Gesicht bekommen.

Statt dessen könnte man ja versuchen den Fehler abzufangen und z. B. eine Meldung ala "Fehler bei der Programminitialisierung, bitte das Programm neu starten." oder sowas ausgeben. Eine Fehlermeldung mit Hilfe von JCLDebug kann einem dann sogar sagen, wo der Fehler aufgetreten ist. Das könnte dann z. B. so in der Art aussehen (MessageDLG):

markieren

Code:

---------------------------
Fehler
---------------------------
Zugriffsverletzung bei Adresse 00455BF2 in Modul 'LogFileViewer.exe'. Lesen von Adresse 00000198

Fehlertyp: EAccessViolation
Sender: fmMainLogFileViewer [TfmMainLogFileViewer]

11.07.2021 14:45:20

Dateiname: LogFileViewer.exe
Fehleradresse: 00054BF2

Unit: Controls
Fehleradresse: 00455BF2
Modulname: Controls

Prozedur: TWinControl.GetControlCount
Prozeduroffset: 2
Zeilennummer: 0
Zeilenoffset: 0
---------------------------
OK  
---------------------------

(Logfile)

markieren

Code:

LogFileViewer | 2021.07.10 15.40.20,976 | Dateiname            : LogFileViewer.exe
LogFileViewer | 2021.07.10 15.40.20,976 | Fehlermeldung        : Zugriffsverletzung bei Adresse 00455BF2 in Modul 'LogFileViewer.exe'. Lesen von Adresse 00000198
LogFileViewer | 2021.07.10 15.40.20,976 | Fehlerklasse         : EAccessViolation
LogFileViewer | 2021.07.10 15.40.20,976 | Fehlerauslöser       : pc
LogFileViewer | 2021.07.10 15.40.20,976 | Klassenname          : TPageControl
LogFileViewer | 2021.07.10 15.40.20,976 | Unit                 : Controls
LogFileViewer | 2021.07.10 15.40.20,976 | Fehleradresse        : 00455BF2 (00054BF2)
LogFileViewer | 2021.07.10 15.40.20,976 | Modulname            : Controls
LogFileViewer | 2021.07.10 15.40.20,976 | Prozedur             : TWinControl.GetControlCount
LogFileViewer | 2021.07.10 15.40.20,976 | Prozeduroffset       : 2
LogFileViewer | 2021.07.10 15.40.20,976 | Modul                : 4194304 [400000]

oder aus 'nem anderen Programm:

markieren

Code:

FireFoxVerwaltung | 2018.04.09 11.51.47,265 | Dateiname            : FireFoxVerwaltung.exe
FireFoxVerwaltung | 2018.04.09 11.51.47,265 | Fehlermeldung        : Connection is not opened yet
FireFoxVerwaltung | 2018.04.09 11.51.47,265 | Fehlerklasse         : EZDatabaseError
FireFoxVerwaltung | 2018.04.09 11.51.47,265 | Fehlerauslöser       : tmStart
FireFoxVerwaltung | 2018.04.09 11.51.47,265 | Klassenname          : TSpecialTimer
FireFoxVerwaltung | 2018.04.09 11.51.47,265 | Unit                 : ZAbstractConnection
FireFoxVerwaltung | 2018.04.09 11.51.47,265 | Fehleradresse        : 005FCE4F (001FBE4F)
FireFoxVerwaltung | 2018.04.09 11.51.47,265 | Modulname            : ZAbstractConnection.pas
FireFoxVerwaltung | 2018.04.09 11.51.47,265 | Prozedur             : TZAbstractConnection.CheckConnected
FireFoxVerwaltung | 2018.04.09 11.51.47,265 | Prozeduroffset       : 31
FireFoxVerwaltung | 2018.04.09 11.51.47,265 | Zeilennummer         : 942
FireFoxVerwaltung | 2018.04.09 11.51.47,265 | Modul                : 4194304 [400000]

Mit der Angabe von Unit ZAbstractConnection und Zeilennummer 942 weiß man dann schon sehr genau, wo es hakt. Und die Fehlermeldung Connection is not opened yet sagt einem dann auch schon recht genau, was da wohl falschgelaufen ist. Beim Fehlerauslöser handelt es sich hier um die Prozedur tmStart. Damit hat man dann auch die passende Stelle, an der man zum Debuggen mal mit dem Setzen eines BreakPoints anfangen kann.

Das hilft dann bestimmt auch dabei herauszufinden, ob es sich wirklich um das vermutete Netzwerkproblem handelt oder eventuell doch was Anderes dazwischenschießt.

Man kann dann im Dialog direkt einen Abbrechenbutton statt eines OK-Buttons einbauen, der beim Wegklicken das Programm auf jeden Fall beendet.

Per ShellExecute könnte man dann sogar das Programm sich selbst starten lassen.

Achso:
Die Fehlerausgabe aus der JCLDebug sieht nicht so aus, sie stellt lediglich die entsprechenden Informationen zur Verfügung, das Aussehen der Fehlermeldung bzw. der Logausgabe muss man dann schon selbst machen. Oder halt den Exceptiondialog aus der JCL nutzen: https://www.delphipraxis.net/1326309-post19.html oder selbermachen https://www.delphipraxis.net/1326340-post26.html