.net - WPF中的win32窗口

Question

最近，我们的应用程序遇到了一个奇怪的问题。

该应用程序在WPF窗口中有一个win32窗口，
调整WPF窗口大小时，出现了问题。

堆栈跟踪：

Exception object: 0000000002ab2c78
Exception type: System.OutOfMemoryException
InnerException: <none>
StackTrace (generated):
    SP       IP       Function
    0048D94C 689FB82F PresentationCore_ni!System.Windows.Media.Composition.DUCE+Channel.SyncFlush()+0x80323f
    0048D98C 681FEE37 PresentationCore_ni!System.Windows.Media.Composition.DUCE+CompositionTarget.UpdateWindowSettings(ResourceHandle, RECT, System.Windows.Media.Color, Single, System.Windows.Media.Composition.MILWindowLayerType, System.Windows.Media.Composition.MILTransparencyFlags, Boolean, Boolean, Boolean, Int32, Channel)+0x127
    0048DA38 681FEAD1 PresentationCore_ni!System.Windows.Interop.HwndTarget.UpdateWindowSettings(Boolean, System.Nullable`1<ChannelSet>)+0x301
    0048DBC8 6820718F PresentationCore_ni!System.Windows.Interop.HwndTarget.UpdateWindowSettings(Boolean)+0x2f
    0048DBDC 68207085 PresentationCore_ni!System.Windows.Interop.HwndTarget.UpdateWindowPos(IntPtr)+0x185
    0048DC34 681FFE9F PresentationCore_ni!System.Windows.Interop.HwndTarget.HandleMessage(Int32, IntPtr, IntPtr)+0xff
    0048DC64 681FD0BA PresentationCore_ni!System.Windows.Interop.HwndSource.HwndTargetFilterMessage(IntPtr, Int32, IntPtr, IntPtr, Boolean ByRef)+0x3a
    0048DC88 68C6668E WindowsBase_ni!MS.Win32.HwndWrapper.WndProc(IntPtr, Int32, IntPtr, IntPtr, Boolean ByRef)+0xbe
    0048DCD4 68C665BA WindowsBase_ni!MS.Win32.HwndSubclass.DispatcherCallbackOperation(System.Object)+0x7a
    0048DCE4 68C664AA WindowsBase_ni!System.Windows.Threading.ExceptionWrapper.InternalRealCall(System.Delegate, System.Object, Boolean)+0x8a
    0048DD08 68C6639A WindowsBase_ni!System.Windows.Threading.ExceptionWrapper.TryCatchWhen(System.Object, System.Delegate, System.Object, Boolean, System.Delegate)+0x4a
    0048DD50 68C64504 WindowsBase_ni!System.Windows.Threading.Dispatcher.WrappedInvoke(System.Delegate, System.Object, Boolean, System.Delegate)+0x44
    0048DD70 68C63661 WindowsBase_ni!System.Windows.Threading.Dispatcher.InvokeImpl(System.Windows.Threading.DispatcherPriority, System.TimeSpan, System.Delegate, System.Object, Boolean)+0x91
    0048DDB4 68C635B0 WindowsBase_ni!System.Windows.Threading.Dispatcher.Invoke(System.Windows.Threading.DispatcherPriority, System.Delegate, System.Object)+0x40
    0048DDD8 68C65CFC WindowsBase_ni!MS.Win32.HwndSubclass.SubclassWndProc(IntPtr, Int32, IntPtr, IntPtr)+0xdc

StackTraceString: <none>
HResult: 8007000e

另外，我发现了一些相关链接：

relatedA

relatedB


有什么办法可以避免或处理此问题？
如何找出真正的问题？
从调用堆栈中，我们可以确定问题来自.NET Framework吗？


感谢您的回答或评论！

Answer 1

您的问题不是由托管内存泄漏引起的。显然，您是在非托管代码中的某个地方打勾。

在几次MILCore调用之后，将调用SyncFlush（）方法，它似乎使已发送的更改立即得到处理，而不是留在队列中以供以后处理。由于调用处理了先前发送的所有内容，因此从发送的调用堆栈中不能排除可视化树中的任何内容。

包含非托管呼叫的呼叫堆栈可能会显示更多有用的信息。使用本地调试，windbg或其他本地代码调试器在VS.NET下运行应用程序。将调试器设置为打破异常，并在相对断点处获取调用堆栈。

调用堆栈当然会下降到MILCore，然后从那里进入DirectX层和DirectX驱动程序。在本机调用堆栈中的某个位置可以找到有关代码的哪一部分导致问题的线索。

MILCore可能会根据您所讲的内容将巨大的某些参数值传递给DirectX。检查您的应用程序是否存在任何可能导致Bug的错误，这些错误会使DirectX分配大量内存。要寻找的东西的例子是：


设置为以高分辨率加载的BitmapSource。
大型可写位图
极大（或负）变换或大小值


解决该问题的另一种方法是逐步简化您的应用程序，直到问题消失，然后仔细查看上次删除的内容。方便时，最好将其作为二进制搜索：最初将视觉复杂性减少一半。如果可行，则将已删除的内容放回一半，否则再删除另一半。重复直到完成。

还请注意，通常不需要删除UI组件以防止MILCore看到。任何具有Visibility.Hidden的Visual都可以完全跳过。

没有通用的方法可以避免此问题，但是搜索技术将帮助您确定在特定情况下需要进行哪些更改以解决此问题。

从调用堆栈可以肯定地说，您在NET Framework或特定视频卡的DirectX驱动程序中发现了一个错误。

关于您发布的第二个堆栈跟踪

John Knoeller认为从RtlFreeHeap到ConvertToUnicode的转换是胡说八道是正确的，但是从中得出了错误的结论。我们看到的是，您的调试器在追溯堆栈时迷路了。它从异常正确启动，但是在Assembly.ExecuteMainMethod框架下丢失，因为在处理异常和调用调试器时，堆栈的那部分已被覆盖。

不幸的是，对该堆栈跟踪的任何分析对于您的目的都是无用的，因为它被捕获太晚了。我们看到的是在处理WM_LBUTTONDOWN期间发生了异常，该异常被转换为WM_SYSCOMMAND，然后捕获了异常。换句话说，您单击了导致系统命令（例如调整大小）的内容，从而导致异常。在捕获此堆栈跟踪时，该异常已得到处理。您看到User32和UxTheme调用的原因是因为这些都参与了按钮的单击处理。他们与真正的问题无关。

您的工作方向正确，但是在分配失败时，您将需要捕获堆栈跟踪（或者您可以使用我上面建议的其他方法之一）。

当第一个堆栈跟踪中的所有托管帧都出现在其中并且堆栈顶部是内存分配失败时，您将知道您具有正确的堆栈跟踪。请注意，我们只对出现在DUCE+Channel.SyncFlush调用上方的非托管框架感兴趣，在该框架之下的所有内容都是NET Framework和您的应用程序代码。

如何在正确的时间获取本机堆栈跟踪

您希望在显示的DUCE+Channel.SyncFlush调用中第一次内存分配失败时获取堆栈跟踪。这可能很棘手。我使用三种方法：（请注意，在每种情况下，您都从SyncFlush调用中的断点开始-有关更多详细信息，请参见下面的注释）


将调试器设置为在所有异常（托管和非托管）上都中断，然后继续执行（F5或“ g”），直到在您感兴趣的内存分配异常上中断为止。这是第一件事，因为它很快，但是在使用本机代码时，它通常会失败，因为本机代码通常会将错误代码返回给调用的本机代码，而不是引发异常。
将调试器设置为在所有异常上均中断，并在通用内存分配例程上设置断点，然后反复按F5（转到），直到异常发生为止，并计算所命中的F5数量。下次运行时，减少使用一个F5，您可能正在分配生成异常的调用中。将调用堆栈捕获到记事本中，然后从那里反复进行F10（跳过）以查看是否确实是分配失败。
在由SyncFlush调用的第一个本机帧（这是wpfgfx_v0300！MilComposition_SyncFlush）上设置一个断点，以跳过托管到本机的过渡，然后按F5运行。通过函数F10（跳过），直到EAX包含错误代码E_OUTOFMEMORY（0x8007000E），ERROR_OUTOFMEMORY（0x0000000E）或ERROR_NOT_ENOUGH_MEMORY（0x0000008）之一。注意最新的“呼叫”指令。下次运行该程序时，请运行到该处并逐步执行该程序。重复此操作，直到导致问题的内存分配调用并转储堆栈跟踪为止。请注意，在许多情况下，您会发现自己遍历了大型数据结构，因此需要一些智能才能设置适当的断点以跳过该循环，从而可以快速找到所需的位置。该技术非常可靠，但劳动强度大。


注意：在每种情况下，除非您的应用程序位于失败的DUCE+Channel.SyncFlush调用之内，否则您都不希望设置断点或开始单步执行。为确保这一点，请在禁用所有断点的情况下启动应用程序。运行时，在System.Windows.Media.Composition.DUCE+Channel.SyncFlush上启用断点并调整窗口大小。大约是第一次单击F5，以确保在第一次SyncFlush调用中异常失败（如果不是，请计算在异常发生之前必须击中F5的次数）。然后禁用断点并重新启动程序。重复该过程，但是这次是在正确的时间单击SyncFlush调用，设置断点或如上所述执行单步操作之后。

推荐建议

我上面描述的调试技术是劳动密集型的：计划至少花费几个小时。因此，在进入调试器进行此类操作之前，我通常会尝试反复简化我的应用程序，以找出导致问题的根源。这有两个优点：它可以使您很好地复制显卡供应商，并且可以加快调试速度，因为显示的内容更少，因此单步执行的代码更少，分配的次数更少。

因为该问题仅发生在特定的图形卡上，所以毫无疑问，该问题可能是图形卡驱动程序或调用它的MilCore代码中的错误。很有可能是在图形卡驱动程序中，但是MilCore可能传递了大多数图形卡都正确处理的无效值，但不是此值。我上面描述的调试技术将告诉您这种情况：例如，如果MilCore告诉图形卡分配1000000x1000000像素区域，并且图形卡提供正确的分辨率信息，则该错误位于MilCore中。但是，如果MilCore的要求合理，则该错误在于显卡驱动程序中。