WPF在XP中以120 DPI失败，但不能以96 DPI失败

这很奇怪。我有一个WPF应用程序，当DPI设置为96时，它在XP中工作得很好，但是当它设置为120时，它失败了。我在两台不同的XP机器上尝试了这个方法，得到了相同的结果

在加载我的异常处理程序之前，初始化时就出现了错误

你能给我一些关于如何调试这个的提示吗？下面是一个事件日志条目

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

---

您是否在任何一台机器上安装了Visual Studio？如果是这样，我建议在调试器中运行，并将其配置为在引发异常时立即中断。从调试菜单中，打开异常对话框，展开公共语言运行时异常项，然后展开System.IO部分以查找System.IO.FileFormatException项。确保选中了第一列（抛出）

我建议这样做的原因是，您所显示的堆栈跟踪看起来像是用于重试的堆栈，而不是原始异常。异常正在从

MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen

方法引发，该方法是检测未处理异常的WPF消息循环的位。因此，在日志中显示这并不是一件有用的事情——您真正想知道的是，在WPF捕获异常之前，异常最初是从哪里抛出的。如果在抛出异常时要求调试器立即停止，则可以这样做

这应该会让我们对这个问题有更多的了解

如果这不是一个选项，您可以尝试将处理程序附加到

Dispatcher.UnhandledException

事件或

应用程序.DispatcherUnhandledException

事件，并添加一些您自己的自定义日志记录代码。这可能会为您提供有关异常最初从何处引发的更多信息

---

在没有更详细的日志记录的情况下，我想到的显而易见的事情是（尽管这是一个很长的问题）：您在两个系统上都安装了任何不寻常的字体吗？

谢谢您的帮助。内部的例外情况，是一个触摸更多的帮助，因为它限制了位图文件错误

我最终找到了答案，把项目的副本去掉，直到成功。问题就在我面前。当应用程序加载时，它会加载一个主窗口。我很早就删除了这个窗口的图标，但没有成功。直到后来，我绕了回来，还删除了它加载的窗口中对图标的引用（谢天谢地），我都快疯了。也许它在Windows资源中缓存了已删除图标的副本

无论如何，我使用我们的图标编辑器（Axialis IconWorkshop）来确保所有可能的图标格式都存在；没有成功

我最终只是让窗口保持无图标，并尝试在加载时加载图标，如果失败，我只运行无图标。这并不完美，但在图标导致问题的有限情况下，我不希望它因此崩溃

另一方面，如果第一个图标失败，我让它也尝试加载一个旧的/低分辨率的图标版本，在这种情况下确实有效

---

我只希望调试器能在查明这一点上提供更多帮助。

您可能需要查看图标的格式。我在Vista之前的平台上使用WPF应用程序时遇到问题，该应用程序带有高分辨率256图标。我的设计团队提供了一个图标，该图标使用PNG格式，用于256个旧平台无法加载的图标。一旦将特定图标更改为位图格式，一切正常。

请将堆栈跟踪设置为代码格式，以便我们可以轻松阅读。是的。。VS在尝试加载应用程序时立即崩溃，并且“没有可用的源代码”，而且错误也很模糊。好吧，但我的观点是，我想查看堆栈跟踪，了解它真正崩溃的位置。不幸的是，默认情况下，您不会得到这个结果-您最终会得到您发布的非特定堆栈跟踪。正如我上面所说的，整个想法是获得一个更有用的堆栈跟踪。异常将和以前一样“模糊”，因为我希望看到相同的异常，但是如果我们能够看到它从何处抛出，这可能有助于解决问题。