Delphi 2010 und Application Verifier

TomyN · Verfasst: Do 02.02.12 08:57

Hallo,

nachdem bei einem User eine Access-Violation beim Programmstart auftritt, die ich nicht nachvollziehen kann, habe ich den Application-Verifier aktiviert.
Direkt beim Programmstart erhalte ich die folgende Meldung, dabei steht der Cursor in der IDE auf dem Begin im Projekt.

XML-Daten

markieren

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:

  <?xml version="1.0" encoding="UTF-8" standalone="no" ?> 
- <avrf:logfile xmlns:avrf="Application Verifier">
- <avrf:logSession TimeStarted="2012-02-02 : 07:37:10" PID="1848" Version="2">
- <avrf:logEntry Time="2012-02-02 : 07:37:11" LayerName="Heaps" StopCode="0x13" Severity="Error">
  <avrf:message>First chance access violation for current stack trace.</avrf:message> 
  <avrf:parameter1>0 - Invalid address causing the exception.</avrf:parameter1> 
  <avrf:parameter2>1f5039c - Code address executing the invalid access.</avrf:parameter2> 
  <avrf:parameter3>12f668 - Exception record.</avrf:parameter3> 
  <avrf:parameter4>12f684 - Context record.</avrf:parameter4> 
- <avrf:stackTrace>
  <avrf:trace>vrfcore!VfCoreRedirectedStopMessage+81 (d:\avrf\source\base\avrf\avrf30\vrfcore\stopredirect.cpp @ 103)</avrf:trace> 
  <avrf:trace>vfbasics!VerifierStopMessage+292 (d:\avrf\source\base\avrf\avrf30\providers\basics\basics.c @ 1214)</avrf:trace> 
  <avrf:trace>vfbasics!AVrfpCheckFirstChanceException+c8 (d:\avrf\source\base\avrf\vrfcommon\support.c @ 1108)</avrf:trace> 
  <avrf:trace>vfbasics!AVrfpVectoredExceptionHandler+16 (d:\avrf\source\base\avrf\vrfcommon\support.c @ 323)</avrf:trace> 
  <avrf:trace>ntdll!RtlDeleteAce+c36f ( @ 0)</avrf:trace> 
  <avrf:trace>ntdll!wcstol+b6 ( @ 0)</avrf:trace> 
  <avrf:trace>ntdll!KiUserExceptionDispatcher+e ( @ 0)</avrf:trace> 
  <avrf:trace>vfbasics!AVrfpStandardDllEntryPointRoutine+97 (d:\avrf\source\base\avrf\vrfcommon\dlls.c @ 741)</avrf:trace> 
  <avrf:trace>ntdll!LdrInitializeThunk+24 ( @ 0)</avrf:trace> 
  <avrf:trace>ntdll!LdrFindResourceDirectory_U+28d ( @ 0)</avrf:trace> 
  <avrf:trace>ntdll!RtlLookupElementGenericTable+185 ( @ 0)</avrf:trace> 
  <avrf:trace>ntdll!RtlLookupElementGenericTable+80 ( @ 0)</avrf:trace> 
  <avrf:trace>ntdll!KiUserApcDispatcher+7 ( @ 0)</avrf:trace> 
  </avrf:stackTrace>
  </avrf:logEntry>
  </avrf:logSession>
  </avrf:logfile>

Nach der Hilfe ist das ein Heap-Overflow oder ein Zugriff auf 'verbotene' Bereich im Heap. Wenn ich das Programm ohne den Verifier ausführe, treten (bei mir) keine Probleme auf.

Gibt es eine Möglichkeit herauszufinden, was hier die Ursache ist (wenn die die Code Adresse suchen lasse, bekomme ich nur ???).

Tomy

Moderiert von Martok: XML-Tags hinzugefügt

jaenicke · Verfasst: Do 02.02.12 19:08

Setze den Haltepunkt auf die initalization Sektion der ersten im Projektquelltext eingebundenen Unit oder auf _StartExe in der System-Unit. Das wird nämlich alles vor der ersten Zeile im Projektquelltext ausgeführt, weshalb ich den Fehler in einer der initialization Sektionen vermute.

TomyN · Verfasst: Do 02.02.12 20:53

Hi,

vielen Dank für die Antwort (und die Formatierung).

Der Stop erfolgt vor dem Aufruf der ersten Initizalisierung in den Units.
Interessant ist, dass ich beim Fortsetzen die Meldung 'Source geändert, neu compilieren?' erhalte (Delphi 2010, Update 5 ist drauf).
Die system.pas find ich zwar, aber irgendwie nimmt er die Breakpoints nicht, bzw. er compiliert die ganze Unit nicht (keine Punkte links).

Tomy

jaenicke · Verfasst: Fr 03.02.12 00:14

TomyN hat folgendes geschrieben :

Die system.pas find ich zwar, aber irgendwie nimmt er die Breakpoints nicht, bzw. er compiliert die ganze Unit nicht (keine Punkte links).

Projekt --> Optionen --> Compilierung --> Mit Debug-DCUs ;-)

TomyN · Verfasst: Fr 03.02.12 12:04

Hi,

danke. Ich bin hatte eigentlich erwartet, dass diese Option in der DEBUG Konfiguration schon aktiv ist.

Bei dem Fehler gibt's aber nix neues, er tritt schon vor _StartExe auf. Wahrscheinlich nix um sich drum Sorgen zu machen, wird so ähnlich sein wie der 'Es wird ein Speicher freigegeben, der eine aktive Mutex enthält' Fehler, dessen Ursache sich gezeigt hat:

App will kill it off anyways, so just let it leak :-)

Tomy


Delphi-Forum.de	Delphi-Library.de
C-Sharp-Forum.de	C-Sharp-Library.de