DirectShow Related Bugs: MediaLooks MPEG-2 Video Decoder, Haali Media Splitter (AR)

An attempt to render media file in GraphStudio ended up with an error message:

Protection
A monitor program has been foun drunning in your system. Please unload it from memory and restart your program.

The module which popped up the message chose to not identify itself in a friendly manner, however as nothing goes untraceable it appeared to be MediaLooks MPEG-2 Video Decoder file, Mpeg2DecoderL.dll (version 1.0.3.9). As the message was popped up from a non-GUI thread, there was no way to close the box – the entire application froze…

MediaLooks MPEG-2 Video Decoder Error Message

The problem does not happen in GraphEdit, as the decoder is probably handling this case specifically.

The decoder has an deinstallation batch file located in application directory: C:\Program Files\MediaLooks\Mpeg2Decoder\Uninstall.bat. A curious thing, however, is that running this file in attempt to uninstall the decoder shows the same problem: the decoder refuses to be uninstalled due to mystic “monitor program” running in the system:

MediaLooks MPEG-2 Video Decoder Deinstallation Failure

After closing the message box the application still continues deinstallation script and removes the decoder from system.

Another issue for this file (and hopefully for today) is that another filter Haali Media Splitter (AR) (splitter.ax, version 1.9.42.1) is crashing the hosting process on being removed from the graph.

Haali Media Splitter Crash Haali Media Splitter Crash

One Reply to “DirectShow Related Bugs: MediaLooks MPEG-2 Video Decoder, Haali Media Splitter (AR)”

  1. I just wanted to ask you if you perhaps found any solution or any info about the crash you mentioned in your post about the Haali Media Splitter.I have the same crash. Looking at the mailinglist for the Haali Media Splitter, a Microsoft employee also posted about the same crash, but no response at all from the developers.

    I’m looking to use the splitter in a commercial application so it’s quite saddening to see no response from Mike (I think that’s his name)
    http://lists.matroska.org/pipermail/matroska-devel/2009-October/003557.html
    I never thought Microsoft would actually look at those dumps if the code responsible wasn’t theirs.

    Well, I don’t already remember the details, but I think that even if the problem is here, you can in your application just use try/catch block to catch the exception. I am not sure if this can really work, but this is the first thing to try.

    If this is does not work, you can leave the graph and the filter not released. This will create a memory leak, of course, but you can remove other filters which you can remove safely so that the effect is minimal. Once the problem is fixed you will return to normal release/destruction.

    Both ways are of a kind that you normally avoid, but it is going to work in most cases as a workaround.

Leave a Reply