The exception in question is one normally seen when a program modifies a collection from another thread:
System.NotSupportedException: This type of CollectionView does not support changes to its SourceCollection from a thread different from the Dispatcher thread.
But this isn't a case of pushing the modifications onto the main thread. The CollectionView in question is one of my own creation which does support cross-thread changes.
After investigating, I found that the exception is actually thrown by a CollectionViewProxy object, one of which is created internally by WPF to wrap around my collection view.
This type's constructor sets a flag called ShouldProcessCollectionChanged to false, preventing itself from processing collection changed events (in OnCollectionChanged). 99% of the time this works correctly, but somehow this check very occasionally passes, even though the proxy does NOT have that flag set (when the crash occurs the flags are IsDynamic | NeedsRefresh). When the check passes an exception is always thrown.
Has anyone seen this before? All I can think of is that there is some sort of contention going on where one thread is changing the proxy's flags (perhaps NeedsRefresh) as another reads them. But integer operations are meant to be atomic in .Net, and if that was going wrong it would surely be causing problems elsewhere too.
