0x88980406 SyncFlush() …Is there a workaround?

前端 未结 3 878
挽巷
挽巷 2021-02-05 04:14

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

相关标签:
3条回答
  • 2021-02-05 04:21

    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 MemoryFailPoint mechanism when I implemented a feature that placed processing an image buffer on another thread.

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

    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.
    0 讨论(0)
  • 2021-02-05 04:25

    This is old, but I will answer anyways, since I had the same issue that I just resolved.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.

    0 讨论(0)
  • 2021-02-05 04:25

    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!

    0 讨论(0)
提交回复
热议问题