Trouble with Service Pack 1

So at last it was time to install Service Pack 1 on the Windows 7 PC.  That's when more trouble started.

SP1 was released in February 2011, yet it was now January 2013 - why the delay?  Reasons were:

•  SP1 initially had issues - let others prove its stability first
•  the target system is critical to the users
•  the target system had hardware issues: backup drive, memory
•  no pressing drivers exist until support for Win7 RTM ceases in April 2013
•  techie time is scarce.

Following Microsoft's recommendations to prepare before installing SP1, the SP1 box was ticked in Windows Update 'important updates' and off we went.

After about ten minutes, this fateful error message appeared:

Installation was not successful
Error E_FAIL (0x80070002)

It's at times like this you realise how useful the world-wide-web is.

Trawling around, it seems there are loads of people out there who are unable to install Windows 7 SP1.  A number of standard fixes exist, some of which may work in some cases, but not in others.  Despite advice freely offered by practitioners world-wide, many have spent many frustrating days or weeks trying to resolve problems, only to resort to a Windows Repair or even a clean install in order to get SP1 to 'take'.  As this PC's previous instability had already been impacting users for some time, it was more important - for now - to keep it running than to install SP1.

Undaunted, investigation started.  First step was to download and run the latest version of Microsoft's System Update Readiness Tool (CheckSUR.exe KB947821).  This tool will flag a range of issues that may prevent a successful update, but it is not infallible.

So when it completes, always inspect the log file (%SYSTEMROOT%\Logs\CBS\CheckSUR.log) which in this case revealed "CSI Payload File missing" - two font files that had previously been identified by sfc as corrupt.

These missing files were duly located on another 32-bit machine and copied into the appropriate folders \Windows\winsxs\x86_microsoft-windows-font-truetype-<fontname_key_version_checksum>.  There is also a way of extracting them from a Windows install disk.  Once copied, permissions must be checked and set to the same as the other files in the winsxs folder.

So time for a second try.  This time it ran for a bit longer, but then stopped with another error (right).

Error 0x80004005 is rather generic - it could mean many things.  So it was time to trawl the log files: %systemroot%\logs\CBS\CBS.log - this can be a very large file, so several previous versions get archived into CbsPersist cab files.  I use Notepad to view logs because Word takes ages to open and manipulate it.  Even then it takes some time to open.  There are several third-party editors (e.g. notepad++) out there which may prove easier to use.

It's worth noting here that CBS.log contains error messages even when things run OK.  So the key thing to look for is 'Error' in the 3rd column after the timestamp so as to be sure 'genuine' errors are located.

In this case, the first such error was:

2013-02-14 15:44:26, Error                 CBS    Failed. Attempted to uninstall a version of a non-driver component that is not installed, version: 0X600011db04001, component: x86_usbport.inf_31bf3856ad364e35_6.1.7600.16385_none_bd98b59664e136c7, owner: Microsoft-Windows-Common-Drivers-Package~31bf3856ad364e35~x86~~6.1.7600.16385.INF_usbport [HRESULT = 0x80004005 - E_FAIL]

The salient bit is in blue.  Beyond highlighting the offending component, the message isn't that helpful - where to look?

It turns out that there is another helpful log for driver-related errors:
%systemroot%\inf\setupapi.dev.log.  Interesting things like errors are flagged with !!!.  Unfortunately the related info hasn't been kept, so I can't recall exactly what it said.  However it may not matter because, after much hunting on the web, the important breakthrough came from a problem documented by simplymagic on Microsoft's Technet forums.  The key take was that a missing component relates to a registry entry - or rather, a missing one. 

Looking at a 'good' Windows 7 system that had not previously misbehaved, the relevant registry key was located and exported:

This key did not exist at all on the target system!  Some gremlin - faulty memory? - must have removed it at some point.  Odd, because a data corruption might have caused a corrupted key rather than no key; maybe the registry contains internal integrity checks.  Anyway, this key was imported and we tried again.

Whilst this lengthy exercise was proceeding - on just one day a week in between other tasks - various other updates were issued by Microsoft but they all installed without problem.  However, after the December 2012 updates, one particular housekeeping script started throwing errors, e.g. xcopy /o switch and start /wait - nothing else had changed.  Something for another day...

This time the SP1 install seemed to run for a bit longer, but stopped with the same error: 0x80004005.  Hmm, didn't that registry patch work?  So once again wade through the several MB of CBS.log - a different error!

2013-03-07 14:56:45, Info                  CBS    Exec: Unprojecting Package: Microsoft-Windows-MediaPlayer-Package~31bf3856ad364e35~x86~~6.1.7600.16385, Update: WindowsMediaPlayer, UninstallDeployment: x86_microsoft-windows-mediaplayer-deployment_31bf3856ad364e35_6.1.7600.16385_none_71ad27aea516fdf4
2013-03-07 14:56:45, Error                 CBS    Failed. Attempted to uninstall a version of a non-driver component that is not installed, version: 0X600011db04001, component: x86_microsoft-windows-mediaplayer-wmpps_31bf3856ad364e35_6.1.7600.16385_none_ae60a5fb9d50dc3e, owner: Microsoft-Windows-MediaPlayer-Package~31bf3856ad364e35~x86~~6.1.7600.16385.WindowsMediaPlayer [HRESULT = 0x80004005 - E_FAIL]

So this new SP1 install error had the same process applied to check and then patch the registry from another PC.  After that, the SP1 install ran to the end, restarted the computer (twice), and completed the installation!  Woohoo!

So then it only remained to install the 100 or so updates released since SP1.  Luckily I had been updating one or two other PCs, so had already downloaded and saved all the SP1 updates on a USB stick.  An associated script installs them all in one go, logging results so that any problems can be fixed before restarting.  To ease this process, there is now an SP1 update roll-up available from Microsoft.

Apart from the script error issues mentioned earlier, all has been well running on SP1.  If we'd had a reserve way of keeping our database running, it would have been far easier and quicker to just reload this PC from media and updates, reinstall applications and restore the data.  But so much was learned about Windows 7 that all the malarkey may just have been worthwhile.