Replace protected system files?
What is the proper way to replace or update a protected system file? I have received a vendor package that is replacing one protected system file msvcp50.dll. This of course causes windows to complain. I've contacted the vendor about this and it is my assumption that they have authored their package wrong in the method they are using to update a protected system file. Web searches for replacing protected files results in too many hacking pages. I want to find out what the MS supported method is for replacing a protected system file is. If the vendor's package is incorrect I want to be able to let them know that it is a problem with their software and not our workstations. My guess would be that they would need to have this dll certified with MS and have it signed in order to replace it correct? Anyone know?
0 Comments
[ + ] Show comments
Answers (9)
Please log in to answer
Posted by:
aogilmor
16 years ago
This bit from msi.chm might help. Make sure the wfp protected file is a component keypath.
Note that if a Windows Installer component contains a WFPfile, this file must be specified as the key path for the component.
When the installer attempts to install a component's keyfile on Windows 2000, it first calls Windows File Protection to determine if the key file is protected. When the key file of a component is protected by WFP, and that key file is already installed, the installer updates the component only if the version of the key file in the package is greater than the installed version. If the installation package specifies that a component be installed, and the key file of the component is not currently installed, then regardless of whether the key file is protected the installer installs the component. Once any component having a key file protected by WFP is installed, it is permanently installed, and the installer never removes or replaces the component.
Note that if a Windows Installer component contains a WFP
When the installer attempts to install a component's key
Posted by:
India_Repackaging
16 years ago
Hello All,
Owen are you suggesting that the component holding a WFP file should be made keypath and how about marking the component as 'Transitive' as well. Just an thought, please let me know if am wrong.
Cheers[8|]
Owen are you suggesting that the component holding a WFP file should be made keypath and how about marking the component as 'Transitive' as well. Just an thought, please let me know if am wrong.
Cheers[8|]
Posted by:
Inabus
16 years ago
The problem, I suspect, is that the vendor hasn't conditionalised the component to NOT install the system file under Windows XP. I would think that this file has been left so that the application works under Windows 2000 systems and earlier. The route to take would be to just conditionalise the component using "VersionNT <= 500", then the file wont attempt to install under a Windows XP system, thus avoiding your problem.
P
P
Posted by:
anonymous_9363
16 years ago
The route to take would be to just conditionalise the component using "VersionNT < 500", then the file wont attempt to install under a Windows XP system, thus avoiding your problem...except, of course, the OP *wants* the file replaced, not to avoid its replacement! :)
Posted by:
Inabus
16 years ago
WFP is there for a reason, updating a core system file like this is just plain silly when Microsoft could potentially patch it with a security update down the line.
You then have the version question, what version of the file is currently installed and "protected" and what version of the file doesn this vendor MSI want to install?
I would like to point you too the following article:
http://support.microsoft.com/kb/898628
And I quote "WFP prevents applications from overwriting system files. Windows Installer cannot overwrite WFP-protected files."
P
You then have the version question, what version of the file is currently installed and "protected" and what version of the file doesn this vendor MSI want to install?
I would like to point you too the following article:
http://support.microsoft.com/kb/898628
And I quote "WFP prevents applications from overwriting system files. Windows Installer cannot overwrite WFP-protected files."
P
Posted by:
anonymous_9363
16 years ago
Well, that was kind of my point. Your last response answers the original question. A more complete answer would have advised that WFP files can't be replaced and that if the vendor MSI is trying to do that, the relevant component needs to have a condition added to not install it for systems with W2K and above.
Posted by:
Inabus
16 years ago
My answer was to fix the problem the vendor has produced however you have rightly pointed out I didnt give the reason for my answer, so in future ill try to avoid ambiguity.
P
P
Posted by:
joedown
16 years ago
I should have mentioned that this vendor patch is not an MSI but rather a legacy install shield setup.exe. The original mscvp50.dll has a date of 8/23/2001 and the new one has a date of 5/13/2007. So it looks like I should tell the vendor that they need to fix their package so that it does not try and replace this file because it could be overwritten by MS with an update? I would like to be able to tell the vendor why/how they should fix it rather than just say it's broken and have them blame my environment.
I've noticed that when it comes to software support problems where you can tell the vendor exactly what the problem is and suggestions on how it can be fixed gets better results than just having them open a trouble ticket for a problem one person is having.
I've noticed that when it comes to software support problems where you can tell the vendor exactly what the problem is and suggestions on how it can be fixed gets better results than just having them open a trouble ticket for a problem one person is having.
Posted by:
Inabus
16 years ago
Just snapshot it as its a legacy setup.exe and not an MSI.
If I was to ask the vendor to fix it I would say conditionalise the component the file is comming from so it wont deploy to an XP and upwards system.
P
If I was to ask the vendor to fix it I would say conditionalise the component the file is comming from so it wont deploy to an XP and upwards system.
P
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.