locked
A bug of Media extensions sample

    Question

  • when i use the local decoder to play a clip(about 2 min), a framework thread crashed, how to fix it?

    This is the screenshot:

    screenshot


    thanks!

    • Edited by wuyueduzun Monday, June 11, 2012 9:26 AM
    Monday, June 11, 2012 9:21 AM

Answers

  • The Media team has a fix that will be in the next release of the samples to address this issue. These are the instructions to fix the current samples:

    We found a bug in the Media samples which cause DLLs to get unloaded too early. This fix will be in the next update to the samples. In the meantime you can add these lines to constructors/destructors of the source/stream classes in the MSDN samples:
    Note: This is not needed for classes which derive from RuntimeClass<> (ex: the scheme handler).

    Constructor:

        auto module = ::Microsoft::WRL::GetModuleBase();
        if (module != nullptr)
        {
            module->IncrementObjectCount();
        }

    Destructor:

        auto module = ::Microsoft::WRL::GetModuleBase();
        if (module != nullptr)
        {
            module->DecrementObjectCount();
        }


    David Lamb


    Thursday, June 28, 2012 5:26 PM
    Moderator

All replies

  • callstack like this:

    callstack


    haha

    Monday, June 11, 2012 9:29 AM
  • Can you please grab a dump file, zip it up and put it on your Skydrive? I will then take a look and see if I can help. Also please make sure that you are on RP before sending the dump.

    -James


    Windows Media SDK Technologies - Microsoft Developer Services - http://blogs.msdn.com/mediasdkstuff/

    Tuesday, June 12, 2012 1:00 AM
    Moderator
  • this is the dump file

    please check!

    Thanks


    haha

    Tuesday, June 12, 2012 2:04 AM
  • Hello,

    I can tell you what the problem is based on the dump file but I honestly don't know why the problem is occurring. Although I would wager a guess that the issue is due to a corrupt input file. The problem is due to the fact that the MPEG1Source stream handler is going out of scope when the MFCore is attempting to read the next sample. Since the stream handler has gone out of scope the stream is no longer valid and an access violation is generated. There are no locks around stream access for performance reasons in this section of the Windows source code.

    I would recommend that you please place various break points in the MPEG1 source to see when it is going out of scope and hopefully this will allow you to understand why it is going out of scope unexpectedly.

    I hope this helps,

    James


    Windows Media SDK Technologies - Microsoft Developer Services - http://blogs.msdn.com/mediasdkstuff/

    Tuesday, June 12, 2012 11:11 PM
    Moderator
  • Does " going out of scope" mean the byte stream reach the end?

    the byte stream didn't reach the end after reading the last block, i have output the log

    and i play it well with WMP.

    This is the clip


    haha

    Wednesday, June 13, 2012 6:29 AM
  • In this case "going out of scope" means that the source stream is getting released. For some reason when the stream is released the DLL is unloaded. Again it is not entirely clear from the dump why this is occurring.

    -James


    Windows Media SDK Technologies - Microsoft Developer Services - http://blogs.msdn.com/mediasdkstuff/

    • Marked as answer by wuyueduzun Tuesday, June 26, 2012 2:50 AM
    • Unmarked as answer by wuyueduzun Tuesday, June 26, 2012 2:50 AM
    Friday, June 15, 2012 9:20 PM
    Moderator
  • Thanks!

    I find the root case, the dll was unloaded.

    This is the dump file

    But why the app model free that dll? 



    haha

    Wednesday, June 20, 2012 6:06 AM
  • Do you have a sample project to share that can repro this behavior?

    David Lamb

    Wednesday, June 20, 2012 6:32 PM
    Moderator
  • the sample project is in the MS win8 RP sample code.

    http://code.msdn.microsoft.com/windowsapps/Media-extensions-sample-7b466096


    haha

    Thursday, June 21, 2012 1:52 AM
  • Hello wuyueduzun,

    I will look at this and let you know what I find. Unfortunately it may not be until next week due to my current schedule.

    Thanks,

    James


    Windows Media SDK Technologies - Microsoft Developer Services - http://blogs.msdn.com/mediasdkstuff/

    Wednesday, June 27, 2012 7:29 PM
    Moderator
  • The Media team has a fix that will be in the next release of the samples to address this issue. These are the instructions to fix the current samples:

    We found a bug in the Media samples which cause DLLs to get unloaded too early. This fix will be in the next update to the samples. In the meantime you can add these lines to constructors/destructors of the source/stream classes in the MSDN samples:
    Note: This is not needed for classes which derive from RuntimeClass<> (ex: the scheme handler).

    Constructor:

        auto module = ::Microsoft::WRL::GetModuleBase();
        if (module != nullptr)
        {
            module->IncrementObjectCount();
        }

    Destructor:

        auto module = ::Microsoft::WRL::GetModuleBase();
        if (module != nullptr)
        {
            module->DecrementObjectCount();
        }


    David Lamb


    Thursday, June 28, 2012 5:26 PM
    Moderator
  • Thank you for the information. I downloaded the new sample, constructors/destructors of the source/stream classes are added those  code, but the decoder sample(MPEG1DECODER) don't added. why?   I think these dlls have the same logic, so the same code need added in the decoder sample. 

    I thought the framework thread crashed bug may still exist. But to my surprise,  the video playback is normal.  Now I am crazy. can you make clear about the problem? Thanks in advance.

    Friday, August 31, 2012 6:19 AM