Crash And Can't Catch Exception

[MuMuTian]

Multiple calls to open and close cause the program to crash immediately, and the exception cannot be caught.
Sometimes it doesn't reproduce consistently, but once it occurs, opening a video, closing it, and then opening it again will definitely cause a crash.

I have experimented with versions 7.0.361-beta.1 and 4.4.350, and the issue still occurs.
I hope an expert can help solve this problem. Thank you.

[MrBean2016]

Have you tried to enable native debugging? C++ exceptions are not propagated to the managed runtime without marshaling and re-casting.

[MuMuTian]

Have you tried to enable native debugging? C++ exceptions are not propagated to the managed runtime without marshaling and re-casting.

thank your reply, I enable native debugging and enbale Microsoft Symbol Servers. The exception was caught during debugging, as shown in the image below.

[F0bes]

I can reproduce it with the sample program, and my own code.
The issue can't be reproduced on my other system.
In the sample, open an h.264 mp4, then go to the playlist view and open a second h.264 mp4 and the program will crash.

I believe this might be some sort of race condition, as using app verifier ends up "fixing" it. Probably due to the overhead of appverifier and the debugger.

My solution for my project was to have one MediaElement per media and never reuse them for other media.
Really frustrating as this behaves a lot better than libvlcsharp and I'm deep in the sunken cost fallacy 😅 .

For more information, here is the crash data from the sample program.

Exception thrown at 0x00007FFBA4329051 in ffmeplay.win.exe: 0xC0000005: Access violation reading location 0x00007DFD03F50B50.

Thread list:

Maybe something to note, the crash is always as violation at 0x00007DFD03F50B50 for me.

[saulgreenberg]

Has any progress been made on tracking this down and fixing it? Not being able to reliably switch between videos is an extremely serious limitation of ffmediaelement - the software I am developing allows a user to rapidly switch between running video files, and this bug essentially kills my ability to use ffmediaelement.

So I am curious if anyone is working on this (the skill set required is beyond my own), or if I should just give up on ffmediaelement (which would be unfortunate indeed).

[F0bes]

I have no solution.
I had much better luck with LibVLC, the main drawback was the native HWND made animating, moving, etc the media player glitchy or non functional. I ended up just using ffmediaelement caching media player instances like I stated above.

Regardless, I found that using WPF for playback was a regrettable choice for my project and I ended up moving a future project to WinUI3 and using their provided media element. Playback was much more smooth as well, but with it comes the quirks of WinUI3, and probably less codec support. Such a sad state for C# media playback🤷

[saulgreenberg]

Ah well. FFMediaElement, in my tests, was doing really well until it hit that snag. Unfortunately, LibVLC is not an option for me due to airspace issues (which means it doesn't interact well with WPF controsl) and my huge code-base is in WPF. No other real options seem to be available. Very surprising that Microsoft has not created a modern media playback control with good codec support that can interoperate with its variouos GUI frameworks, especially given the importance of video these days. Thanks for responding. I do hope someone else will take a hard look at FFMediaElement and bring it to a production status.