Hey, wo ist meine Exception hin?

Ich hatte kürzlich den Fall eines Programms, welches munter mit einem uninitialisierten Pointer hantierte und trotzdem keine Exception auslöste oder von Windows gestoppt wurde. Die tl;dr-Version des Resultats meiner darauf folgenden Abklärung: Wenn 32bit-Programme unter einem 64bit-Windows laufen, werden unter gewissen Umständen Fehler wie ungültige Zugriffe auf Speicher einfach verschluckt. Der Stack wird abgebaut und das Programm läuft weiter, unklar an welcher Stelle, in einem wahrscheinlich inkonsistenten Zustand. Es sieht so aus, als könne man im Moment nichts dagegen unternehmen.

Die lange Version meiner Geschichte:

In unseren „native“ d.h. C++-Programmen haben wir bei Windows mit Hilfe des WIN32-API-Aufrufs SetUnhandledExceptionFilter eine Prozedur installiert, welche sämtliche Laufzeitfehler melden und in einem Log auf Disk vermerken soll.

Beim eingangs erwähnten Fehler mit einem ungültigen Pointer wurde diese Prozedur allerdings nicht aufgerufen, und es passierte mit und ohne Debugger gleichermassen folgendes: Der Fehler wurde verschluckt und das Programm fuhr fort, jedoch an einer unklaren Stelle (Step Into und Step Over im Debugger versagten beide, so dass man nicht sah, wo), in einem ziemlich „wackeligen“ internen Zustand.

Nach einigem Googlen fand ich dann den folgenden Blog-Eintrag: The case of the disappearing OnLoad exception.

Dieser bestätigt: Wenn während der Ausführung eines 32bit-Programms auf einem 64bit-Windows die Prozeduraufrufe so geschachtelt sind, dass es „zwischendurch“ Prozeduren von Windows selbst hat, z.B. wenn man sich in einer eigenen WindowProc befindet, und dann ein Fehler passiert, wird dieser verschluckt.

Als Lösung wird beschrieben, man solle sein Programm per Manifest explizit als unterstützt Windows 7 markieren. Wie genau sich das Programm verhalten soll, wenn man das macht, wurde mir anhand der Ausführungen im Blog-Eintrag nicht ganz klar, aber auf jeden Fall werden Fehler offenbar nicht mehr einfach ignoriert.

Ok, hab‘ ich ausprobiert, eine solche Markierung ist ja nicht schwierig, wie Microsoft hier beschreibt. Resultat: Keine Änderung.

Ich vermute, der Grund dafür ist diese Geschichte: Application Manifest may be ignored in Windows 7 x64: Man kann zwar sagen, man unterstütze Windows 7, aber ein 64bit Windows 7 lässt das 32bit-Programm unter Umständen trotzdem nur als Windows Vista laufen, und da werden Fehler offenbar noch ignoriert.

Es gab zwar einmal einen Hotfix, um dieses Problem zu beheben, aber der will auf meinem Windows 7 SP1 nicht installieren, der Hotfix aus dem Jahr 2010 ist wohl nur für Windows 7 „pur“.

Mir scheint, hier verheddert man sich prächtig in einem Gestrüpp von Windows-Fehlern und -Unzulänglichkeiten; auf jeden Fall habe ich bis jetzt keine Verbesserung hingekriegt.

Advertisements
Veröffentlicht in Keine Kategorie. Schlagwörter: , , . Leave a Comment »

Alles wird unscharf

Fast auf den Tag genau vor 1 Jahr habe ich in diesem Eintrag vom „unscharfen“ Text in WPF-basierten Applikationen geschrieben. Seither gehört das Wort unscharf zu den absoluten Top-Such-Begriffen, mit denen dieses Blog gefunden wird, was darauf schliessen lässt, dass die Sache einige Leute beschäftigt, wenn nicht sogar nervt.

Es sieht so aus, als wäre Microsoft unterwegs zu einer überraschenden Lösung für dieses Problem, die man als Bestandteil von Windows Vista und Windows 7 betrachten kann: Man macht einfach Text generell unscharf…

Windows 7 verwendet ClearType für Text per Default systemweit, mit nur wenigen Ausnahmen wie etwa der Shell, was eben zur angesprochenen leichten Unschärfe führt. Allerdings muss man sagen, dass Microsoft ClearType um einiges verbessert hat und auch ein eigenes Tuning-Tool dafür mitliefert, damit man auf seiner Hardware das Optimum betreffend Darstellung herausholen kann.

Es gibt in Windows 7 sogar eine etwas versteckte Option, mit der man ClearType ausschalten kann, die z.B. hier (für das englische Windows 7) beschrieben ist, aber so ganz will das nicht klappen: Vieles wird nach dem Ausschalten der Option Smooth edges of screen fonts zwar wieder pixel-scharf, aber Dinge wie die Anzeige der Uhrzeit, Tooltips oder gewisse Kolonnen-Überschriften im Explorer bleiben völlig unbeeindruckt bei der Verwendung von ClearType, und WPF-Applikationen wie etwa das neue Visual Studio 2010 sowieso.

Ich habe mich gefragt, ob die weitgehende Verwendung von ClearType auch damit zusammenhängt, dass Dinge wie der Explorer von Windows 7 als WPF-Applikationen neu geschrieben worden sind. Es ist häufig schwierig, Informationen darüber zu finden, wie genau Microsoft Windows-Interna implementiert; so auch in diesem Fall. Es scheint allerdings unter interessierten Leuten einen gewissen Konsens darüber zu geben, dass das Windows-7-GUI nicht in WPF implementiert sein kann, wie z.B. in einem Posting im Rahmen dieser Diskussion ausgeführt. WPF heisst managed code, der einen gewissen Geschwindigkeitsverlust mit sich bringen kann und für das Framework einiges an Speicher benötigt – beides Dinge, die Microsoft vermeiden musste, um Windows 7 gegenüber Vista deutlich abzuspecken und schneller zu machen, damit es z.B. Netbook-tauglich wird.

Ich denke nicht, dass man das als Votum gegen WPF deuten sollte, im Stile von „Ja, wenn nicht mal Microsoft selbst Dinge mit Hilfe von WPF implementiert…“. Normale Windows-Business-Applikationen sind nun mal nicht dasselbe wie Kern-Bestandteile von Betriebssystemen, wo ganz andere Bedingungen und Anforderungen die Wahl der Mittel erheblich einschränken.

Veröffentlicht in Keine Kategorie. Schlagwörter: , . 3 Comments »