problems when integrating hotfixes

[xvampx]

hi when i integrate SP2 into my xp everything goes fine, but when i make one with SP2 and the other hotfixes and patches, it wont go through the setup anymore...

does anybody have a list of working KB patches for the XP home version? i downloaded them all from the sticky but they seem to mess up my CD.

[neo]

Use the Windows Update Downloader and download the hotfixes for your Windows.

Download

[mormoloc]

you might want to try this and see if it works. i have used it before but installation returned errors, i do not know if the update pack was to blame.

ps: the pack is to be applied only to sp2ed distributions.

[xvampx]

Use the Windows Update Downloader and download the hotfixes for your Windows.

Download

thanks im downloading them now:)

i'll let you know if it worked

[aliceinchains]

I didn't want to start a new thread for this because I seem to be in the right topic but can anyone tell me how to /integrate Windows Malicious Software Removal Tool - August 2011 (KB890830) and

Update for Microsoft XML Core Services 4.0 Service Pack 2 (KB973688) ?

[PaulAuckNZ]

Get this, its a lot easier..Then use this to remove, what you dont want. Extract it first <- direct link

You need this for the 2nd link I posted.And Nlite to slipstream whatever (The service pack / drivers etc)

Edited August 26, 2011 by PaulAuckNZ

[Guest]

Teach a man to fish, PaulAuckNZ... aliceinchains may only want KB890830 and KB973688.

First and foremost, KB973685 supersedes KB973688.

Assuming you're using XPx86SP3 Home and using no tools like nLite or HFSLIP, the simplest method is to add the installers to SvcPack.inf by following these steps:

1. Rename your files to fit the 8.3 naming convention:
   1. "windows-kb890830-v3.22.exe" becomes "KB890830.exe".
      
   2. "msxml4-KB973685-enu.exe" becomes "KB973685.exe".
      
   3. Correctly place your KB*.exe files:
      1. Create a folder named SVCPACK inside I386 of your source.
         
      2. Copy your KB files to the I386\SVCPACK folder.

[*]Decompress existing SvcPack.inf file:

1. Locate the file "SvcPack.in_" in I386 in your source.
   
2. Using 7-Zip, WinRAR or another compressed file manager extract SvcPack.inf from SvcPack.in_ and place the INF file in I386.
   
3. Delete "SvcPack.in_" in I386.

[*]Edit I386\SvcPack.inf:

1. Open SvcPack.inf in NotePad or your favorite text editor.
   
2. Add the following lines to the bottom of the [Version] section:
   
   • MajorVersion=5
     MinorVersion=1
     BuildNumber=2600

[*]Under [setupData] change:

• CatalogSubDir="i386\hotfixes"

to

• CatalogSubDir="\i386\svcpack"

[*]Under [setupHotfixesToRun] add the following lines:

• 
  KB890830.exe /Q
  KB973685.exe /qn

[*]Save SvcPack.inf in I386.

If your source was unmodified at the start, your SvcPack.inf file should now look like this:

Signature="$Windows NT$"
MajorVersion=5
MinorVersion=1
BuildNumber=2600

[SetupData]
CatalogSubDir="\i386\svcpack"

[ProductCatalogsToInstall]

[SetupHotfixesToRun]
KB890830.exe /Q
KB973685.exe /qn

[Version]

It should be mentioned that these instructions are available in a more generalized form in MSFN's Unattended Windows guide.

Edited August 26, 2011 by 5eraph

[aliceinchains]

Teach a man to fish, PaulAuckNZ... aliceinchains may only want KB890830 and KB973688.

You hit the nail on the head ...

First and foremost, KB973685 supersedes KB973688.

I figured the KB973688 was superseded by another because of -x- update list and xable's,neither have it on their 'high priority' update list... I am more concerned with why /integrate didn't work for KB973688 as well as MRT.

(just for the knowledge) Also, how does one find out which updates supersede others ? Where exactly do I find that info out without relying on someone else's research ?

Assuming you're using XPx86SP3 Home and using no tools like nLite or HFSLIP, the simplest method is to add the installers to SvcPack.inf by following these steps:

Well, I slipstreamed SP3 so I'm using XPx86SP2 Home with SP3 slipstreamed, and I do prefer the manual method ...

1. Rename your files to fit the 8.3 naming convention:
   1. "windows-kb890830-v3.22.exe" becomes "KB890830.exe".
      
   2. "msxml4-KB973685-enu.exe" becomes "KB973685.exe".
      
   3. Correctly place your KB*.exe files:
      1. Create a folder named SVCPACK inside I386 of your source.
   
   I'll stop you here just to make sure .... There is already a folder named 'svcpack' in the I386. Do you mean to use this one ?

Copy your KB files to the I386\SVCPACK folder.

[*]Decompress existing SvcPack.inf file:

1. Locate the file "SvcPack.in_" in I386 in your source.
   
2. Using 7-Zip, WinRAR or another compressed file manager extract SvcPack.inf from SvcPack.in_ and place the INF file in I386.
   
3. Delete "SvcPack.in_" in I386.

[*]Edit I386\SvcPack.inf:

1. Open SvcPack.inf in NotePad or your favorite text editor.
   
2. Add the following lines to the bottom of the [Version] section:
   
   • MajorVersion=5
     MinorVersion=1
     BuildNumber=2600

[*]Under [setupData] change:

• CatalogSubDir="i386\hotfixes"

to

• CatalogSubDir="\i386\svcpack"

[*]Under [setupHotfixesToRun] add the following lines:

• 
  KB890830.exe /Q
  KB973685.exe /qn

[*]Save SvcPack.inf in I386.

If your source was unmodified at the start, your SvcPack.inf file should now look like this:

Signature="$Windows NT$"
MajorVersion=5
MinorVersion=1
BuildNumber=2600

[SetupData]
CatalogSubDir="\i386\svcpack"

[ProductCatalogsToInstall]

[SetupHotfixesToRun]
KB890830.exe /Q
KB973685.exe /qn

[Version]

It should be mentioned that these instructions are available in a more generalized form in MSFN's Unattended Windows guide.

An excellent guide (MSFN's Unattended Windows) and I do have it bookmarked.

Thank you for taking the time and writing this out in more detail. An excellent post !

[Guest]

I'll try to hit the most relevant parts first then finish with the tangential ones.

Well, I slipstreamed SP3 so I'm using XPx86SP2 Home with SP3 slipstreamed, and I do prefer the manual method ...

It is considered an XPx86SP3 source once SP3 is slipstreamed. So far, so good.

There is already a folder named 'svcpack' in the I386. Do you mean to use this one ?

Yes. Was it empty when you started? I ask because it is best to slipstream a service pack into an unaltered source to avoid problems during installation.

I figured the KB973688 was superseded by another because of -x- update list and xable's,neither have it on their 'high priority' update list... I am more concerned with why /integrate didn't work for KB973688 as well as MRT. (just for the knowledge) Also, how does one find out which updates supersede others ? Where exactly do I find that info out without relying on someone else's research ?

/integrate and /s don't work with KB890830 and KB973688 because they are not built like common update packages. They're basically just extractors that execute another program within: MRT.exe inside KB890830 and MSXML.msi inside KB973688 (KB973685 has the same MSI file name with newer contents).

To determine which update supersedes another the most dependable method is to extract the files within the packages and compare file versions. Most packages for XP can be extracted using the /x switch. Common packages almost always have two folders that are named for their installation branches, such as SP3GDR and SP3QFE. Within these are the files to be updated. To determine a file's version right-click the file to be examined, click Properties, then click the Version tab.

MSI-based packages are more complicated to extract. First you extract from the EXE using the /x switch. To reliably extract the files within the MSI follow the following steps:

1. Create a folder for the administrative install point (fancy name for extraction folder ). It is preferable to create this folder near the root of the drive to prevent a lot of typing in the next step. Try a folder name like "C:\MSI_Extract".
   
2. Open a command prompt in the folder with the MSI and type the following using KB973688 as an example:
   

   MSIExec.exe /A msxml.msi TARGETDIR="C:\MSI_Extract"

   
   Note that a fully qualified path must be used for TARGETDIR, including drive letter!
   

3. Examine the files in the new "C:\MSI_Extract\System" folder.

There's more involved with packages that install Side-By-Side binaries such as this. As a beginning example, this is pretty hairy as you need to examine policy files to determine which binaries will be used as default. I'll explain further if you'd like.

Thank you for taking the time and writing this out in more detail. An excellent post !

Thanks for the compliment.

[aliceinchains]

Yes. Was it empty when you started? I ask because it is best to slipstream a service pack into an unaltered source to avoid problems during installation.

I was wrong, I didn't have the folder until after I started installing updates. No worries,I understand why you said "create" now. lol

To determine which update supersedes another the most dependable method is to extract the files within the packages and compare file versions.

What exactly am I looking for, I mean to be able to tell one supersedes the other ?

Most packages for XP can be extracted using the /x switch. Common packages almost always have two folders that are named for their installation branches, such as SP3GDR and SP3QFE. Within these are the files to be updated. To determine a file's version right-click the file to be examined, click Properties, then click the Version tab.

After they are extracted, in this case, I would be checking the file version of both SP3GDR and SP3QFE,yes ?

MSI-based packages are more complicated to extract. First you extract from the EXE using the /x switch. To reliably extract the files within the MSI follow the following steps:

1. Create a folder for the administrative install point (fancy name for extraction folder ). It is preferable to create this folder near the root of the drive to prevent a lot of typing in the next step. Try a folder name like "C:\MSI_Extract".
   
2. Open a command prompt in the folder with the MSI and type the following using KB973688 as an example:
   

   MSIExec.exe /A msxml.msi TARGETDIR="C:\MSI_Extract"

   
   Note that a fully qualified path must be used for TARGETDIR, including drive letter!
   

3. Examine the files in the new "C:\MSI_Extract\System" folder.

There's more involved with packages that install Side-By-Side binaries such as this. As a beginning example, this is pretty hairy as you need to examine policy files to determine which binaries will be used as default. I'll explain further if you'd like.

OK, I extracted the msi contents out of both 'KB973688' and 'KB973685' and looked in the system folders of both. 'kb973688' had three dlls,file versions "4.10.9404.0" "4.10.9404.0" and "4.20.9876.0."

'KB973685' had two dlls, file versions "4.30.2100.0" and 4.30.2107.0."

It should be noted that when I extracted them, in both cases I got the message "this type of update is not supported - hit ok " This was new to me so I am glad you taught me how to do this.

[Guest]

What exactly am I looking for, I mean to be able to tell one supersedes the other ?

After [the standard updates] are extracted, in this case, I would be checking the file version of both SP3GDR and SP3QFE,yes ?

No. For a given update package, the files in the SP3GDR folder will be the same version as those in the SP3QFE folder. We need only check the file versions of one of these folders against those from a folder of another update package.

Let's compare two standard updates, like KB2503658 and KB2544893, as an example. First we extract both using the /x switch. Then we choose a branch to compare; usually the QFE branch is best since it should always exist in a standard update. In this example, with only one file, it should be easy to see which supersedes the other. It becomes more complicated when two updates supersede one other, or vice versa as is the case between KB2507938 and KB2121546 + KB2476687.

OK, I extracted the msi contents out of both 'KB973688' and 'KB973685' and looked in the system folders of both. 'kb973688' had three dlls,file versions "4.10.9404.0" "4.10.9404.0" and "4.20.9876.0."

'KB973685' had two dlls, file versions "4.30.2100.0" and 4.30.2107.0."

It should be noted that when I extracted them, in both cases I got the message "this type of update is not supported - hit ok " This was new to me so I am glad you taught me how to do this.

The newer update does not seem to need the extra resource file, which should explain the difference in file quantity. But you can see how the file versions differ between packages.

There is much you can do with administrative install points in MSI packages as they can be updated or otherwise modified, then repacked to install as the original package would. With these simple XML updates repacking would be pointless, so the error message is understandable. You can skip the error message in the future by adding /qn to the end of the command line like so:

MSIExec.exe /A msxml.msi TARGETDIR="C:\MSI_Extract" /qn

[aliceinchains]

No. For a given update package, the files in the SP3GDR folder will be the same version as those in the SP3QFE folder. We need only check the file versions of one of these folders against those from a folder of another update package.

Yeah, that's what I meant .. OK

Let's compare two standard updates, like KB2503658 and KB2544893, as an example. First we extract both using the /x switch. Then we choose a branch to compare; usually the QFE branch is best since it should always exist in a standard update. In this example, with only one file, it should be easy to see which supersedes the other.

What I see is KB2503658's file version is "6.0.2900.6090" and KB2544893's file version is 6.0.2900.6109 .. So obviously, the higher number supersedes (?)

It becomes more complicated when two updates supersede one other, or vice versa as is the case between KB2507938 and KB2121546 + KB2476687.

...and in this case 'KB2507938' supersedes because it has both the dlls that the others have collectively,plus the file version numbers are higher,correct ?

Edited August 29, 2011 by aliceinchains

[tomasz86]

There is more about superseding than just comparing file version numbers. For example, one update can add some registry changes which are not added by the other one. The safest method would be comparing not only file versions but also the content of update.inf.

[aliceinchains]

[*]Add the following lines to the bottom of the [Version] section:

• MajorVersion=5
  MinorVersion=1
  BuildNumber=2600

[*]Under [setupData] change:

• CatalogSubDir="i386\hotfixes"

to

• CatalogSubDir="\i386\svcpack"

[*]Under [setupHotfixesToRun] add the following lines:

• 
  KB890830.exe /Q
  KB973685.exe /qn

[*]Save SvcPack.inf in I386.

If your source was unmodified at the start, your SvcPack.inf file should now look like this:

[Version]
Signature="$Windows NT$"
MajorVersion=5
MinorVersion=1
BuildNumber=2600

[SetupData]
CatalogSubDir="\i386\svcpack"

[ProductCatalogsToInstall]

[SetupHotfixesToRun]
KB890830.exe /Q
KB973685.exe /qn

It should be mentioned that these instructions are available in a more generalized form in MSFN's Unattended Windows guide.

I just have a couple question about this:

Can I do this "inf method" after I have already "/integrated" a bunch of updates, only doing this for the updates that don't use the /integrate switch ?

Can I do the inf way and then use the integrate switch after ? Or is it all one or the other ? E.G. I have a fresh copy of XPHOMESP3 (source) and I "/integrate" a bunch of updates until I come to those that won't and THEN I add those to the inf, such as explained here.

Also, in this MSFN's Unattended Windows guide, do I need to do the "DOSNET.inf" part of it ? ...Also the "adding" QCHAIN.exe part of it ?

Plus, You said add these like this:

KB890830.exe /Q

KB973685.exe /qn

My question is how do I know what /Q or /qn to add with the rest of the updates ?

The guide says : KB824146.exe /Q /O /N /Z but I'm not familiar with this stuff. I read some about what they mean but I don't really know how to apply them and why.

[Guest]

There is more about superseding than just comparing file version numbers. For example, one update can add some registry changes which are not added by the other one. The safest method would be comparing not only file versions but also the content of update.inf.

That is true, but not too common with XP packages. In XP packages the file sections to check are [Product.Del.Reg] and [Product.Add.Reg] in file "update_SP3QFE.inf". And all lines containing "%SP_SHORT_TITLE%" or "LogLevel" can be ignored.

What I see is KB2503658's file version is "6.0.2900.6090" and KB2544893's file version is 6.0.2900.6109 .. So obviously, the higher number supersedes (?)

...and in [the second] case 'KB2507938' supersedes because it has both the dlls that the others have collectively,plus the file version numbers are higher,correct ?

Correct on both counts.

Can I do this "inf method" after I have already "/integrated" a bunch of updates, only doing this for the updates that don't use the /integrate switch ?

Can I do the inf way and then use the integrate switch after ? Or is it all one or the other ? E.G. I have a fresh copy of XPHOMESP3 (source) and I "/integrate" a bunch of updates until I come to those that won't and THEN I add those to the inf, such as explained here.

Yes, you can /integrate in addition to adding packages manually. Just be sure you continue using the same SvcPack.inf throughout so all your packages are listed under [setupHotfixesToRun], not just the ones you added manually.

The order in which you add packages (either /integrate or manually) shouldn't matter. But it is good practice to keep the packages in numerical order since it's close to the order in which the packages were likely released by Microsoft. So you can /integrate all supported packages first then add the rest manually if you wish; putting the unsupported packages in proper order with the rest.

Also, in this MSFN's Unattended Windows guide, do I need to do the "DOSNET.inf" part of it ? ...Also the "adding" QCHAIN.exe part of it ?

I would recommend the "DOSNET.inf" part. I am not certain if /integrate does this automatically. You can open DOSNET.inf after you /integrate some packages and CTRL+F to see if the required entries exist. Add them if they do not.

QChain.exe has not been necessary since SP2. You do not need it. The update packages themselves now include this functionality.

The guide says : KB824146.exe /Q /O /N /Z but I'm not familiar with this stuff. I read some about what they mean but I don't really know how to apply them and why.

You don't need to add these switches to packages that are added by /integrate. It is done automatically.

[...] how do I know what /Q or /qn to add with the rest of the updates ?

You need to examine the unsupported packages to see what switches are needed to install silently. This can usually be done at a command prompt by using the /? switch. For MSI-based packages, /qn usually works.