Access Violation in Win CE 6.0 R3 Dll-Projekt

Edit: Das Dll Projekt wurde als Subproject im Platform Builder angelegt. 
Also kein Exportieren und Einbinden eines bestimmten SDKs notwendig.

hast du eventuell Debug und Release gemischt?

Hi!

Also die Dateien werden in "obj\...\retail" erstellt und dann in das 
Release-Verzeichnis unter "...\retail" kopiert, worauf dann das MakeImg 
ausgeführt wird.

Global habe ich Release eingestellt. Das wird dann doch für das 
Subproject übernommen, oder?

Grüße, JoW

JoW schrieb:
> Also die Dateien werden in "obj\...\retail" erstellt und dann in das
> Release-Verzeichnis unter "...\retail" kopiert, worauf dann das MakeImg
> ausgeführt wird.

dann sollte das passen.

Warum debugs du die Stelle nicht einfach mal? Dann sieht man doch worauf 
er zugreifen will.

Ja, das ist ein wenig ein Problem. Ich hab erstens kein zuverlässiges 
Debug-Image. Außerdem müsste ich dieses auf Grund der Größe und des 
begrenzten RAMs meiner Zielhardware jedes mal bei einer Änderung in den 
Flash schreiben. Dies dauert ca. 30-40 Minuten. Davon möchte ich als 
eher absehen. Klingt doof, aber geht halt nicht.

Ich kann aber mit dem KITL auch im Release durch den Code-Steppen, die 
Sprungweite stimmt dann zwar nicht immer - er springt manchmal in eine 
if, obwohl er dies nicht tut - aber man kann sehen, wo es hängt.

Dabei habe ich eben festgestellt, dass alle anderen Methoden der Klasse, 
die bis zu der Zugriffsverletzung aufgerufen werden, erfolgreich 
terminieren. Erst in dieser einen Methode tritt, egal was man macht - 
Aufrufen einer Member-Methode oder einer externen Funktion wie 
prinft(..) - die Zugriffsverletzung ein.

Greets, JoW

JoW schrieb:
> Ich kann aber mit dem KITL auch im Release durch den Code-Steppen, die
> Sprungweite stimmt dann zwar nicht immer - er springt manchmal in eine
> if, obwohl er dies nicht tut - aber man kann sehen, wo es hängt.

dann must du einfach mal auf ASM umschalten und schauen was da genau 
passiert.

Das habe ich noch nie im Platform Builder gemacht. Wie funktioniert das? 
Er unterbricht ja das Steppen, sobald ich an einer dieser Fehlerstellen 
weiterlaufe.

Danke!

JoW schrieb:
> Das habe ich noch nie im Platform Builder gemacht. Wie funktioniert das?

keine Ahnung wie es dort genau geht, aber bei den anderne IDEs von MS 
kann man einfach per Rechte maustaste auf ASM umschalten und dann dort 
im einzelschritt steppen.

Das hier spuckt mir das Debug-Fenster im Visual Studio aus:

72246 PID:41b000a TID:528000a Exception 'Data Abort' (4): Thread-
       Id=0528000a(pth=895e29c0), Proc-Id=041b000a(pprc=8952b364)
      'MeineTestExe.EXE', VM-active=041b000a(pprc=8952b364)
      'MeineTestExe.EXE'

72246 PID:41b000a TID:528000a PC=40051544(coredll.dll+0x00041544)
        RA=4091ef18(MeineDLL.dll+0x0001ef18) SP=001ffdec, BVA=001ffddc

Und an der letzten Zeile wirft die coredll.dll die Access Violation, 
wenn ich als erste aufgerufene Funktion an dieser Stelle ein 
printf("...\n") einfüge. Was sagt mir dies nun?

printf:
40051540    mov         r12, sp
40051544    stmdb       sp!, {r0 - r3}

Danke für Rat und Tat!

JoW schrieb:
> Was sagt mir dies nun?
>
> printf:
> 40051540    mov         r12, sp
> 40051544    stmdb       sp!, {r0 - r3}

dafür müsste man etwas mehr wissen, was steht in Rl2, was steht in sp, 
was steht in R0 oder R3.

dann muss man auch etwas mehr vom ASM sehen.

Ich werde mich mal mit dem ASM Code auseinandersetzen.

Woran könnte es denn grundsätzlich liegen, dass exakt eine 
Member-Methode keinerlei externe Funktionen oder andere Member-Methoden 
aurufen kann?

Viele Grüße, JoW

eigentlich nur wenn der "this" zeiger unsinn ist. Dann geht der Zugriff 
auf die Members der Klasse schief. Oder der Fehler ist schon vorher 
passiert (z.b. es wurde speicher überschrieben) und wirkt sich erst beim 
nächsten zugriff auf dem Stack aus.

"Access Violation" ist halt ein ungültiger speicherzugriff, dafür müsste 
man erstmal wissen warauf er zugreifen wollte.

Nützt es evtl. wenn ich mir den this-Pointer im Konstruktor mal ausgeben 
lasse und später direkt zu Beginn der "fehlerhaften" Methode?

Grüße, JoW

JoW schrieb:
> Nützt es evtl. wenn ich mir den this-Pointer im Konstruktor mal ausgeben
> lasse und später direkt zu Beginn der "fehlerhaften" Methode?

schaden tut es auf jeden fall nicht.