ExecutionEngineException occurs 'randomly' after a while

[rasmus-z]

Description

After using Rise Media Player for a while, and right clicking on stuff to use the MenuFlyout and then pressing either choosing something in the MenuFlyout or after that pressing a button (such as the Back button) I get hit with "An unhandled exception of type 'System.ExecutionEngineException' occurred in Unknown Module." No call stack.

Steps To Reproduce

Since it is a bit random, it's a bit hard but these steps usually triggers the exception:

1. Start Rise Media Player, ensure you have music files in your library.
2. Go to Artist (in the Sidebar), choose an artist, switch to the Albums tab then choose an album.
3. Play a song from that album via the right-click MenuFlyout.
4. Press the Album image on the Now Playing control.
5. Toggle the Now Playing Queue via the button.
6. Right click on a Song and then move it up or down.
7. Press the top-left Back button.
8. If this didn't trigger it, then:
9. Right click on a song and choose Add to > New playlist.

Expected behavior

Not triggering an unhandled exception of type 'System.ExecutionEngineException'

Rise Media Player Version

Alpha Preview 2 - 0.0.170.0 (release_vnext branch)

Windows Version

Windows 10 Pro 21H2 19044.1741

Relevant Assets/Logs

[itsWindows11]

Can reproduce this same issue here but only when running the app with an attached debugger.

Otherwise, it works perfectly when running the app without debugging, so it shouldn't be an issue for most users already.

I guess it's also caused by the fact that it's running native code (NAudio for example) since it only happens when you play media.

[rasmus-z]

That's not what I see when running without debugging. When I run a deployed Debug build without any debugger attach (start it from the Start Menu) what happens instead is a crash. No message or anything, just halts for an instant then closes. Building a Release build now, will try that in a couple of minutes. Edit: Tried it in a Release build (without a debugger attached) and I get the same result as you - ie that seems to not trigger this issue.

[YourOrdinaryCat]

Does the event viewer have any relevant data? On my end, disabling XAML Hot Reload fixes those random exceptions. Seems to be a problem with the VS Debugger, or .NET

[itsWindows11]

Edit: Tried it in a Release build (without a debugger attached) and I get the same result as you - ie that seems to not trigger this issue.

Hmm strange, so definitely a native code issue in debug.

[rasmus-z]

Does the event viewer have any relevant data? On my end, disabling XAML Hot Reload fixes those random exceptions. Seems to be a problem with the VS Debugger, or .NET

Disabled Hot Reload + XAML Hot Reload but to no avail. The exception still occurs (in Debug+debugger), and a new entry in the Event Viewers log appears which includes this information:

Faulting application name: Rise Media Player.exe, version: 0.0.171.0, time stamp: 0x62a3c35e Faulting module name: KERNELBASE.dll, version: 10.0.19041.1741, time stamp: 0xe9b4a91b Exception code: 0xc000027b Fault offset: 0x000000000010fa32 Faulting process id: 0x2b78 Faulting application start time: 0x01d8dfcde44d8c43 Faulting application path: T:\GitHubDesktop\Rise-Software\Rise-Media-Player\Rise Media Player Dev\bin\x64\Debug\AppX\Rise Media Player.exe Faulting module path: C:\WINDOWS\System32\KERNELBASE.dll

[rasmus-z]

While testing on a .NET Native compiled Debug build with debugger (both Hot Reload and XAML Hot Reload disabled) attached, I encountered this issue:

Failfast due to accessing a neutered CCW! You can only access a neutered CCW from ICCW or IUnknown::AddRef/Release

Took a bit more right clicking/MenuFlyout summoning than in the first post to trigger, still happened after I cleaned (and removed all obj/bin folders) and rebuilt the Solution.

[itsWindows11]

There are no stable steps to reproduce this. Also can reproduce it in many other ways than the right click thing.

[YourOrdinaryCat]

While testing on a .NET Native compiled Debug build with debugger (both Hot Reload and XAML Hot Reload disabled) attached, I encountered this issue:

Failfast due to accessing a neutered CCW! You can only access a neutered CCW from ICCW or IUnknown::AddRef/Release

Definitely a problem with native code interop, it occurs randomly and seems to happen when interacting with UI elements, so likely something going wrong with WinUI interop (which is bound to happen rather frequently).

I'm guessing this is something the C# projection's messing up, particularly when a debugger is attached or a debug build is deployed.

[YourOrdinaryCat]

I've tried gathering some info, but the logs just aren't clear enough to pinpoint an exact cause. I'll leave the issue open for now, but there doesn't seem to be much we can do. Take everything below with a grain of salt.

CCWs are COM Callable Wrappers, which COM clients use as proxy for managed objects. I could barely find anything regarding neutered CCWs, so I'm guessing this refers to version neutral interop as described in this random 2010 article, specifically:

4. It’s been suggested to me that the the generated runtime callable wrapper could be modified so that the type names are constant. ( Version Neutral / Neutered interop )...

I'm guessing this refers to explicit interfaces for COM clients, so I'll take a wild guess and say the log message probably refers to COM trying to access version neutral (neutered?) CCWs without the proper interface (ICCW?). I'm guessing the IUnknown part is relevant somehow, but I can't see exactly how.

This of course narrows the problem down to... anything in the app that has to do COM/WinRT interop. I do think it's somehow related to the way the UWP C# projection works due to the random nature of the exception, plus there's little to no logs, which likely means there's something failing at a much deeper level than our code. Again, this isn't very concrete, but it might help when it comes to narrowing things down.

Just for the record, I'm able to reproduce the issue much more consistently by playing a few videos, although only if attached to a debugger. Playing 2 videos is usually enough to trigger the exception on my end.

[YourOrdinaryCat]

I tried with WinDbg, and it actually shows something at least.

(324c.134c): Windows Runtime Originate Error - code 40080201 (first chance)
(324c.5cd8): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
CoreCLR!MetaDataGetDispenser+0x5865:
00007ffe`71577335 488b18          mov     rbx,qword ptr [rax] ds:00000000`00000000=????????????????

So I guess this does have something to do with platform code. I found an issue similar to ours in the Win2D repo, same error codes and all. There's also something similar on StackOverflow, a question related to file handling no less.

I guess this has something to do with navigation - every single "reliable" (as reliable as it gets for this...) repro involves navigation at some point, specially with Now Playing (which involves a lot of interop with platform code). We might have to look into any possible memory leaks.