KB994653 Doesn't work with /INTEGRATE

[DarkShadows]

If you have your own script that integrates Updates into your Windows XP source, you might be getting short changed by this update.

KB944653 -> Vulnerability in Macrovision driver could allow local elevation of privilege

Download -› 493 KB (December 10, 2007)

Switches: KB944653.exe /q /n /z

I use my own homegrown script to integrate updates using the /INTEGRATE parameter. My script checks svcpack.inf in the XPCD\i386 folder to verify if an KBnnnnnn.exe entry was added for each integrated Windows update. Nearly all current updates will have such an entry, but a few leave behind different file name entries, not named after the knowledgebase number. My Integrate.cmd script flags all missing KBnnnnnn.exe entries as warnings. I always go and inspect svcpack.inf, to see what the unverified update actually added to the XPCD.

Tonight I was working on adding December's updates, and I kept getting a warning for KB944653. So I eventually trimmed my update list down to only that update and watched my script work. When my script launched it, the update: ran, unpacked itself, and went about it's business integrating. Finally the dialog closed without any errors—to all appearances, it looked like the /INTEGRATE switch worked as expected. However, when my Integrate.cmd script ended and still reported a warning that there was no svcpack.inf entry for KB944653. So I inspect the svcpack.inf file and... nothing, it's empty! Now mind you I am integrating about 90 updates and all of the others work flawlessly, all except KB944653. So something has to be different here with this update.

So I manually extracted KB944653 and look at it's only file.

Filename	 Version	Modified Date  MD5
secdrv.sys   4.3.86.0   2007-11-13	 90a3935d05b494a5a39d37e71f09a677

I also find the file on my Windows XP Pro CD -ROM (no Service Pack).

Filename	 Version	Modified Date  MD5
secdrv.sys			  2004-07-17	 d26e26ea516450af9d072635c60387f4

Notice that there is no file version on the original file on the CD-ROM. Could that make a difference I wondered? So I Googled around and found Error 0x715 slipstreaming KB944653 on Ross's Blog. This fine fellow had a very similar experience to mine, and fortunately he documented it. As it turns out, the Windows Update coughs out because the version on the existing file could not be verified.

Well okay, that sucks. So then I wondered: How do we reliably Integrate this update? The answer turned out to be simple, delete the original file from your XPCD source (or just rename it). Then the update will integrate correctly.

But just think of the logic here. A file with missing module version information will hang this update, but a missing file (and thus with missing module version information) will not.

The wow definitely starts now!

[Neo - Matrix]

Thanks I was looking for this help

Btw, can you please post your Integrate Script that checks the integration !? - Hope isn't english only. I'm looking to known why some of my updates don't integrate and end up with an error :@ and to check what update went OK.

[DarkShadows]

Glad to hear my article helped someone!

Unfortunately, my Integrate script is English only. I'm not really comfortable sharing it. One, it would create a number of support requests that I don't have time for. Two, I'm using a number of tools that I have installed on my PC and the script calls them from the command line. Three, I wrote it for my own purposes and it is still very much a work-in-progress. It suits my purposes but it is not as polished as XPCREATE, HFSLIP, or nLite.

Edited January 11, 2008 by DarkShadows

[Ascii2]

How do we reliably Integrate this update? The answer turned out to be simple, delete the original file from your XPCD source (or just rename it). Then the update will integrate correctly.

It really is not so simple. The original file from the installation source should be deleted before starting the integration process. Otherwise, if deleting the file during the many patch integration process, there is a risk of not retaining versions of the secdrv.sys file newer than what is included in the defective patch.

[Ascii2]

Rethinking about the problem after examing what the update is for, I have decided that the better solution is to remove the secdrv.sys driver/service (the service is hidden by default) from Windows XP with Service Pack 2.

secdrv.sys is a third-party DRM driver, generally used to restrict use of games. DRM drivers for games has been reported to cause system instability. The commercial name of the secdrv.sys is "SafeDisc".

It may be unwise to install the update patch and update the DRM (to SafeDisc V4.3.86); it would be best to completely remove SafeDisc from the system.

More on SafeDisc:

http://en.wikipedia.org/wiki/SafeDisc

Edited September 22, 2009 by Ascii2