Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Our sales guys have an in-house application installed that uses a few custom COM objects/DLLs stored in System32. I've been trying to replace one of these DLLs with a newer version, which works fine after the installation, but not after a reboot.

Here's the interesting part.

  1. I unregister the old DLL with regsvr32 /u myDll.dll
  2. Regsvr32 shows a dialog indicating success.
  3. I copy the old DLL into a "save" folder, and rename it to 20110412-myDll.dll_.
  4. I delete the original from system32.
  5. I put the new DLL in system32.
  6. Register the new dll with regsvr32 myDll.dll
  7. Test new DLL with a VBScript - works fine.
  8. And the fun part
  9. Reboot.
  10. Re-run test vb script. It fails.
  11. Look at the DLL (which I replaced) in system32. It has been magically replaced by the old DLL. I verified this with fc (binary compare) with system32\myDll.dll and the saved 20110412-myDll.dll_.
  12. DELETE the old DLL. Verify that it is, in fact, gone.
  13. Search all drives for "myDll.DLL", including system folders. Verify that there are no instances of the old DLL other than the renamed version in the "save" folder.
  14. Reboot
  15. The old DLL has, again, magically reappeared.

The user account I'm using for this has full admin rights to the machine. I haven't been able to find any running process that should do this, and our IT department is stumped.

Anyone have any suggestions?


Just for the hell of it, I started one of the machines in safe mode, installed the new DLL, and restarted again. This time the change appears to have worked, even after a subsequent restart. Weird.

I can do this on the other machines that exhibit the same problem, and I expect it to work, but I'd really like to know what the problem is. Argh.

share|improve this question
Maybe doing steps 1-7 and then setting up Process Monitor in boot logging mode to see which process is replacing the file. Should give you some clue as to what's going on. – Andrew Lambert Apr 12 '11 at 17:30
@Amazed not a bad idea. I'll give it a shot. – David Lively Apr 12 '11 at 19:29

This is most likely a problem with System Restore. Try disabling it before replacing the DLL.

For more info, see What is System Restore in Windows operating systems?


share|improve this answer
System restore is disabled. – David Lively Apr 12 '11 at 17:03

The system is replacing the DLL with the file in C:\Windows\System32\DLLCache by Windows File Protection. Check the System log in Event Viewer (in Administrative Tools) for this event:

Event ID: 64001
Source: Windows File Protection
Description: File replacement was attempted on the protected system file C:\Windows\System32\myDll.DLL . This file was restored to the original version to maintain system stability. The file version of the system file is x.x:x.x. 

Try deleting the DLL file stored in DLLCache, replace the DLL in System32 again, then reboot the computer

Edit: Check the logs in your security software, since some security programs monitor system DLLs and block attempts to replace the file. You can also try using Process Monitor to check what program is replacing the DLL, especially during startup with the "Enable Boot Logging" feature located under "Options".

share|improve this answer
WFP doesn't protect third-party files, though. – Andrew Lambert Apr 12 '11 at 17:13
This is probably still worth checking; if this event shows up in the logs, then it would explain the problem. – bwDraco Apr 12 '11 at 17:18
No events in the logs related to WFP. =/ – David Lively Apr 12 '11 at 17:21
Also, the DLL isn't in the DllCache folder. =/ – David Lively Apr 12 '11 at 19:31
@DavidLively, have you read the edit to this answer? – bwDraco Apr 12 '11 at 20:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .