Delphi6-Anwendung gestartet von "fremdsprachigen" Verzeichnis

[Bernhard Geyer]

Ich habe hier eine Anwendung die mir jetzt auf einem russischen System probleme bereitet.

Hat das Verzeichnis in der die Anwendung gestartet wird kyrilische Zeichen und Leerzeichen im (letzten?) Pfadteil, so kracht die Anwendung mit komischten Fehlermeldung, oft in der ntdll.dll und hier sowie ich durch Debuggin heraus gefunden habe beim handieren mit Strings.

Wenn ich mit FastMM-Debugausgaben arbeiten sagt er mir oft das Objekte mehrmals freigeben wurde und ähnliches.

Gerade habe ich heraus gefunden das bei einem Start mit der 8.3-Datei/Pfadnamen (Batch-Datei nötig - Start über Link sorgt beim speichern für automatisches Umwandeln der 8.3 in richtigen Pfadangaben) die Abstürze verschwinden.

Ich bin mit meinem Debug-Ansätzen langsam am Ende.
Hättet Ihr Ideen welche checks ich durchführen könnte bzw. welche (Win)API-Funktionsaufrufe das verursachen könnten.
Die Anwendung ist u.a. mit hilfe vom ElPack GUI-Technisch Unicode-Enabled. Einzig im Bereich Filenamen-Handling ist noch vieles nicht umgestellt. Der o.g. kyrische Pfadteil hat aber nur Zeichen die per Charset auf einem kyrisch eingestellten Windows auch erreichbar sein (also nur die 127 gebräuchlichen Zeichen die als $80...$FF "eingeblendet" werden.

[jaenicke]

In den Stacktraces ist da kein Hinweis zu finden? Kannst du die vielleicht mal anhängen? Also bei einem solchen Speicherbereich den Stacktrace vom Allozieren und den vom Deallozieren meine ich. Ggf. mit höherer StackTraceDepth (in FastMM.pas), wenn die sonst nichts aussagen.

[himitsu]

Die ntdll.dll ist oftmals letzendlich der ausführende Teilder meisten Dateifunktionen ... wenn es dort kracht, liegt der Fehler meißt aber im aufrufenden Teil (falsche Parameter übergeben und so).

Zitat:

Einzig im Bereich Filenamen-Handling ist noch vieles nicht umgestellt.

Wenn Man mit Dateinamen in als Unicode-Strings anfängt und dann intern nur den Typ konvertiert, aber nicht den Inhalt (LongFileNames <> ShortFileNames), dann könnte schonmal hier und da etwas schief laufen.
Auch wenn ich da eher andere Fehler, ala "Datei nicht gefunden" erwarten würde ... aber wenn man z.B. eine ordentliche Fehlerbehandlung vergißt, dann sind die Nachfolgefehler schon viel weitreichender und würden mit den genannten Symptomen schon übereinstimmen.

[Bernhard Geyer]

Also als genaue Fehlermeldung habe ich schon mal

Code:

Zugriffsverletzung bei Adresse 77259C5F in Modul 'ntdll.dll'. Lesen von Adresse 2E3B6AE0
[77259C5F] RtlSizeHeap + $73

(mit Hilfe von den Jedi-Debug-Funktionen


Callstack muss ich schauen das ich wieder bekomme (aktuell kommt da beim Remote Debugger (D6) nix rüber bzw. er bleibt nicht stehen ...

[Bernhard Geyer]

So. Eigentlich wollte ich noch Callstacks posten die ich noch gefunden habe, aber ich habe jetzt eine (fast) Lösung für mein Problem und auch den (teilweise?) Schuldigen gefunden: TNTForm!

Hab jetzt auf die LMDForms (mit Widestring als Caption) umgestellt sowei eine Anpassung an an ElPack-Units vorgenommen und jetzt kommt im Entwicklerzweig nicht mehr die Fehlermeldung.