Access Violation in Win CE 6.0 R3 Dll-Projekt

[JoW (Gast)]

Mahlzeit!

Ich habe folgendes Problem: Ich habe auf einem XP System eine DLL 
Projekt erstellt, welches dort erfolgreich in einer Applikation 
verwendet wird. Nun habe ich diees DLL Projekt auf mein Win CE 6.0 R3 
portiert. Alles ging ohne Probleme kompilieren. Lass ich den Code 
laufen, so wirft exakt eine bestimmte Member-Methode einer Klasse ein 
Access Violation, sobald ich innerhalb dieser Methode eine externe 
Funktion oder eine andere Member-Methode aufrufe. Das Deklarieren und 
Initialisieren von lokalen Variablen und der Zugriff auf 
Member-Variablen funktioniert.

Selbst ein simples "printf("Hallo Welt!\n")" innerhalb dieser 
Member-Methode wirft eine Access Violation in "coredll.dll". Rufe ich 
eine Member-Methode auf, so führt meine DLL zu dieser Access Violation.

Woran kann dies liegen? Hat jemand einen guten Tip?

Vielen Dank!

Grüße, JoW

[JoW (Gast)]

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

[Peter II (Gast)]

hast du eventuell Debug und Release gemischt?

[JoW (Gast)]

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

[Peter II (Gast)]

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.

[JoW (Gast)]

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

[Peter II (Gast)]

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.

[JoW (Gast)]

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!

[Peter II (Gast)]

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.

[JoW (Gast)]

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

[JoW (Gast)]

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!

[Peter II (Gast)]

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.

[JoW (Gast)]

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

[Peter II (Gast)]

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.

[JoW (Gast)]

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

[Peter II (Gast)]

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.