Do you have a problem with explorer.exe using high CPU, showing 100% CPU usage (per CPU core) in windows 7, Windows server 2008 or windows 8? ie. It might show as using 50% CPU on a dual core or 25% on a quad core machine…
Task manager shows explorer.exe and/or dllhost.exe using loads of CPU? Have you recently exported .wav files which contain markers in them using Sony SoundForge, Image-Line FL Studio or any other audio software? Maybe the files are either on the Desktop, ‘My documents’, or somewhere else which is in the path for search indexing? Or are you trying to move or delete some .wav files but can’t as they are locked ‘in use by another program’ ? Or just when you open a folder containing these .wav files with markers in them, explorer seems to take forever… If so, read on.
Microsoft claims these are ‘corrupted’ .wav files but they’re not, it seems it’s only a new problem since window 7. The solution is to disable windows explorer from trying to extract the metadata from the .wav files (by using mf.dll which fails to do it correctly, gets confused and becomes stuck in a loop forever.)
Some related files:
Here is a description and explanation from Microsoft:
High CPU usage in the Explorer.exe process when you open a folder that contains corrupted .wav files in Windows 7 or in Windows Server 2008 R2 SYMPTOMS You have some corrupted .wav files in a folder on a computer that is running Windows 7 or Windows Server 2008 R2. When you open the folder, you encounter the following problems: The computer responds slowly. You cannot perform any other operations. You experience high CPU usage in the Explorer.exe process. Note To temporarily resolve these problems, restart the Explorer.exe process. For more information about how to restart the Explorer.exe process, see the "More Information" section. You may also encounter problems when you use other applications or operations to open the corrupted .wav files. For example, if you try to use Windows Media Player to open the corrupted .wav files, Windows Media Player stops responding. Additionally, the Wmplayer.exe process generates high CPU usage. CAUSE When a folder that contains corrupted .wav files is opened, Windows Explorer calls the Media Foundation (Mf.dll) function to extract metadata from the .wav files. However, the Mf.dll function enters an infinite loop when extracting the metadata.
You can try their official hotfix there also, (doesn’t work lol) but an actually working solution is this:
Download the following zip and open it, double click on Fix.reg and add the information to your registry, then reboot:
An ‘unfix’ is also provided in the zip, though you won’t be needing that.
The solution and registry fix was originally found here: http://superuser.com/questions/233223/prevent-windows-explorer-from-trying-to-extract-metadata by Wojtek and also some extra information and an explanation of how that works by Gwideman:
Adding a bit of explanation: What this fix does is disable the "PropertyHandler" dll for files having a particular filename extension (here, '.wav.). The registry should already contain the mentioned keys, with the default value shown. In the .reg files shown here, '@=' means 'default value'. The '#' sign prepended to the GUID apparently just makes the GUID invalid, but preserves it for future reference.
So if you are full nerd mode, that’s how it works. There is apparently the same sort of issue with some video files and formats so you could simply find and edit the property handlers for any type of file extension like that, if one so wanted to.
And here is some more info on this error from one of the Fl Studio developers, Didier Dambrin (Gol):
What they might be calling "corrupt" is a misinterpretation of the wav file format on their side. There is a legacy bug by Sonic Foundry (now Sony) in the association of a MIDI note to a wav marker, only Soundforge & FL reads it, and it has to be buggy on purpose (wrong marker ID used) for it to load in Soundforge. Probably Microsoft isn't aware of that, but a bug in a format becomes part of history & thus part of the format. That or they have a bug somewhere else.
// cue triggers
for m:=0 to High(Regions) do if Regions[m].ID>=0 then
with SampleTriggerChunk do
dwIdentifier:=Regions[m].ID-1; // don’t forget the -1 (bug in SoundForge)
dwType :=1; // MIDI Command Trigger
dwFunction :=0; // Play
// size of the trigger list chunk
Hope this helps… Don’t forget to reboot! It won’t work until then.