WPF fails in XP with 120 DPI, but not with 96 DPI

This is odd. I have a WPF application that works just fine in XP when the DPI is set to 96, but it fails with it set to 120. I tried this on two separate XP machines with the same results.

The error is right at initialize, prior to loading my exception handler.

Can you give me some tips on how I can debug this? Here is one of the the Event Log entries.

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.M开发者_JAVA百科SG 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()

Do you have Visual Studio installed on either of the machines in question? If so, I'd recommend running within the debugger, and configuring it to break as soon as the exception is thrown. From the Debug menu, open the Exceptions dialog, expand the Common Language Runtime Exceptions item, and then expand the System.IO section to find the System.IO.FileFormatException item. Ensure the first column (Thrown) is checked.

The reason I suggest this is that the stack trace you've shown looks like the stack for a rethrow, rather than the original exception. The exception is being thrown from the MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen method, which is the bit of the WPF message loop that detects unhandled exceptions. So that's not a useful thing to have shown up in the log - what you really want to know is where the exception was originally thrown from before WPF caught it. And you'll be able to do that if you ask the debugger to stop as soon as that exception is thrown.

That should shed more light on the issue.

If that's not an option, you might try attaching a handler to the Dispatcher.UnhandledException event, or the Application.DispatcherUnhandledException event and adding some custom logging code of your own. That might provide you with more information about where the exception was originally thrown from.

In the absence of more detailed logging, the obvious thing that occurs to me is this (although it's a long shot): do you have any unusual fonts installed on either system?

Thank you, for your help. The Inner Exception, was a touch more help in that it limited it to a Bitmap file error.

I eventually figured it out by gutting the copy of the project until it worked. The problem was starring me in the face. When the app loads it loads a main window. I deleted the Icon for this window early on, with no success. It wasn't until later that I circled back and also deleted the reference to the icon in the window that it loaded (Thank goodness), I was going insane. Perhaps it cached a copy of the removed icon in the Windows resources?

Anyway, I used our icon editor (Axialis IconWorkshop) to make sure every possible icon format was present; with no success.

I eventually just left the window iconless, and attempt to load the icon at load, if it fails, I just run iconless. This is not perfect, but in the limited situations where the icon causes a problem, I don't want it to crash for that.

On a side note, I had it also try to load an older/lower res. version of the icon, if the first one fails, and that does work in this situation.

I just wish the debugger was more help in pinpointing this.

You may want to look at the format of your icons. I had issues with a WPF app on pre-Vista platforms with the high res 256 icon. My design team supplied an icon which used PNG format for the 256 icon which older platforms couldn't load. Once that particular icon was changed to the bitmap format everything was fine.