Solved Cannot repair member file [l:12{6}]"mf.dll" of Microsoft-Windows-MediaFoundation

I don't know why this file is being flagged by SFC scannow, but it keeps repeating in the log output.

Cannot repair member file [l:12{6}]"mf.dll" of Microsoft-Windows-MediaFoundation, Version = 6.0.6002.18392, pA = PROCESSOR_ARCHITECTURE_AMD64 (9), Culture neutral, VersionScope = 1 nonSxS, PublicKeyToken = {l:8 b:31bf3856ad364e35}, Type neutral, TypeName neutral, PublicKey neutral in the store, hash mismatch.

Click to expand...

After reading up on similar problems, I learned that the approach is to replace the file with a trusted original copy. So, I installed 7z in order to view my Vista Ultimate install disks and extracted "mf.dll" from the appropriate image (#4, for Ultimate). And yes, I did make sure I had selected the x64 disk (not x32).

When I compared the two files, it was clear that they were slightly different in size, so the one that was in the System32 folder was not original... not to mention the fact that it was dated November 7th of 2012. I executed takeown (takeown /f c:\windows\system32\mf.dll) and icacls (icacls c:\windows\system32\mf.dll /grant administrators:F), then copied it over the current file with no problem, followed with a reboot. I then ran SFC scannow again...

Same problem. SFC scannow keeps flagging it. Incidentally, I noticed there's another copy of this file in SysWOW64, but it's of a smaller size than both of the others.

What should I do?

OK, I did some investigating and found that under the Winsxs sub folder off of C:\Windows, there are numerous copies of mf.dll that are of many different sizes (11 distinctly different ones in fact, ranging from 2,789 to 3,467).

Oddly, the "winsxs\backup" folder does not contain a single instance of "mf.dll". They're all in "winsxs".

My installation is fairly recent (I got a new hard drive and installed Windows Vista Ultimate successfully). I do not have any operational issues and very few errors appear in the event logs. The largest software package I installed so far is Office 2007.

I'm baffled as to why there are so many different media foundation DLL's, but then I don't have a working knowledge of how "mf.dll" functions in the system. But why does SFC find it corrupt? My previous Vista Home Premium installation did not have this problem.

Any ideas?

Hi,

I would suggest that you start again & do a fresh install (Genuine disks) of your new system.

Incidently I have several copies of that file, all differnet versions & sizes. Therefore this file is updated at times & Sp's etc...

Your CBS log will tell us which one is the valid replacement. From there, we need to perform the replacement and reset the ACL back to TrustedInstaller.

Could you zip up and upload your CBS log to your next post please?

C:\Windows\Logs\CBS\CBS.log

Tom

Thanks a lot for your reply, Tom. I had checked the file and saw which mf.dll files were being complained about, but the reference being compared isn't listed as a full file. The good thing is that it's just 2 mf.dll files, namely:

• \SystemRoot\WinSxS\amd64_microsoft-windows-mediafoundation_31bf3856ad364e35_6.0.6002.18392_none_fa04f953c28c8dee\mf.dll
• \Windows\System32\mf.dll

The trouble is that there's 11 distinctly different sized copies of this file, so I don't know which one is being referenced. I've attached the CBS log. Thanks again!

Hi Cytherian,

Thanks for the log! The CBS log is showing that this file:

C:\Windows\System32\mf.dll

Needs to be replaced with this one:

C:\Windows\WinSxS\amd64_microsoft-windows-mediafoundation_31bf3856ad364e35_6.0.6002.18392_none_fa04f953c28c8dee\mf.dll

But SFC failed to do so. Let's try and do it with a batch file, but I doubt it will work. We will probably have to copy this file from the recovery environment as it is most likely in use, but it's worth a shot!

Batch File

Warning: this fix is specific to the user in this thread. No one else should follow these instructions as it may cause more harm than good. If you are after assistance, please start a thread of your own.

1. Click on the Start
   
   button and in the search box, type Notepad and click on it
2. Copy (Ctrl+C) all of the text in the following box and paste (Ctrl+V) it into Notepad
   Code:

   ::tom982 SFC Batch File Creator 2012
   if not exist %SYSTEMDRIVE%\tom982 mkdir %SYSTEMDRIVE%\tom982
   icacls   C:\Windows\WinSxS\amd64_microsoft-windows-mediafoundation_31bf3856ad364e35_6.0.6002.18392_none_fa04f953c28c8dee\mf.dll  /save %SYSTEMDRIVE%\tom982\aclbackup
   takeown /f  C:\Windows\WinSxS\amd64_microsoft-windows-mediafoundation_31bf3856ad364e35_6.0.6002.18392_none_fa04f953c28c8dee\mf.dll
   icacls   C:\Windows\WinSxS\amd64_microsoft-windows-mediafoundation_31bf3856ad364e35_6.0.6002.18392_none_fa04f953c28c8dee\mf.dll  /grant administrators:F
   ren C:\Windows\WinSxS\amd64_microsoft-windows-mediafoundation_31bf3856ad364e35_6.0.6002.18392_none_fa04f953c28c8dee\mf.dll *.bak
   copy  C:\Windows\System32\mf.dll  C:\Windows\WinSxS\amd64_microsoft-windows-mediafoundation_31bf3856ad364e35_6.0.6002.18392_none_fa04f953c28c8dee\mf.dll
   icacls   C:\Windows\WinSxS\amd64_microsoft-windows-mediafoundation_31bf3856ad364e35_6.0.6002.18392_none_fa04f953c28c8dee  /restore %SYSTEMDRIVE%\tom982\aclbackup
   sfc /scannow
   copy %SYSTEMROOT%\Logs\CBS\CBS.log %USERPROFILE%\Desktop\CBS.txt
   start notepad.exe %USERPROFILE%\Desktop\CBS.txt

3. Go to File > Save As... and save it to your Desktop named fix.bat. Make sure you change the Save as type to All Files (*.*)
4. Locate fix.bat on your Desktop and right click then select Run as administrator

Upload the file on your Desktop, CBS.txt, to your next post

Tom

Won't work, Tom - the source file is also corrupted.
You need to replace the WinSxs file and then use SFC to replace the active one.....
(do you want to do it, or shall I?)

NoelDP said:

Won't work, Tom - the source file is also corrupted.
You need to replace the WinSxs file and then use SFC to replace the active one.....
(do you want to do it, or shall I?)

Click to expand...

Thanks for spotting that Noel, I need more sleep! I'll give it a go and try and redeem myself!

Managed to grab a clean copy of the file from an update If anyone happens to stumble upon this post when researching something, it was this update:

Platform Update Supplement for Windows Vista and for Windows Server 2008

Please download the attached file, packs.zip, and extract this to the root folder of your primary drive (usually C:\) so that the folders have the structure: C:\Packs\Windows... etc.

View attachment 27762

You will now need to boot into your Vista DVD. After selecting the language, click Repair Computer then click Command Prompt. In this Command Prompt window, type out the following command, double checking it for typos before pressing enter:

robocopy C:\Packs C:\ /E /IS

Then reboot your computer, run another SFC and post the CBS log please.

Tom

Thanks for all of your work on this Tom, and your helpful advice on this Noel.

I had done a fresh install of Vista Ultimate, then applied SP1 and SP2, followed by numerous updates automatically applied by Microsoft. I didn't run into any errors or anomalies. Strange how the mf.dll became "corrupted", isn't it? I quoted it, as the current file seems to be doing its services OK.

Anyway, I'll try the fix after I get a good night's rest, and let you know how it goes.

NoelDP said:

Won't work, Tom - the source file is also corrupted.
You need to replace the WinSxs file and then use SFC to replace the active one.....
(do you want to do it, or shall I?)

Click to expand...

Noel, how were you able to determine that the source file is corrupt as well? Is there some other check that Windows does that can make that determination?

tom982 said:

Managed to grab a clean copy of the file from an update If anyone happens to stumble upon this post when researching something, it was this update:

Platform Update Supplement for Windows Vista and for Windows Server 2008

Please download the attached file, packs.zip, and extract this to the root folder of your primary drive (usually C:\) so that the folders have the structure: C:\Packs\Windows... etc.

You will now need to boot into your Vista DVD. After selecting the language, click Repair Computer then click Command Prompt. In this Command Prompt window, type out the following command, double checking it for typos before pressing enter:

robocopy C:\Packs C:\ /E /IS

Then reboot your computer

Click to expand...

Tom, thanks a lot for going to the trouble of locating the file and then extracting it for me. Much appreciated! I'm sorry it took me a while to confirm the outcome. I got sidetracked and had forgotten about this issue (it's definitely not critical and I never see any errors, unless running SFC /scannow). Periodically I do a look-up of threads I started and see if there have been replies, and spotted this.

Getting back on track, I went ahead and decompressed the files in the appropriate location, rebooted into the repair command prompt, and ran the robocopy command. I see now why you went this route, to ensure no system files were in use (and thus might prevent a file from being copied over).

The result? After rebooting I ran the SFC scan and....... no errors. I'm still a bit baffled as to how this came up to begin with. I guess with all of the mf.dll versions floating around, somewhere along the line Windows must have tripped over itself and got confused, unable to recover. While I understand Microsoft's approach, I'd expect something like the mf.dll being core to the Windows system would motivate higher QC when patches are created that make any replacements of the file.

Anyway... thanks again.

Cytherian said:

Noel, how were you able to determine that the source file is corrupt as well? Is there some other check that Windows does that can make that determination?

Click to expand...

That's what SFC does

Yes, it did identify corrupt instances of mf.dll... I'm just not understanding how it does this. Winsxs houses a number of versions, some within separate folders and others renamed with a numeric extension under the Backup folder. I understand that as certain programs are installed that an updated mf.dll may be deployed, and thus the older one is backed up for safe keeping in case that software is ever uninstalled. And then an "active" copy is retained in case of a system corruption. Is there some update trace logged somewhere that SFC is referencing?


Part of why I want to understand this better is that I modified my "imageres.dll" file, so that I could have a different Windows startup sound (baffles me why they had to embed the WAVE file inside it). Anyway, I successfully replaced it and it works, but SFC complains about it. I built a "Packs" folder much like what Tom created, replicating the structure and file naming convention of the imageres.dll files and backups, then copied the same file to all of them. I did the robocopy successfully. However, SFC now not only complains about the imageres.dll, but also the store copies.

So, SFC must be referencing something else. I checked the manifest files and didn't see any checksum or hash info contained within. The only other files I see are ".mui", but those are for multilingual purposes. Is the hash reference in the registry somewhere?

I'm not entirely sure how it all works in Windows 7/Vista, but in XP there was a file called sfcfiles.dll that contained the list of files and hashes to cross reference anything found in an SFC scan.

As you correctly said, the winsxs folder contains all version of Windows Update files that have ever existed on the PC. This is simply to allow third party software to function correctly, even if it isn't designed for use with the latest version of the .dll residing in the system32 folder

Yeah, doesn't look like there's anything like sfcfiles.dll now... Microsoft changed tactics.

I wonder... would running the dll registrator make this work? I'm thinking that if this makes an "officially recognized version" of the file, that SFC would stop calling it suspect.

I did find an interesting utility on a website (winaero.com) that breaks out the reference to a physically separate wave file, which you can then easily change at will. I think I may try this out and see if it works. Although the SFC errors won't cause any problems, I'll just feel better about them not being there (and avoid future concerns if the DLL gets replaced).

I think in Win7, there is multiple redundancy - the Manifest files tell the system which files should be present, the CAT files tell the expected filesize and signatures, and there's an element in the registry (and elsewhere?) that hangs things together - any mismatch between them and SFC screams about it.

How Windows Vista manages it is a mystery. It appears to be dynamic in nature, based on what happened next.

So, originally I had replaced my imageres.dll with a modified one that incorporated a replacement WAVE file. I kept a backup of the original, of course. Well, I went ahead and put the original back into all the previous places, rebooted, then ran SFC. SFC found hash problems with all of them. And I was sure to catch them all, in system32, SysWOW64, Winsxs(several sub folders). So the reference hash information changed somehow.

I've been running with the modified imageres.dll for quite a while now, so the restore point is far back enough that it would be a major pain to restore it (I installed more software since then, which would all have to be installed again).

I have learned my lesson about mucking around with system files before having a deeper knowledge of the ramifications. But now... any suggestion as to how I should proceed? Should I reboot and run a Windows Repair?

We can grab the latest version from a Windows Update I'll need a bit of information though, as there's no way of seeing what's inside an undocumented update without trying all of them individually - and I don't particularly fancy sifting through however many GB of updates there are!

System Look

Please download SystemLook from one of the links below and save it to your Desktop.

• Double-click SystemLook.exe to run it.
• Copy the content of the following codebox into the main textfield:
  
  Code:

  :filefind
  imageres.dll

• Click the Look button to start the scan.
• When finished, a notepad window will open with the results of the scan. Please post this log in your next reply.

Note: The log can also be found on your Desktop entitled SystemLook.txt


I would also like you to zip up, and attach, the following file please:

C:\Windows\system32\config\COMPONENTS (It has no file extension)

Tom

Hi Tom, thanks a lot for your attention on this. I ran System Look and it found the same file in all the places I had placed it (text file attached).

I wasn't aware of this components library. Interesting. Anyway, I can't copy it despite taking ownership. It's open and in use by a system process. Do I need to reboot into repair mode in order to get access to it?

I tried a number of ways to copy "COMPONENTS" but none of them worked (file in use), so I booted with the repair disc mode and that worked. I used WinRAR to compress it, which ended up being 10Mb (down from 54Mb), but I can't attach it. Here's a dropbox link instead.

The COMPONENTS file is a registry hive containing all of the information on Windows Updates

I traced the origin of your version of imageres.dll and unfortunately, it's not from an update, it's a file that can be found on a RTM disc. I'm downloading the x64 install.wim and I'll extract it from there for you. It's downloading at ~9MB/s so it'll be done in a few minutes, then I'll have to find it and upload it for you.

Tom