![]() |
Zugriffsverletzung sofort nach Programmstart
Hallo,
ich erhalte direkt nach Programmstart die EAccessViolation: "Zugriffsverletzung bei Adresse 0040DEE4 in Modul 'Meine.exe'. Lesen von Adresse 06B64000.". Das Exception-Log sieht so aus:
Code:
Was kann das sein? Sieht ja so aus, als ob die EAccessViolation ganz früh auftritt, noch bevor irgendein Code von mir ausgeführt wurde. An der System.pas wurde nichts geändert. Merkwürig ist auch die Zeulennumer 12238 identisch an 3 Stellen in der System.pas obwohl in den 3 Fällen jeweils andere Funktionen aufgerufen wurden, die nicht an der selben Stelle sind.
main thread ($61e0):
0040dee4 +048 Meine.exe System 12238 +0 Pos 020f4a60 +10c Meine.exe ZipForge initialization 0040bfe2 +042 Meine.exe System 12238 +0 InitUnits 0040c04b +03f Meine.exe System 12238 +0 @StartExe 0041452a +042 Meine.exe SysInit @InitExe 020f9917 +01b Meine.exe MeinProject 127 +0 initialization 767d6357 +017 KERNEL32.DLL BaseThreadInitThunk |
AW: Zugriffsverletzung sofort nach Programmstart
Was steht denn an der geloggten Stelle der initialization Sektion der ZipForge-Unit?
|
AW: Zugriffsverletzung sofort nach Programmstart
Ich würde mit dem Debugger einen Haltepunkt an der ersten Stelle setzen (zum Beispiel im OnFormCreate sofern vorhanden) und mich dann Zeile für Zeile durcharbeiten. Dann solltest du eigentlich relativ schnell sehen wo es kracht.
|
AW: Zugriffsverletzung sofort nach Programmstart
@scrat: Dort kommt er garnicht erst bis hin :zwinker:
Es knallt bereits bei der Initialisierung einer Units, also noch vor seinem eigenen Code. (außer er hat selbst was in die Initialization reingemacht) Die Initialisierung des Programms und der Units kommt im/vorm ersten BEGIN in der DPR. Und jupp, die Ausführung kommt bis ZipForge.pas-initialization und danach knallt es, also würde ich auch dort mal nachsehen. > "initialization" und ob ein "class contructor" in der Unit steht und dort den Haltepunkt rein. (wenn diese Unit mit Debuginfos kompiliert wurde) Wo system.pas dran steht, das muß nicht in dieser Unit drin sein. Alles was zur Compilermagic gehört und wo der Compiler eigene Dinge einfügt, das wird mit dieser Quelle angezeigt. |
AW: Zugriffsverletzung sofort nach Programmstart
Zitat:
|
AW: Zugriffsverletzung sofort nach Programmstart
Wenn das nicht zuviele Probleme macht, nutz am besten die 7z.dll und den Wrapper der in der Jcl ist.
Wenn es da Probleme gibt, kann man die selber beseitigen. |
AW: Zugriffsverletzung sofort nach Programmstart
Zitat:
|
AW: Zugriffsverletzung sofort nach Programmstart
Dann wirst dich wohl nur an den Hersteller von ZipForge wenden können.
ZipForge.pas > initialization > Byte 268 knallt ... vermutlich irgendwas mit ![]() Eventuell kann er dir auch eine Version mit Debuginfos zur Verfügung stellen, damit du im Stacktrace vielleicht mehr siehst. Delphi dort installieren wird ja wohl nicht gehen, dann bliebe maximal noch der Remotedebugger über eine VPN zu deinem Delphi und schrittweise nachsehn was du da im Assembler entziffern kannst. |
AW: Zugriffsverletzung sofort nach Programmstart
Wann hatte es denn zuletzt funktioniert? Gab es seitdem Änderungen im Repository? Wenn ja, würde ich diese erst einmal rückgängig machen und es dann erneut testen.
Wenn es keine Änderungen an den Quelltexten gab, würde ich alle Komponenten neu installieren. Funktioniert die ZipForge-Unit denn in einem neuen Projekt? Zur Fehlersuche bleibt ansonsten noch nach und nach alles aus dem Projekt hinauszuwerfen bis der Fehler nicht mehr auftritt. Und dann schauen wann er wieder auftritt. Als erstes würde ich einfach alles, das die ZipForge-Unit verwendet, auskommentieren und es dann ohne diese Unit testen. Es kann sich allerdings auch um einen Speicherfehler handeln, der nur zufällig dort auftritt. Daher wäre es auch sinnvoll zu schauen welche initialization Abschnitte eigentlich vor dem Fehler durchlaufen werden. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 21:58 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz