Oft Zugriffsverletzung bei Debugger-Start F9

[menschjens]

Hallo,

Ich nutze zur Zeit Delphi XE Update 1 unter Windows XP Prof. SP2, das selbe Problem hatte ich aber früher schon mal mit Delphi 2007, was mich damals zurück zu Delphi 2006 getrieben hatte.
nach gut 2 Tagen Suche und Herumprobieren bin ich nun ratlos und hoffe auf eure Hilfe:

Der Programmstart über Umsch+Strg+F9 (bzw. 'Start/Ohne Debugger ausführen') funktioniert immer.
Der Programmstart über F9 (bzw. 'Start/Start') führt bei mir manchmal zum einwandfreien Starten meiner Programme (siehe 'Geht.gif'), manchmal aber zu einer Access Violation. Ich habe bereits mit allen möglichen Debugger- / Compiler- / Linker-Optionen herumgetestet - keine Veränderung.

Es ist kein Zusammenhang erkennbar, wann es funktioniert und wann nicht. Die Zugriffsverletzung wird bereits am 'begin' des Hauptprogramms, also noch vor 'Application.Initialize;' ausgelöst!

Zuerst wird im Ereignisprotokoll ein 'Nicht-Benutzer-Haltepunkt' angezeigt (siehe 'Geht nicht 1.gif' oder auch 'Geht icht 1a.gif'). Wenn ich dann schrittweise weiter debugge, kommt die Meldung mit der 'Access Violation' ('Geht nicht 2.gif'). Wenn ich die dann mit 'OK' bestätige, lande ich im CPU-Fenster (siehe 'Geht nicht 4.gif').

Um auszuschließen, dass die Ursache in meinem Programm liegt, habe ich es mit einem leeren Form getestet - das selbe Problem.

Entsprechend einigen Tips in diesem Forum habe ich die Produktschutz-Einstellungen von 'Avira Antivir Personal' nach Anleitung verändert mit Neustart usw. - keine Veränderung.

Ich habe 'Avira Antivir Personal' nun entfernt (vollständig) - keine Veränderung.

Ich habe die 'Virtual Controls' und 'Abbravia' vollständig entfernt - keine Veränderung.

Irgendwie scheint es ja wohl die IDE zu betreffen.
Die Situation ist zwar nicht untragbar, schließlich funktioniert F9 ja auch immer mal wieder.
Aber Ihr wiss ja selber, wie oft man den Debugger startet. Es nervt gewaltig, wenn er es immer nur ab und zu mal tut...

Hat irgend jemand noch eine zündende Idee, was ich noch machen könnte?

Jens

[CCRDude]

Auf den Screenshots kann ich nicht viel erkennen, aber das abgebildete begin ist vielleicht der Begin der Hauptprojektdatei, aber nicht zwingend der des eigenen Codes. Davor kommt noch jede Menge initialization-Krams, etwa von eingebundenen Units.

Für Krams, der vor Application.Initialize kommt, hilft mir eigentlich nur, das Debuggen direkt mit F7/F8 zu starten und durch das initialization von allen genutzten Units durchzusteppen, bis ich den Fehler gefunden habe (bzw. habe ich dafür inzwischen Debug-Code in allen eigenen initialization-Teilen; darf es kommerziell sein, fällt mit da etwa SmartInspect ein).

Oder tritt die AV mit F7/F8 statt F9 gar nicht auf?

[menschjens]

Also mit nur F8 kommt die Schutzverletzung auch manchmal.
Und 1xF7 und ab da nur noch einige F8's führten gerade mal eben zu einem Totaleinfrieren von Windows... kein Mousezeiger, keine Tastaturreaktion - also auch kein Taskmanager... ---> Reset am Computer
So was hatte ich in den letzten Jahren nicht...

[menschjens]

So, nach dem Absturz also noch mal getestet:
Habe einen Breakpoint auf das 'begin' vor dem 'Application.Initialize' des Hauptprogramms gesetzt. Schon der erste F7-Aufruf nach diesem Breakpoint brachte einen 'access violation at 0x7c976668: access of address 0x01000000' und schickte mich dann ins CPU-Fenster.

[menschjens]

Die Stelle scheint auch ab und zu zu wechseln. Laut Ereignisprotokoll passiert es beim Laden verschiedener Module - meistens aber nach OLEAUT32.DLL.

[menschjens]

Gerade nochmal mit F4 auf das erste 'begin' gesprungen und F7 legte wieder mein ganzes System auf Eis. Also auf das schrittweise Testen hab ich unter diesen Umständen keine Lust mehr.
Kann ich irgendwie kontrollieren, ob die betreffenden Module an die richtigen Stellen im Speicher geladen werden?
Kann doch nicht sein, dass ich mir Delphi XE umsonst gekauft habe!!!

[haentschman]

Hallo...

Zitat:

Kann doch nicht sein, dass ich mir Delphi XE umsonst gekauft habe!!!

...dem widersprechen die tausenden funktionierenden Versionen. In diesem Falle mußt du vor der eigenen Tür kehren...

Zum Thema kann ich dir leider nicht helfen

Ein paar Fragen:
- das Net Framework wurde bei der Delphi Installation installiert oder war es vorhanden ?
- gab es bei der Installation irgend welche Ungereimtheiten ?

[menschjens]

Das .Net-Framework ist seit 2009 bei mir installiert. (1.1 bis 3.5).
Könnte diese Info helfen?
Und Ungereimtheiten gab es nicht.

[jaenicke]

Ich würde dir einmal raten:
Erstens den Arbeitsspeicher zu prüfen. Das geht bei aktuellen Windowsversionen mit der Windows-CD oder (bzw. bei XP oder früher nur) z.B. mit memtest86.
Und zweitens rate ich dazu Windows einmal frisch zu installieren. Du kannst es ja einmal parallel installieren oder dein aktuelles System vorher sichern.

Denn ich vermute, dass entweder mit der Hardware (und da kommt vor allem der RAM in Betracht) oder mit Treibern etwas nicht in Ordnung ist.

[Satty67]

Versuche mal ein Micosoft Update (also nicht nur Windows Update).

Bin mir nicht ganz sicher, hatte mit .NET in der Basis-Installation (ohne Patches) schon öfters seltsames Verhalten (allerdings nicht mit Delphi)

€: Notfalls oder auf jeden Fall auch nach Jaenickes Vorschlag.