locked
Additional requirements for a WMP plugin on Vista 64? RRS feed

  • Question

  • I have a WMP plugin (as a DMO) that works with Media Player 10 and 11 on Windows XP and Vista (32-bit).  That same DMO does not work on Vista 64-bit.

    My DMO registers with IWMPMediaPluginRegistrar::WMPRegisterPlayerPlugin() and ThreadingModel = 'Both'. ()

    My plugin will support IEEE_FLOAT as well as PCM audio, but it does not appear to get the chance.

    I usually see my DMO loaded into multiple processes on Vista 32, and the rendering always occurs in an MFPMP.exe process.  I do not ever see my DMO getting loaded into the MFPMP.exe process on Vista 64, and I suspect that is where the audio rendering is occurring since I do see an MFPMP.exe process starting when audio playback starts.

    What more do I need to do to get my DMO picked-up on Vista 64?

    Dan

    Monday, February 12, 2007 9:11 PM

Answers

  • I'm glad you were able to get scenario (C) working! I'm stumped as to why it suddenly started working when you changed the location of the DSPs though. I build a bazillion DSPs in various folders (including C:\Src) and I could not reproduce your issue. Might there be a permissions issue with your C:\Src folder that is interfering? Do you have UAC enabled/disabled?

    Also is this reliable? Can you build a brand new DSP in C:\Src, register it and not have it work, then re-register it in C:\Program Files (x86) and make it work again?

    When you registered your DSPs on "Don," were you using "Debug" bits? If so, you probably had to install Visual Studio to get the debug runtime. "Debug" built stuff won't load (register) since it has a dependency on this debug runtime. You should be able to register your plugins on a clean machine with "Release" bits since Vista includes the retail runtime. You might want to try this if you can to eliminate the possibility that installing Visual Studio somehow causes scenario (C) to start working.

    To answer your question about mfpmp.exe running as a protected process, it runs protected unless the content is clear AND a plugin is registered (and loaded into the topology). So yes, mfpmp.exe will run protected if there are no plugins registered or the plugin does not fit into the topology for some reason (incompatible media types, no out-of-proc support, loading errors, etc.)

    I'm thinking that mfpmp.exe running secure when your scenario (C) was failing may be more of a side-effect of the failure rather than the cause. Still, I can't think of a good explanation of why any behavior would have changed based on the path. If you can reliably cause scenario (C) to fail again with a new DSP plugin, we can continue to investigate this if you're still interested.

    Wednesday, March 7, 2007 2:38 AM

All replies

  • Have you tried using a 64-bit version of your DMO for use on 64-bit?  mfpmp.exe on a 64-bit machine always runs 64-bit -- even if the playback application is 32-bit.
    Wednesday, February 14, 2007 5:30 PM
  • I rebuilt my plugin as a 64-bit DLL, and that did not help.  Now it does not appear to get picked up by either WMP or MFPMP.  I also recall that, on Vista, a WMP plugin registers as WMP_PLUGINTYPE_DSP_OUTOFPROC -- does that equate to running in another process, external to WMP and external to MFPMP, so that 32-bit / 64-bit harmony is not necessary?

    I have also tried to change my registered preferred media type (to MEDIASUBTYPE_IEEE_FLOAT) and my dwPriority handed to WMPRegisterPlayerPlugin.  None of these appeared to change anything.

    Another possibility: Would I need to have a signed DLL for a plugin on Vista 64?  (My DLL is not signed.)

    Tuesday, February 20, 2007 4:36 PM
  • This is probably because the default WMP shortcut launches the 32-bit player, but mfpmp.exe always runs 64-bit on a 64-bit platform (even if the client app is 32-bit).

    In order for a DSP to work with the 32-bit player and 64-bit mfpmp.exe, you need to build two copies of your DSP, a 32-bit one registered with the 32-bit regsvr32 (in SysWOW64) and a 64-bit one registered with the 64-bit regsvr32 (in System32). The player runs the 32-bit code while mfpmp.exe runs the 64-bit code.

    Since this setup is sort of cumbersome to build and test while developing, I'd recommend testing with the 64-bit player until you're almost ready to release and then build both platforms. Then you only need to build/rebuild the 64-bit DLLs while developing.

    Thursday, February 22, 2007 1:00 AM
  • Thanks for the advice so far; I believe that I am closing in on the answer.  Unfortunately, I do not quite have it yet.

    I see a bit of activity on my plugin before rendering starts.  (I label this "housekeeping" below).  Then there are two interesting audio rendering options -- in-proc (or within the wmplayer.exe process) and out-of-proc (or within the mfpmp.exe process).  So I have these different scenarios where I expect my plugin to be used:
      (A) 32-bit WMP housekeeping:                       my 32-bit DMO is used
      (B) 32-bit WMP with in-proc rendering:             my 32-bit DMO is used
      (C) 32-bit WMP with out-of-proc rendering (mfpmp): my plugin is NOT LOADED
      (D) 64-bit WMP housekeeping:                       my 64-bit DMO is used
      (E) 64-bit WMP with in-proc rendering:             (could not make this happen)
      (F) 64-bit WMP with out-of-proc rendering (mfpmp): my 64-bit DMO is used

    The most important scenarios are (B) and (C) because we will be using a 32-bit WMP, and (C) is not working.  From the information I have so far, I would expect (C) and (F) to be the same rendering case, but I get different results.  Is something handed off from WMP to MFPMP that qualifies which plugins can be loaded?

    I tried mixing up the regsvr32 (from SysWOW64 and System32) and the target DMO to register (my 32-bit and my 64-bit version).  I could not find a combination that gets (C) to work.

    I tried changing the CLSID so that the 32-bit and 64-bit versions have different GUIDs.  That also did not seem to help.

    Do you see anything else that I have missed?

    Friday, February 23, 2007 2:13 PM
  • Hmm, that's strange. If (B) and (F) both work, then it seems (C) should work. Can you give the value of the following reg key in both the 32-bit and 64-bit registries?

    HKLM\Software\Microsoft\MediaPlayer\MediaPlugins\DSPConfig\<Your CLSID>\PipelineMode

    To answer your question about how WMP communicates to MFPMP what plugins to load, WMP gives MFPMP the CLSID of the plugin to load, so for this to work the 32-bit and 64-bit DSPs must register using the same CLSID. If you changed the CLSIDs you should go back to them being the same.

    Also, just to make sure, verify that the content you're playing for (C) is clear content. MFPMP will not load uncertified plugins when playing protected (DRM'd) content. Currently, MP3 and ASF (WMA/WMV) files play out-of-proc (with a few exceptions), while all others (ex. WAV, AIFF, etc.) play in-proc.

    Finally, do you get the same problem when you build the DMO generated by the WMP DSP wizard from the Windows SDK? I just tested this myself on x64 Ultimate RTM and have the scenario with 32-bit player and 64-bit mfpmp.exe working fine with the sample DSP (as well as (B), (E), and (F)). You get 4 files in this case, the 32-bit DSP and proxy/stub and the 64-bit DSP and proxy/stub. You have to register them all.

    Friday, February 23, 2007 10:54 PM
  •  

    Thanks for the new info.

     

    I am running now with the same CLSID for both my 32- and 64-bit DMOs.

     

    The PipelineMode value that you asked about is 3 for both 32-bit and 64-bit versions of my DMO - CLSID 776718B9-F083-415A-B6A3-7027683B7B78:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MediaPlayer\MediaPlugins\DSPConfig\{776718B9-F083-415A-B6A3-7027683B7B78}

                PipelineMode     0x3

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MediaPlayer\MediaPlugins\DSPConfig\{0FD02159-F616-45C9-88C8-9B2046FE6BF9}

                PipelineMode     0x3

     

    HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MediaPlayer\MediaPlugins\DSPConfig\{776718B9-F083-415A-B6A3-7027683B7B78}

                PipelineMode     0x3

    HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MediaPlayer\MediaPlugins\DSPConfig\{0FD02159-F616-45C9-88C8-9B2046FE6BF9}

                PipelineMode     0x3

     

    Yes, I am using clear content; my testing has been primarily on a set of mp3 tracks.  (I also used a WAV track to confirm that my secenario (E) above works.)

     

    I am running Windows Vista Ultimate RTM, 64-bit.

     

    I built an Audio DSP with the Windows Media Player Plug-in Wizard -- that is the "0FD02159-F616-45C9-88C8-9B2046FE6BF9" CLSID in the above registry samples.  I built and registered 32-bit DMO and proxy stub and 64-bit DMO and proxy-stub.  I get the same results for the (A) through (F) scenarios -- notably, scenario (C) did not work even for the new DMO from the Wizard.

    I modified the Wizard's generated source only to log text lines (to a file) in FinalConstruct(), FinalRelease(), ProcessInput(), and ProcessOutput(); and I modified the build configurations to include an x64 platform version.

    It is from my inserted logging that I determine that the Wizard-generated DMO is not loading in the mfpmp.exe process when starting from the 32-bit Media Player process, but it is loading (and included in rendering) for the other cases.

     

    From all of this, can you identify what is different for me vs your sample DSP?

     

    Tuesday, February 27, 2007 12:39 AM
  • Well, the "PipelineMode" reg values look correct. 3 means that WMP should be handing the CLSID's off to mfpmp.exe to instantiate in the pipeline.

    MP3 content should make fine testing material. However, just to be sure, can you also try the WMA sample clips that come with Media Player? Those are clear and known to work with the DSP plugins.

    Finally, can you see if mfpmp.exe is running as a protected process in your scenario (C)? This would be a bug if the content is clear and you have a plugin registered, but knowing this can help with the diagnosis. To quickly check if it's running as a secure process, I usually just try to change the process priority in an elevated task manager. If it's an unprotected process, the priority change will succeed. If it's a protected process, task manager will issue an "Access is denied" error.

    I'm still trying to reproduce the problem you describe on my own machines, but have been unsuccessful. I just did the following as another test:

    1. Install Vista Ultimate RTM x64 on clean machine.
    2. Install Visual Studio 2005 Professional.
    3. Install Vista RTM Windows SDK (x86 + x64 compilers).
    4. Install WMP11 sample DSP wizard from SDK.
    5. Generate audio DSP project with wizard. Build 32-bit DMO + proxy/stub. Register.
    6. Add new x64 build config. Build 64-bit DMO + proxy/stub. Register.
    7. Playback WMA sample clips in the library. Playback MP3 test files.

    All the scenarios, including 32-bit player/64-bit mfpmp.exe (C) are working fine. Since we're getting different results with the same sample code, this might be a machine configuration problem. Would it be possible for you to try your plugins on another machine? If not, could you give some more details about your build/test environment (Visual Studio version, building on same machine/other machine, any other WMP plugins or related software installed, and the audio hardware you're using)?

    Thursday, March 1, 2007 12:46 AM
  • Below is a sequence of observations over a couple of days.  In the end, I have seen my 64-bit DMO load and run when mfpmp.exe is kicked off by a 32-bit WMP (my formerly failing scenario C).  I do not understand how it got that way.

    Using tracks from <C:\Users\Public\Music\Sample Music>:
     - Amanda.wma
     - Despertar.wma
    I ran wmplayer.exe 32-bit and 63-bit on multiple Vista 64-bit systems.


    Thursday:
    Showing processes from all users in Windows Task Manager on my development system:
    When running the 32-bit wmplayer.exe, right-click->Set Priority on mfpmp.exe to Above Normal
       o choose "Change priority" on a dialog
       o message box: The operation could not be completed.  Access is denied.
    When running the 64-bit wmplayer.exe, right-click->Set Priority on mfpmp.exe to Above Normal
       o choose "Change priority" on a dialog
       o Worked! - priority now shows as Above Normal

    I then tried 2 other 64-bit Vista Ultimate machines (let's call them "Don" and "Bob").  Both of those resulted in an Access-is-denied protected process for mfpmp.exe for BOTH the wmplayer.exe 32-bit and the wmplayer.exe 64-bit cases.

    The configuration on my development system:
     - Visual Studio 2005, Version 8.0.50727.762 (SP.050727-7600)
     - I am both building and running on the system that exhibits the difficulties.
     - I have run with similar results with the DFX For Windows Media Player DSP installed and removed (http://www.fxsound.com/dfx/).  I have not installed any other plugins.
     - In my system's Device Manager, under "Sound, video and game controllers" I have only "High Definition Audio Device", which has a Microsoft driver of date 6/21/2006 and version 6.0.6000.16386

    The configuration for "Don":
     - no Visual Studio installed
     - no other WMP plugins have been installed (nor did I register my own DMO nor the DMO built from the Visual Studio WMP Plugin wizard)
     - Device Manager shows "High Definition Audio Device", which has a Microsoft driver of date 6/21/2006 and version 6.0.6000.16386

    "Bob" system also has "High Definition Audio Device", and is a clean Vista Ultimate installation.


    Friday:
    From my development system, I see the correlation between a protected mfpmp.exe process (as revealed by the ability to change Priority) and my 64-bit WMP DMO loading/running.

    You also wrote that mfpmp.exe should be an unprotected process for clear content AND(?) if there is a plugin registered ... Does that mean that mfpmp.exe should be a protected process if there are no plugins registered? 

    On attempting to register the Studio WMP plugin Wizard sample DMO on "Don", my registrations failed; so I installed Visual Studio 2005 (and all the suggested updates).  Then my registrations succeeded AND my 64-bit plugin gets loaded in the mfpmp.exe process both when started with 32-bit WMP and when started with 64-bit WMP.  I confirmed that I could change process priority as well in both of those cases.  The registered plugins here are in a file path from <C:\Program Files (x86)>.

    My first system had the 32-bit and 64-bit plugin registered in a path from <C:\Src>.  I re-registered these in a path from <C:\Program Files (x86)>, and they started to work.  I can also change the priority on my mfpmp.exe process.  I then re-registered the 64-bit plugin in a path from <C:\Src> and it continued to work.

    So did the mfpmp.exe process somehow change to unprotected in my sequence?  Did it change because I installed Studio 2005?  Or did it change because I registered the plugins in a "Program Files" path?  Is there something that I have done or can do to change whether mfpmp.exe runs as a protected process?

    Friday, March 2, 2007 8:22 PM
  • I'm glad you were able to get scenario (C) working! I'm stumped as to why it suddenly started working when you changed the location of the DSPs though. I build a bazillion DSPs in various folders (including C:\Src) and I could not reproduce your issue. Might there be a permissions issue with your C:\Src folder that is interfering? Do you have UAC enabled/disabled?

    Also is this reliable? Can you build a brand new DSP in C:\Src, register it and not have it work, then re-register it in C:\Program Files (x86) and make it work again?

    When you registered your DSPs on "Don," were you using "Debug" bits? If so, you probably had to install Visual Studio to get the debug runtime. "Debug" built stuff won't load (register) since it has a dependency on this debug runtime. You should be able to register your plugins on a clean machine with "Release" bits since Vista includes the retail runtime. You might want to try this if you can to eliminate the possibility that installing Visual Studio somehow causes scenario (C) to start working.

    To answer your question about mfpmp.exe running as a protected process, it runs protected unless the content is clear AND a plugin is registered (and loaded into the topology). So yes, mfpmp.exe will run protected if there are no plugins registered or the plugin does not fit into the topology for some reason (incompatible media types, no out-of-proc support, loading errors, etc.)

    I'm thinking that mfpmp.exe running secure when your scenario (C) was failing may be more of a side-effect of the failure rather than the cause. Still, I can't think of a good explanation of why any behavior would have changed based on the path. If you can reliably cause scenario (C) to fail again with a new DSP plugin, we can continue to investigate this if you're still interested.

    Wednesday, March 7, 2007 2:38 AM
  • As a non-windows programmer, I followed this tread with interest.  I have the same issues as described.  I run MS Vista Ultimate.  I am using WMP 11.  I have installed DFX by FXsound.com.  But DFX is not working with WMP.  This all works fine on XP.  But I'm sure you know this.   Is there anything I can do to kick this into action, or will I have to wait for FX sound to recompile?

     

    Allergen

     

     

    Monday, April 2, 2007 6:05 PM
  • Is this on 32-bit or 64-bit Vista Ultimate? (To find this information, go Start -> Computer -> Click "System Properties" button -> Look at "System type:" field.)

     

    If 64-bit, it appears the plugin does not install 64-bit copies of the DSP, and so the 64-bit MF cannot use them. Unforunately, there isn't a workaround, so you'll have to wait until they release a 64-bit version.

    Wednesday, April 4, 2007 1:54 AM
  • I assumed this thread was just talking about Vista 64 issues.  Anyway, just feeling some pain.  Sad

     

    General Question;  How much support does 64 bit OSs (Microsoft) receive from the third-party community? 

    This is my first 64-bit OS.  It came on my new laptop.  It didn't occur to me to determine 32 or 64 bit when I was placing the order.  Live an learn.

     

    Thanks,

                   Allergen

    Wednesday, April 4, 2007 3:45 PM