2010-11-18 8 views
0

Dies ist seltsam. Ich habe eine WPF-Anwendung, die in XP gut funktioniert, wenn die DPI auf 96 gesetzt ist, aber es scheitert mit ihr auf 120. Ich versuchte dies auf zwei separaten XP-Maschinen mit den gleichen Ergebnissen.WPF schlägt in XP mit 120 DPI, aber nicht mit 96 DPI

Der Fehler ist richtig beim Initialisieren, vor dem Laden meines Ausnahmebehandlers.

Können Sie mir ein paar Tipps geben, wie ich das debuggen kann? Hier ist einer der Einträge des Ereignisprotokolls.


Event Type: Error 
Event Source: .NET Runtime 
Event Category: None 
Event ID: 1026 
Date:  11/17/2010 
Time:  7:37:15 PM 
User:  N/A 
Computer: EXIDA-100A3799C 
Description: 
Application: exSILentia3.exe 
Framework Version: v4.0.30319 
Description: The process was terminated due to an unhandled exception. 
Exception Info: System.IO.FileFormatException 
Stack: 
    at MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen(System.Object, System.Delegate, System.Object, Int32, System.Delegate) 
    at System.Windows.Threading.DispatcherOperation.InvokeImpl() 
    at System.Windows.Threading.DispatcherOperation.InvokeInSecurityContext(System.Object) 
    at System.Threading.ExecutionContext.runTryCode(System.Object) 
    at System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode, CleanupCode, System.Object) 
    at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object) 
    at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) 
    at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object) 
    at System.Windows.Threading.DispatcherOperation.Invoke() 
    at System.Windows.Threading.Dispatcher.ProcessQueue() 
    at System.Windows.Threading.Dispatcher.WndProcHook(IntPtr, Int32, IntPtr, IntPtr, Boolean ByRef) 
    at MS.Win32.HwndWrapper.WndProc(IntPtr, Int32, IntPtr, IntPtr, Boolean ByRef) 
    at MS.Win32.HwndSubclass.DispatcherCallbackOperation(System.Object) 
    at System.Windows.Threading.ExceptionWrapper.InternalRealCall(System.Delegate, System.Object, Int32) 
    at MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen(System.Object, System.Delegate, System.Object, Int32, System.Delegate) 
    at System.Windows.Threading.Dispatcher.InvokeImpl(System.Windows.Threading.DispatcherPriority, System.TimeSpan, System.Delegate, System.Object, Int32) 
    at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr, Int32, IntPtr, IntPtr) 
    at MS.Win32.UnsafeNativeMethods.DispatchMessage(System.Windows.Interop.MSG ByRef) 
    at System.Windows.Threading.Dispatcher.PushFrameImpl(System.Windows.Threading.DispatcherFrame) 
    at System.Windows.Threading.Dispatcher.PushFrame(System.Windows.Threading.DispatcherFrame) 
    at System.Windows.Threading.Dispatcher.Run() 
    at System.Windows.Application.RunDispatcher(System.Object) 
    at System.Windows.Application.RunInternal(System.Windows.Window) 
    at System.Windows.Application.Run(System.Windows.Window) 
    at exSILentia3.Application.Main() 
+0

Bitte legen Sie die Stack-Trace im Code-Format, so dass wir es leicht lesen können. – Brad

Antwort

2

Haben Sie Visual Studio auf einer der fraglichen Maschinen installiert? In diesem Fall würde ich empfehlen, den Debugger auszuführen und ihn so zu konfigurieren, dass er bricht, sobald die Ausnahme ausgelöst wird. Öffnen Sie im Menü Debug das Dialogfeld Ausnahmen, erweitern Sie das Element Common Language Runtime Exceptions, und erweitern Sie dann den Abschnitt System.IO, um das Element System.IO.FileFormatException zu suchen. Stellen Sie sicher, dass die erste Spalte (Geworfen) aktiviert ist.

Der Grund, den ich vorschlagen, ist, dass die Stack-Ablaufverfolgung, die Sie gezeigt haben, eher wie der Stapel für einen erneuten Durchlauf aussieht, als die ursprüngliche Ausnahme. Die Ausnahme wird von der MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen-Methode ausgelöst, bei der es sich um das Bit der WPF-Nachrichtenschleife handelt, die nicht behandelte Ausnahmen erkennt. Das ist also keine nützliche Sache, um im Log aufgetaucht zu sein - was Sie wirklich wissen möchten, ist, wo die Ausnahme ursprünglich geworfen wurde, bevor WPF sie erwischt hat. Und Sie können das tun, wenn Sie den Debugger auffordern zu stoppen, sobald diese Ausnahme ausgelöst wird.

Das sollte mehr Licht auf das Thema werfen.

Wenn dies keine Option ist, können Sie versuchen, einen Handler an das Ereignis Dispatcher.UnhandledException oder das Ereignis Application.DispatcherUnhandledException anzuhängen und einen eigenen benutzerdefinierten Protokollierungscode hinzuzufügen. Dadurch erhalten Sie möglicherweise mehr Informationen darüber, woher die Ausnahme ursprünglich stammt.

In Ermangelung einer ausführlicheren Protokollierung ist die offensichtliche Sache, die mir auffällt, dies (obwohl es eine lange Geschichte ist): Haben Sie ungewöhnliche Schriftarten auf beiden Systemen installiert?

+0

Ja .. VS stürzte vorher beim Versuch, die App zu laden, mit "kein Quellcode verfügbar", und ebenso vage von einem Fehler. –

+0

Nun gut, aber mein Punkt war, dass ich den Stack-Trace sehen wollte, wo er wirklich abgestürzt ist. Leider erhalten Sie das standardmäßig nicht - Sie erhalten den unspezifischen Stack-Trace, den Sie gepostet haben. Wie ich oben sagte, war die ganze Idee, eine nützlichere Stapelspur zu bekommen. Die Ausnahme wird genauso "vage" wie zuvor sein, weil ich die gleiche Ausnahme erwarte, aber wenn wir sehen können, * wo * es geworfen wird, könnte das helfen, das Problem zu lösen. –

0

Vielen Dank für Ihre Hilfe. Die Inner Exception war ein wenig hilfreicher, da sie auf einen Bitmap-Dateifehler beschränkt war.

Ich fand es schließlich durch Aushöhlen der Kopie des Projekts, bis es funktionierte. Das Problem war, mich im Gesicht zu sehen. Wenn die App geladen wird, wird ein Hauptfenster geladen. Ich habe das Icon für dieses Fenster frühzeitig gelöscht, ohne Erfolg. Erst später kreiste ich zurück und löschte auch den Verweis auf das Icon im geladenen Fenster (Gott sei Dank), ich wurde wahnsinnig. Vielleicht hat es eine Kopie des entfernten Symbols in den Windows-Ressourcen zwischengespeichert?

Wie auch immer, ich verwendete unseren Symboleditor (Axialis IconWorkshop), um sicherzustellen, dass jedes mögliche Symbolformat vorhanden war; ohne Erfolg.

Ich verließ schließlich das Fenster ohne Symbol, und versuchen, das Symbol beim Laden zu laden, wenn es fehlschlägt, ich laufe einfach ohne Symbol. Das ist nicht perfekt, aber in den begrenzten Situationen, in denen das Symbol ein Problem verursacht, möchte ich nicht, dass es abstürzt.

Nebenbei bemerkt, ich hatte es auch versuchen, eine ältere/niedrigere res zu laden. Version des Symbols, wenn das erste fehlschlägt, und das funktioniert in dieser Situation.

Ich wünschte nur, der Debugger war mehr Hilfe bei der Ermittlung dieses.

0

Sie können sich das Format Ihrer Symbole ansehen.Ich hatte Probleme mit einer WPF-App auf Pre-Vista-Plattformen mit dem hochauflösenden 256-Symbol. Mein Designteam lieferte ein Symbol, das das PNG-Format für das 256-Symbol verwendete, das ältere Plattformen nicht laden konnten. Sobald dieses bestimmte Symbol in das Bitmap-Format geändert wurde, war alles in Ordnung.

Verwandte Themen