Zugriffsverletzung 0x00.. in user32.dll auf chinesischem Server

[Sherlock]

Ins Blaue hinein: Kann es sein, daß bei der Übersetzung eigentlich interne Bezeichner oder Unitnamen oder sowas in der Art übersetzt wurden/werden? Im europäischen Umfeld macht das ja weniger was aus, aber sobald da chinesische Zeichen reinrutschen könnte das Problematisch werden.

Sherlock

[mquadrat]

Das ganze ist sehr diffus. Ich habe immerhin jetzt die Stelle gefunden. Den Fehler verursacht hat ein TChart, obwohl der Fehler erst nach(!) dem Release des entsprechenden Formulars geworfen wird. Ebenso trittder Fehler nur auf, wenn das Objekt, das in diesem Form dargestellt wird, einen bestimmten Status hat. Der Status wirkt sich aber eigentlich gar nicht auf dieses TChart aus.

Wenn ich etwas Luft habe, werde ich da mal weiter testen.

[Dejan Vu]

Das ist ein Seiteneffekt: Der Fehler ist vermutlich ganz woanders. Hast Du dein Projekt mal mit Range- und Overflowchecks kompiliert? Mal FastMM mit FullDebugMode probiert? Erst wenn letzteres im normalen Betrieb (was deinen komischen Fehler verursacht) ohne Meckerei durchläuft, ist es ein Problem.

[Redeemer]

Ich weiß nicht, ob das mit deinem Problem zusammenhängen kann, aber ein Projekt von mir zeigte bei einem koreanischen Nutzer koreanische Zeichen als sehr seltsame andere Zeichen an, wenn es mit XE2 kompiliert wurde. Mit 2009 hingegen kein Problem. Falls du andere Compiler zur Hand hast - da gab es ja mal die Aktion, bei XE2 alle Vorgänger bis 2007 dazu zu kriegen - probier's mal damit.

Weitere Idee: Lädt dein Projekt über TStrings/TStringList Textdateien, die nicht in Unicode vorliegen und Nicht-ASCII-Zeichen enthalten?

[Memnarch]

Etwas auf das ich noch nicht gestoßen bin(weil noch nie mit Chinesischen Zeichen gearbeitet habe), aber mir habe mal sagen lassen:
Chinesisch nutzt Surrogate-Pairs in strings. das heißt, dass 2 Chars ein Chinesisches Zeichen ergeben. Wird so eines vllt ausversehen auseinander gepflückt bei einer String-Operation und verursacht murks?

[himitsu]

Alle Zeichen im Bereich von #0 bis #$FFFF sind ganz normale UCS2-Chars.
Falls Chinesisch Zeichen von #$010000 bis #$10FFFF nutzt, dann sind diese als Surrogates im String kodiert,
aber normales Stringoperationen/-konvertierungen sollten Diese eigentlich selten zerlegen.
Und ja, es sind zwar viele chinesische Zeichen in der BMP (Basic Multilingual Plane = bis #$FFFF), aber ein großer Teil liegt auch in den Surrogates.

Was man mal machen könnte:
- das Programm mit DebugDCUs (RET+VCL) kompilieren
- Fehlersuchcodes ala Eurekalog oder MadExcept einbauen (oder man debuggt das selber)
- und vielleicht auch noch einen FastMM im FullDebugMode

[Der schöne Günther]

Ich kenne mich da überhaupt nicht aus, aber das GetKeyboardLayout im Stacktrace hat nichts zu bedeuten?

[himitsu]

Wenn das GetKeyboardLayout Probleme macht, dann wäre wohl eher der entsprechende Rechner im Arsch.

Ich hätte eher bei den übergebenen Parametern die Probleme vermutet, aber diese API hat eigentlich keine problematischen Parameter, wo man z.B. ausversehn ein nil (siehe Überschrift) übergeben könnte.

Das Problem ist hier auch, daß man nicht genau sieht um welches Control es beim TWinControl.MainWndProc handelt.
Eventuell ist das Control auch weg und hier stünde dann ein NIL, aber das würde ich eigentlich ausschließen, da es für nichtexistierende Controls keine Messages mehr gibt, weil Diese eigentlich automatisch gelöscht werden. Und außerdem hoffe ich mal BorCodEmba hat bei der Umwandlung von HWND in TWinControl abgefangen, wenn das Control nicht gefunden wird, oder so.

Drum ja die Hoffnung, daß man mit mehr Debugginfos auch mehr im Stacktrace sieht.