Question

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.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()

Answer 1

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?