wpf 0x88980406 SyncFlush() ...有解决方法吗？

0x88980406 SyncFlush() ...Is there a workaround?

提问by cbuteau

I get this exception in my application. I have found links discussing it on the web but nothing indicating how to track it down and/or workaround it.

我在我的应用程序中遇到了这个异常。我在网上找到了讨论它的链接，但没有任何说明如何追踪它和/或解决它。

Please do not reply with links from the internet. Please reply with strategies of tracking the source. Please reply with workarounds if you found them.

请不要回复来自互联网的链接。请回复追踪来源的策略。如果您找到了解决方法，请回复。

Source: PresentationCore
Message: Exception from HRESULT: 0x88980406
Stack Trace:
   at System.Windows.Media.Composition.DUCE.Channel.SyncFlush()
   at System.Windows.Interop.HwndTarget.UpdateWindowSettings(Boolean enableRenderTarget, Nullable`1 channelSet)
   at System.Windows.Interop.HwndTarget.UpdateWindowPos(IntPtr lParam)
   at System.Windows.Interop.HwndTarget.HandleMessage(WindowMessage msg, IntPtr wparam, IntPtr lparam)
   at System.Windows.Interop.HwndSource.HwndTargetFilterMessage(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
   at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
   at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
   at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
   at MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen(Object source, Delegate method, Object args, Int32 numArgs, Delegate catchHandler)

采纳答案by cbuteau

In my case it turned out the application in question was already pressing up on memory limits of its specced hardware. Any time I added code that used a decent amount of memory this would crop up.

在我的情况下，结果证明有问题的应用程序已经达到了其指定硬件的内存限制。每当我添加使用大量内存的代码时，都会出现这种情况。

I ended up using a MemoryFailPointmechanism when I implemented a feature that placed processing an image buffer on another thread.

MemoryFailPoint当我实现将处理图像缓冲区放在另一个线程上的功能时，我最终使用了一种机制。

https://docs.microsoft.com/en-us/dotnet/api/system.runtime.memoryfailpoint

https://docs.microsoft.com/en-us/dotnet/api/system.runtime.memoryfailpoint

First implementation did the trick but after many tries QA caused a OOM bomb. So I implemented a MemoryFailPoint()with GC.Collect()loop (hackish I know...but sometimes...get er done).

第一个实现成功了，但经过多次尝试，QA 导致了 OOM 炸弹。所以我实现了一个MemoryFailPoint()withGC.Collect()循环（hackish 我知道......但有时......完成）。

The main things I learned were:

我学到的主要内容是：

1. This is a really bad bug in WPF.
2. You only have to worry about it if you have truly consumed an inordinate amount of memory.

1. 这是 WPF 中的一个非常糟糕的错误。
2. 如果你真的消耗了过多的内存，你只需要担心它。

回答by TrialAndError

This is old, but I will answer anyways, since I had the same issue that I just resolved.https://stackoverflow.com/a/18003004/1415307

这是旧的，但无论如何我都会回答，因为我遇到了刚刚解决的相同问题。https://stackoverflow.com/a/18003004/1415307

Basically, my issue with this error came down to an outdated video card driver. After updating to the newest driver, the issue has been resolved.

基本上，我的这个错误问题归结为过时的显卡驱动程序。更新到最新驱动后，问题已解决。

回答by Dale Barnard

With Microsoft's excellent help, we just solved a SyncFlush problem that has plagued us for more than a year. It turns out that we were creating multimedia timers in native code, but we weren't freeing them every time. More specifically, we called timeBeginPeriod and timeEndPeriod, but we called begin more times than end, thus creating a resource leak. The WPF rendering thread needs to use those timers, but we exhausted a limited supply of them (perhaps 65k). The result was that the rendering thread stopped rendering and either hung or caused a crash. Watch out for timers!

在微软的大力帮助下，我们刚刚解决了一个困扰我们一年多的SyncFlush问题。事实证明，我们是在本机代码中创建多媒体计时器，但我们并没有每次都释放它们。更具体地说，我们调用了 timeBeginPeriod 和 timeEndPeriod，但是我们调用 begin 的次数比调用 end 的次数多，从而造成资源泄漏。WPF 渲染线程需要使用这些计时器，但我们用尽了它们的有限供应（可能是 65k）。结果是渲染线程停止渲染，要么挂起，要么导致崩溃。注意定时器！