locked
.NET 4.0, WMP 12, Memory leak problem using embedded activeX WMP control RRS feed

  • Question

  • Hi!

    I use wrapped activeX control in Windows Forms Application to play files one by one in specified order.

    After a while OutOfMemory Exception is thrown. Using memory profiler and find out that during plays unmanaged memory allocated by application (previuosly I separated View - control embedding WMP to ensure that this control is problem) is still growing (bytes and instances).

    Any ideas what is teh problem ?

    To play files I use player property URL, before I set autostart to false, after setting URL i call player.

    ctlcontrols.play(). When I want to stop playing I use player.ctlcontrols.stop() and then player.close().

     

     


    Regards, Qrakus
    Friday, October 28, 2011 6:33 PM

Answers

  • Hi!

    I definitely have receieved your emails. Still I don't have any idea why it was impossible to repro the memory issue, but I have fixed it. Maybe you didn't test the app for long time run.

    First:

    According to http://msdn.microsoft.com/en-us/library/windows/desktop/dd562470(v=VS.85).aspx one can't use URL property in event handlers code - it can cause problems - (so why in the example code forbidden event handler code is used to set mentioned property).

    I've changed logic not to use URL property (switched to IWMPMedia interface using AxWindowsMediaPlayer.currentMedia/AxWindowsMediaPlayer.newMedia) and I didn't use builtin AxWindowsMediaPlayer.PlayStateChanged event. I created timer and I'm observing AxWindowsMediaPlayer.playState property to identify start/stop and so forth.

    During image view (I want to show it continuously for variable amount of time) I managed not to use loop on one item and I'm using pause.

    Second:

    I changed codecs used to view content on target Windows Embedded Standard 7 platform where memory problem still existed after above changes (on my development machine everything worked fine). I've installed "K-lite codec pack". I don't really know why there is a difference in app behaviour on distinct software and hardware platforms.

    On my development PC (notebook, nVidia GPU) and second development machine (desktop, ATI GPU) running Windows 7 Proffesional without third party video codes after code changes I've described the memory consumption was stable. On the other hand on target device (barebone, Intel GPU) running WES7 installed from template (Set Top Box as I remembere) with all necessary drivers (all Windows 7) and builtin Windows codecs (Windows Media Player v12 package) the memory leak appears and after some time app is using about 300-500 MB of Private bytes and WMP media error occurs (if you try to use this WMP control after error for several times, out of memory exception is thrown). After codecs install everything is fine and app uses about 95-110 MB after 72h non-stop run and display multiple images, avi, wmv.

    If I find some time I will try to find direct issue.

    Anyway thanks for help and commitment.

     


    Regards, Qrakus
    Monday, November 14, 2011 10:00 AM

All replies

  • Hi Qrakus,

    Would you please show your detailed code here so that we can reproduce it?

    Best Regards


    Neddy Ren [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Monday, October 31, 2011 7:53 AM
  • Hi Qrakus,

    Would you please show your detailed code here so that we can reproduce it?

    Best Regards


    Neddy Ren [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Hi!

     

    Thanks for response. Yesterday, finally I have found the issue: commented line of code

     

        public static class Program
        {
            [STAThread]
            private static void Main()
            {
                //!!!
                ////Application.EnableVisualStyles();
                //!!!
    
                Application.SetCompatibleTextRenderingDefault(false);
    
                Container ioc = new Container();
    
                CommonAppBootStrapper<AppRegistry> bootStrapper = new CommonAppBootStrapper<AppRegistry>(ioc);
    
                ApplicationContext appcontext = bootStrapper.ApplicationContext;
    
                Application.Run(appcontext);
            }
        }
    

     

    Control seems to have problems with visual styles. After removing this setting everything is stable and unmanaged memory used by WMP is level fixed.

    You are asking for media error code - the player during work (with visulas styles enabled) used to raise randomly this code (C00D11B1) after starting playing files when the unmanaged memory level was high enough - in my case after 30-40 minutes of constant work of player control. 

     

     


    Regards, Qrakus
    • Edited by qrakus Monday, October 31, 2011 12:37 PM
    Monday, October 31, 2011 12:36 PM
  • After making some tests the problem still exist so I think my previous solution is wrong.

    Any idea?


    Regards, Qrakus
    Monday, October 31, 2011 2:56 PM
  • Hi qurkus,

    Is it possible to share a demo project with us?  You can directly ping me at misun@microsoft.com

    Good day!

    Thanks


    Michael Sun [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Tuesday, November 1, 2011 11:19 AM
  • Hi qurkus,

    Any update?  I tested your demo, but cannot repro the memory leak issue.  Do you recieve my mail? 

    Good day!

    Thanks


    Michael Sun [MSFT]
    MSDN Community Support | Feedback to us
    Monday, November 14, 2011 5:37 AM
  • Hi!

    I definitely have receieved your emails. Still I don't have any idea why it was impossible to repro the memory issue, but I have fixed it. Maybe you didn't test the app for long time run.

    First:

    According to http://msdn.microsoft.com/en-us/library/windows/desktop/dd562470(v=VS.85).aspx one can't use URL property in event handlers code - it can cause problems - (so why in the example code forbidden event handler code is used to set mentioned property).

    I've changed logic not to use URL property (switched to IWMPMedia interface using AxWindowsMediaPlayer.currentMedia/AxWindowsMediaPlayer.newMedia) and I didn't use builtin AxWindowsMediaPlayer.PlayStateChanged event. I created timer and I'm observing AxWindowsMediaPlayer.playState property to identify start/stop and so forth.

    During image view (I want to show it continuously for variable amount of time) I managed not to use loop on one item and I'm using pause.

    Second:

    I changed codecs used to view content on target Windows Embedded Standard 7 platform where memory problem still existed after above changes (on my development machine everything worked fine). I've installed "K-lite codec pack". I don't really know why there is a difference in app behaviour on distinct software and hardware platforms.

    On my development PC (notebook, nVidia GPU) and second development machine (desktop, ATI GPU) running Windows 7 Proffesional without third party video codes after code changes I've described the memory consumption was stable. On the other hand on target device (barebone, Intel GPU) running WES7 installed from template (Set Top Box as I remembere) with all necessary drivers (all Windows 7) and builtin Windows codecs (Windows Media Player v12 package) the memory leak appears and after some time app is using about 300-500 MB of Private bytes and WMP media error occurs (if you try to use this WMP control after error for several times, out of memory exception is thrown). After codecs install everything is fine and app uses about 95-110 MB after 72h non-stop run and display multiple images, avi, wmv.

    If I find some time I will try to find direct issue.

    Anyway thanks for help and commitment.

     


    Regards, Qrakus
    Monday, November 14, 2011 10:00 AM
  • Glad to hear the issue is solved and thanks for sharing the solution.

    Good day!


    Michael Sun [MSFT]
    MSDN Community Support | Feedback to us
    Tuesday, November 15, 2011 2:18 AM