3

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?

Update

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.

2
  • 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. Apr 12, 2011 at 17:30
  • @Amazed not a bad idea. I'll give it a shot.
    – 3Dave
    Apr 12, 2011 at 19:29

2 Answers 2

2

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?

and http://support.microsoft.com/kb/310405

1
  • System restore is disabled.
    – 3Dave
    Apr 12, 2011 at 17:03
1

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".

6
  • WFP doesn't protect third-party files, though. Apr 12, 2011 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, 2011 at 17:18
  • No events in the logs related to WFP. =/
    – 3Dave
    Apr 12, 2011 at 17:21
  • Also, the DLL isn't in the DllCache folder. =/
    – 3Dave
    Apr 12, 2011 at 19:31
  • @DavidLively, have you read the edit to this answer?
    – bwDraco
    Apr 12, 2011 at 20:01

You must log in to answer this question.

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