WPF does not ignore ignorable DWM errors and instead crashes the process

The gist of the problem is WPF does not ignore STATUS_MESSAGE_LOST in their call to DWM's flush function. This message is ignorable and in fact should be ignored as DWM will recycle itself if it crashes and become available again. WPF not ignoring this forces a SyncFlush failure in VS which forces a UI thread exception to be thrown which crashes the product potentially losing unsaved user data.

The DWM folks in an internal email (quoted below) suggested this error (and possibly all others) should be treated as transitory/ignored, as WPF is already doing for SOME other error codes in this same code path.

This crash is responsible for approximately 50% of the SyncFlush Watson bucket which is the #1 crash in Dev17.

From an internal email thread with the DWM folks (emphasis on 'all errors should be in this bucket', mine):

> Yes, STATUS_MESSAGE_LOST is the NTSTATUS that is returned by LPC, whereas the other value is the HRESULT version of the same thing. The only difference is the extra facility bit that’s OR’ed in.
>
> Here, you’ll notice that WPF doesn’t want to do anything different – it just bubbles the error out. Also notice that we’re filtering some known errors already, and doing nothing special when these are encountered. My point is, **all errors should be in this bucket**, and at that point there is no longer a reason to even check the return code of the method. It’s basically a best-effort method: if it works, you want to wait for it to complete, and if it doesn’t work then there’s nothing to wait for.
>