System.ExecutionEngineException in a Windows Store App? - Why?

Question

Hoping for some help from the powers that be or other resident experts, as I think this is one tricky problem.
I'm getting some seemingly random System.ExecutionEngineException events in my Windows Store app. Even though the error message itself is less than useless, when enabling native code debugging there does seem to be a connection to the use of streams and
possibly thread blocking. The call stack almost always contains a reference to SHCreateStreamOnFileW or similar stream-related functions (although that particular call is unsupported in WinRT, I'm assuming the kernel is calling it under the hood; I certainly
am not).  In my own code, I do indeed utilize CreateStreamOverRandomAccessStream though so there's an obvious possible connection there.
I cut back on what was probably overly conservative use of EnterCriticalSection calls and that seems to have eliminated *almost* - but not all - of these insidious errors. Therefore I'm wondering if there's a connection between these errors and possible
thread blocking or competing locks? They also definitely seem to occur only when disk access is sluggish. So again, I'm thinking some issue with thread blocking while waiting for the disk. But just a guess.   
What's particularly confusing is that the docs say this exception is obsolete, so I don't understand why I'd be getting it in a Windows store app. 
Any insight would be appreciated!
Thanks,
Peter

Answer 1

You know what? I was just telling one of my testers today that I've only ever had an issue on my one laptop and no other machines. And he's never experienced it. (Outside the dev environment if just manifests as a random app crash and he hasn't reported
anything like that). Thing is the laptop is basically fine otherwise. Certainly no random app crashes except my own app. A few other data points. It only manifests in release mode so far. I've never seen it in debug mode. (Maybe code optimization could be
contributing?) I am using a fair amount of C#/C++ interop and a lot of multithreadimg. When the crashes do occur they are always when the app is doing things that use the C++ modules and specifically they utilize COM streams (which I implement
in C# to wrap .net streams) and synchronous disk read ops. IStream specifically. But the modules are always called from worker threads. They never block the UI thread. So that shouldn't be the issue. Even if it is my environment there should be a graceful
way to handle the error. As I said other apps don't just crash. Trying to think of what other relevant information I can give without getting into gory and irrelevant detail. Again any other insights appreciated. I'll try to grab a stack history next time
it happens (I have to be in native mode debugging to get any useful info). that will reveal more. Thanks so much. Peter