In response to a previous post where I mentioned that work was being done on Visual Studio 2005 SP1, reader ringi commented,
“I would match rather has SP1 as a complete 4GB install, including having to uninstall Visual Studio 2005 then have it delayed just to save a little bit of bandwidth.”
Unfortunately, it’s not just a question of bandwidth – even though that is a concern. Bandwidth costs money for our customers, too.
Digital signatures help ensure that a patch has not tampered with, but an additional level of security called Software Restriction Policies is used when Windows Installer calls the SaferIdentifyLevel
function, which in turn calls the WinVerifyTrust
function. Passing the SAFER_CRITERIA_IMAGEHASH
causes the entire patch to be loaded into memory on Windows XP and 2003. The result can be seen from the following log fragment.
MSI (s) (BA:AD) [12:00:00:000]: SOFTWARE RESTRICTION POLICY: Verifying object –> ‘D:WINDOWSInstaller50baad.msp’ against software restriction policy
MSI (s) (BA:AD) [12:00:00:000]: SOFTWARE RESTRICTION POLICY: D:WINDOWSInstaller50baad.msp has a digital signature
MSI (s) (BA:AD) [12:00:00:000]: SOFTWARE RESTRICTION POLICY: SaferIdentifyLevel reported failure. Assuming untrusted. . . (GetLastError returned 5)
MSI (s) (BA:AD) [12:00:00:000]: The installation of D:WINDOWSInstaller50baad.msp is not permitted due to an error in software restriction policy processing. The object cannot be trusted.
This happens during the server installation where the fallback is to assume – since an error occured – the file cannot be trusted. SAFER is looking for as much contiguous memory as the patch file is big. The user would see Windows Installer error 1718, which reads, “Error 1718.File D:WINDOWSInstaller50baad.msp was rejected by digital signature policy.”
Why is the patch file so big? Consider what’s in a patch. Patch files ship the source media for all files being added or updated, plus transforms for each target product. Visual Studio is a large product with many files, so patches that touch a significant portion of those files – like service packs – will be large as well. We are working toward being able to use binary delta compression but have other dependent problems to solve first.
A workaround does exist and we’re exploring additional options. Since our patches write to privileged locations, they require administrative privileges. Local administrators can use the following steps on Windows XP and newer if you are prompted with error message 1718.
- Click Start -> Control Panel
- Open Administrative Tools
- Open Local Security Settings
- Click Software Restriction Policies
- If no software restrictions are defined, right click the Software Restriction Policies node and select New Software Restriction Policy
- Double click Enforcement
- Select “All users except local administrators”
- Click OK
- Reboot the machine
After installing a large patch that may have raised this issue, it is advised that you follow the instructions above to select “All users” in step 6 above.
0 comments