2020. 2. 17. 23:22ㆍ카테고리 없음
Download Windows File Protection (WFP) Service Patcher or Switcher Whenever you want to modify, delete or replace an existing system file in Windows 2000, XP or Windows Server 2003, you can't do that. Windows shows an error message that the file is already in use. It happens due to Windows File Protection (WFP) service which runs in background and regularly checks system files integrity. If it finds that a process is trying to modify a system file, it blocks the operation and shows the error message. But if you are a customization lover, you might face this situation many times while trying to replace or modify system files to change look-n-feel of Windows UI.
Now what to do? One way is to use software which can be used to replace system files at system startup. But there is another way which is mentioned below.
Wfp Patcher Download
Today we are going to share a free and portable utility ' WFP Switcher' which patches Windows 2000, XP and Server 2003 and disables Windows File Protection (WFP) service so that you can easily modify or replace system files without any problem. You just need to run the patcher and click on ' Patch' button. It'll disable the WFP service and you'll be able to edit, delete or replace system files on the fly. The tool also allows you to re-enable WFP service any time if you want.
Wfp Patcher
The official download link is no longer available but you can download it using following alternative link: NOTE: If your antivirus program detects this tool as a virus, don't worry about it. Its a false positive. Since this software modifies system file in Windows, many antivirus software detect it as a suspicious item.
It's telling you that the OS version of the expsrv.dll file is older than the one you are trying to install. You can disable Windows File Protection and then install the software, but I would first back up the current expsrv.dll file in the C: Windows System32 folder. After you back up the expsrv.dll file you can use a registry editor to browse to the key below modify the SFCDisable value to be 1 instead of 0. HKEYLOCALMACHINE SOFTWAR E Microsof t Windows NT CurrentVersion Winlogon OR you can place the text below (between the lines) into a file called SFCDisable.reg and double click it to import the information and disable WFP Windows Registry Editor Version 5.00 HKEYLOCALMACHINE SOFTWA RE Microso ft Windows NT CurrentVersion Winlogon 'SFCDisable'=dword:0000000 1. Another thing you can try is to add the expsrv.dll entry to the filelist.xml which will exclude it from file protection. To do this you will need to go to C: WINDOWS system32 Restor e In Restore folder, right click on filelist.xml and select properties. Uncheck the read only box and press OK.
Right click the filelist.xml and open it with a text editor such as notepad. In the section under, add the expsrv.dll entry and save the file. (Its about 4 or 5 lines down) The entry to add will look like the following.%windir% system32 exp srv.dll After you save and close filelist.xml, right click it and set it back to read only and try your install again. Isn't the 'C: WINDOWS system32 Resto re filelis t.xml' file used for 'System Restore'? I'm pretty sure that Windows Server 2003 is much the same as Windows XP in the way that it caches the files that are regarded as 'Protected' by the System File Protection.
Protected files are cached in C: Windows System32 dllcac he. Windows Updates, security patches, etc, are able to update the files in that folder, and copy additional new files there if they don't already exist. In the event that a file is modified or renamed in or deleted or moved from where it is installed, the System File Protection feature kicks in after a few moments and replaces/restores it with a backup copy from the dllcache folder.
Note: Disabling the System File Protection feature usually empties the dllcache folder and you have to repopulate it again, which is something that you really don't want to be doing unless you are forced to because of a virus or similar. The dllcache folder is a compressed folder, but there is usually nothing to stop you from making renamed backup copies of files in that folder and then copying alternative file versions in there. I have done this many times after deliberately modifying a particular file that happens to be protected. For example, the MSCONFIG dialog is not wide enough for my liking and has no maximize button. I always modify that dialog in the msconfig file and then replace it in the dllcache and its normal folder. That should, however, not be necessary. An installation package that is properly written to be fully compliant with a supported operating system and run from a profile with the correct permissions should be able to update files in the dllcache folder and the system folder where it copies the file.
The first place I would look is the system's 'dllcache' folder to see if 'expsrv.dll' actually does reside there. A quick way to dump the information, if you have the Support Tools installed, is to run the following command which will give verbose details of all instances of the named file recursing on the named path: filever /s /v c: expsrv.dll The next place I would look is to see if there are any events logged in the Windows Event Viewer (eventvwr.msc /s).
Perhaps the event log may provide some more details about the error situation. Let us know the results and we can probably suggest a remedy. Filelist.xml also works for Windows File Protection, System File Protection, however I tried it on multiple systems and it worked on some but not all systems. As for Disabling the System File Protection, I've never seen it empty out the dllcache folder, even on the systems that I recently tested.
BillDL is correct about the dllcache folder. In a simpler form, you can go to C: windows system32 dllcac he and rename the expsrv.dll file to something like expsrv.bak.
The Windows File Protection dialog box may pop up, but you can cancel out of it. After you cancel out of the box you should be able to install your application and Windows shouldn't complain about the file being replaced. Windows Server 2003 and Windows XP / 2000: Replacement of WFP - protected system files is supported only through the following mechanisms: -Windows Service Pack installation using Update.exe -Hotfixes installed using Hotfix.exe -Operating system upgrades using Winnt32.exe -Windows Update Replacing protected files. Replacing protected files by means other than these specified methods results in the original files being restored by WFP. The dllcache path will depends on the registry setting, see SFCDllCacheDir entry in having said above, probably sfs.exe can help to rescan for newer version. If it cannot find newer or get from past installation folder, it will eventually prompt user for media.
Still think purging option would be alternative. Do backup before testing. Bozos22: You are correct about the disabling of the Windows File Protection not purging the DllCache folder. I was confusing the results with an old batch file I had that disabled the protection AND purged the cache. My apologies. You can disable Windows File Protection in 2 different ways depending on what value you place against the 'SFCDisable' value in: HKEYLOCALMACHINE SOFTWA RE Microso ft Windows NT CurrentVersion Winlogon 'SFCDisable'=dword:0000000 0 Windows File Protection enabled and running normally.
'SFCDisable'=dword:0000000 1 Disables Windows File Protection and issues a warning (from sfcos.dll) that it is disabled, plus a prompt to enable it until the next reboot. If you click 'Yes' it enables WFP for the rest of the session but will issue a warning message to administrators and a prompt to re-enable it on each reboot until set back to a Zero value again. 'SFCDisable'=dword:0000000 2 Disables Windows File Protection at the next reboot with no warning messages or prompts to re-enable it.
Hi Jerzak: Have you considered trying a few of the Windows Installer command line options? A verbose log may provide more detail about the actual error situation. There are switches that allow you to 'reinstall' a package and you can control what happens if the same file is already installed. Expsrv.dll = Visual Basic for Applications Runtime - Expression Service. If this process is unavilable VBA will not work and so macros and scripts used in Microsoft Office will cease to function.
I have Windows XP SP3 with Office 2003 Pro installed, but hopefully there will be enough in common with Server 2003 to make sense of this. There is something strange about expsrv.dll. In the File Properties dialog General tab, it shows as version 6.0.72.9590 at the top, but when clicking on the 'File Version' item under the Version tab it shows as 6.0.9589. As expected, the same is true of the version present in my System32 folder and the files are identical on a binary comparison. The file shows with a 'Modified' date/time of '14 April 2008, 04:41:54'.
Looking inside the DLL's resources, I see the following: FILEVERSION 6,0,72,9590 PRODUCTVERSION 6,0,72,9590 Clearly there is some kind of bugginess with this particular DLL where it is being wrongly seen as an older version than the one in the setup package, even though they are most likely the same version. There are only two instances, apart from the 'language version' details, of this DLL in my registry: HKEYLOCALMACHINE SOFTWARE Microsoft Windows CurrentVersion Installer UserData S-1-5-18 Components DC8D5505AC594D11EA7B000B0D91CC5A 'EBD9F446BDECFA54CA8B2E66297BF426'='C? WINDOWS system32 Expsrv.dll' HKEYLOCALMACHINE SOFTWARE Microsoft Windows CurrentVersion SharedDLLs 'C: WINDOWS system32 Expsrv.dll'=dword:00000002 Select all The DWORD value of 2 is a reference count of how many additional setup packages have laid a shared claim on the file since it was originally installed: So, in my case Windows XP Pro installed this file, and then when Office 2003 was installed it declared that it would use this DLL from the System32 folder also. The same observation of the file versions is true for the one installed by XP Pro, ie. It shows in the General tab as version 6.0.72.9590 at the top, but when clicking on the 'File Version' item under the Version tab it shows as 6.0.9589.
The file 'sfcfiles.dll' in the System32 folder (in XP this is a modified Win2000 file) is the one that actually contains the list of protected files, as can be seen in a hex editor: It is possible to singularly exclude expsrv.dll from the list of protected files by adding a Zero in front of its name in a hex-editing utility, but I DO NOT recommend this. If you know enough about modifying MSI packages (eg. Using the ORCA.EXE program from the Windows Installer SDK): then you may be able to modify the setup package so as to prevent it from actually trying to copy 'expsrv.dll' to the System32 folder. Again I DON'T recommend this. Personally I would first check the Fujitsu support site for your version of their Financial management software and see if they have acknowledged your issue as a problem and created a patch or workaround. I suspect that the anomaly between version numbers in the same file may be the root of the issue. Failing that, I would first create a backup copy of: '%SystemRoot% System32 exp srv.dll' to a non-system folder, and also a renamed backup copy of: '%SystemRoot% System32 dll cache exps rv.dll' in the dllcache folder.
And I would then disable WFP using the 'SFCDisable'=dword:0000000 1 method, reboot, and try to install the program again. If successful, re-enable WFP without delay. The above obviously has risks if the same package installs any of the other protected files of different versions. The SharedDLLs key in the registry keeps a counter of the number of programs that share the DLL, and this is used during uninstallation of the programs so as to prevent removal of a file still needed by another program. With WFP disabled I don't think (but I may be wrong) that the counter would be incremented while installing the Fujitsu software. I suppose you could manually change it afterwards in the registry. Anyway, regardless of what method you use I think you are going to need to tinker a bit, so perhaps (as breadtan warned) use a test machine.
Agreed with bill You can see this link on MSI having issue with WFP - see method 2 for the vendor (method 1 will not be reliable since the versioning does not even get in sync as shared by Bill) @ Just some notes on why I am more supportive for vendor to come back instead a)%systemroot% sfcfiles.dll has some CRC checks and if there are changes to it e.g. Size of file or maybe content it may trigger 'fault' by Winlogon at start. I may not be totally sure on the condition for the CRC but it also need time to verify.
If so, will we still want to do it (maybe for knowledge but not as long time solution since it can be patch again with update or installation)? B) there are registry changes manually. And if not done properly, it can be detrimental. Do we even noted that there are overriding settings such as in HKEYLOCALMACHINE Softwar e Policies Microsoft Windows NT Windows File Protection that will copy into the HKLM Winlogon, the path of Dllcache is determine by the registry setting (which stays as default but if wrongly changed you may be having couple of copies) (and maybe more.) c) Disabling and manipulating the WFP dependencies is similar to what a malware will want to do to for the older OS like WinXP/Win2K3 server below (assuming they had admin rights or injecting to services etc) to stay persistence (undercover of WFP). VISTA and above called it Windows Resource Protection.
D) We can try in VM machine with safe snapshots revert if done wrongly. But even if it solve this instance, will it meant that subsequent installation of program or patches (from vendor) will be alright since the DLL stated is quite generally used by OS and application. Maybe a re-installation of latest service pack to the platform can shed better light in the testing (just to make it is covered since vendor may have some assumption what the customer has.
) e) Purging can be done using '/PURGECACHE' in sfs.exe where it purges the file cache and scans all protected system files immediately. It is can be as easy with the rename but the side effect may render the system unstable, as also advised by Bill. Just some thoughts.
So the installation completed and the software is working OK despite the 'error' message? Part of the message was: '. You may need to update your operating system for this program to work correctly', which inferred that it was failing.
Had we known that the setup package allowed you to continue and finish installing the product, then I'm sure we would have suggested that you just allow it to continue, and would have then asked if the software ran OK. You accepted breadtan's comment because it suggested contacting the vendor. I suggested that in my comment ID 34823474. I know it was a long comment.
The suggestion 3 paragraphs after the screenshot was: 'Personally I would first check the Fujitsu support site for your version of their Financial management software and see if they have acknowledged your issue as a problem and created a patch or workaround. I suspect that the anomaly between version numbers in the same file may be the root of the issue.' I am not arguing for points here, but I think that in future you should perhaps have a more careful look through experts' comments and at least acknowledge them, or ask for clarification if any suggestions need more explanation, rather than respond with 'Yes totally confused now' and accept a comment. That is quite dismissive. Anyway, I am glad that you were able to get the installation finished and working, and that is what really matters in the end.