Look at this in the Notes section. It states:
Sometimes the front buffer becomes unavailable. This lack of accessibility may be caused by screen locks, full-screen exclusive Direct3D applications, user switching, or other system actions. When this happens, your WPF application is notified by handling the IsFrontBufferAvailableChanged event.
He talks about this with respect to the Unlock method, which pushes the contents of the backbuffer into the frontbuffer. But I assume that if you acquire a lock and call Unlock , after which it fails, because for some reason it cannot write to the buffer, the lock can remain until it is successfully unlocked, and in this TryLock call TryLock will fail. I imagine something like this:
image.TryLock // image gets written to image.Unlock // fails for one of the listed reasons, lock is retained // loop image.TryLock // fails because lock is already acquired image.Unlock // succeeds because the previously successful lock is still in // place and the issue that caused the previous failure of Unlock // has since subsided.
I saw how this problem occurs in some DirectX own development when BeginDraw and EndDraw used incorrectly, so this may be your solution. This is about all that I have. Hope this helps!
As indicated in this block comment, you can check if this can be done by adding an event to the IsFrontBufferAvailableChanged event. If this is not the case, you can deal with the problem accordingly without causing the TryLock / Unlock combo, essentially skipping the render when the front buffer is unavailable. More information about this event handler can be found here . And the comments on this page contain additional information on how you can better deal with raising this event. It states:
The SetBackBuffer method has an overload that takes a parameter that indicates whether WPF is returning to software rendering.