Explorer09

Are you sure about this? I find no information on Microsoft website saying that KB968389 depends on any other updates. Another reminder: Neither KB982666, KB970430, or KB968389 is offered by Windows Update. I checked this less than a month ago.

When I try to slipstream the WinXP x64 disc, nLite will say that it cannot integrate this KB925398 update. (WindowsMedia6-KB925398-v2-x64-ENU.exe) I found the reason. The KB925398 update is pack so strange that nLite can't understand. The update contains patches 2 files: "dxmasf.dll" and "strmdll.dll", in the SysWOW64 folder. So what I did is renaming the "dxmasf.dll" and "strmdll.dll" to "wdxmasf.dll" and "wstrmdll.dll" respectively, then replacing the files in <disc>\i386\ . I uploaded a script which creates an nLite addon for the same thing. See the attachment. (Note that my script does not copy the file "strmdll.dll" as this file has been replaced by another update, KB974112.) WinXP_2003_x64_KB925398_script.zip

Yes, I see. But my problem is that neither of these updates have been offered to me by Windows Update, and MS has clearly said that Windows XP x64 is not affected. I think you would better write a footnote about the reason why you include them. Something like this: "Although Windows XP x64 is not affected by the vulnerability described in MS10-040 and MS11-005, these two updates patch some Windows XP x64 files and provides optional extended protection." By the way, KB982666 replaces KB973917, and KB973917 replaces KB970430. So would you also remove KB970430 from the list?

There is an error. The correct statement should be: office2003-KB943452-FullFile-XXX.exe (only for NLD, FRA, DEU, ITA, PTB, ESN and SVE. Not needed for ENU or other language-versions of Office)

In the MS security bulletin, it say that Windows XP x64 does not need the MS10-040 (KB982666) update, and Also KB2478953 is unnecessary because Active Directory Application Mode (ADAM) is not part of the standard installation of Windows XP x64.

No, I don't have the Windows Server 2003 disc. Sorry. However, it's easy to tell whether the disc is affected. If the disc contains I386\ASMS01.CAB or AMD64\ASMS01.cab or something similar, but does not contain the ASMS subfolder, then the disc is affected.

I found the old posts about that, and I did some further experiments. Please read my post:

In Mimo's list of Windows XP updates, Lilla reported that when slipstreaming 3 printer updates (KB971276, KB971314 and KB961118), the XPS Printer will not be installed during .NET 3.0 setup. Now I've continued Lilla's experiment and found where the actual problem is. Here are the experiments I've done: All of these experiments use HFSlip 1.7.10 beta J v8 (hfslip_beta_Apr29_v8.zip) for slipstreaming. The systems are installed on VirtualBox. Experiment A: Use a Windows XP SP3 without anything slipstreamed. Then install the specific update X, then install .NET 3.5 SP1. When X = KB961118, (KB961118 refused to be installed without installing .NET Framework 3.0 SP2 first. So for this test I hacked the registry before installing the update.) XPS Document Writer showed up after installing .NET 3.5. (expected result) When X = KB971314, XPS Document Writer showed up after installing .NET 3.5. (expected result) When X = KB971276, XPS Document Writer showed up right after installing the hotfix, before installing .NET 3.5. Experiment B: Slipstream only the update X into Windows XP SP3, and on the slipstreamed Windows install .NET 3.5 SP1. When X = KB961118, XPS Document Writer showed up after installing .NET 3.5. (expected result) When X = KB971314, XPS Document Writer showed up after installing .NET 3.5. (expected result) When X = KB971276, XPS Document Writer didn't show up before or after installing .NET 3.5. I reinstalled KB971276 update for this case, and XPS Document Writer showed up finally. Experiment C: Use a Windows with slipstreamed KB971276 only. Then do the following commands: (as specified in the "update_SP3QFE.inf" file of KB971276) "regsvr32 /s %windir%\system32\prntvpt.dll" "regsvr32 /s %windir%\system32\spool\prtprocs\w32x86\FilterPipelinePrintProc.dll" "%windir%\system32\spool\prtprocs\w32x86\printfilterpipelinesvc.exe /RegServer %windir%\system32\spool\XPSEP\i386" (remark: Dirid %51% expand to the spool directory, i.e. "%windir%\system32\spool" Dirid %55% expand to the print processors directory, in this case, "%windir%\system32\spool\prtprocs\w32x86") I expected that XPS Document Writer shows up, but no. Only the first command succeeded. The file "FilterPipelinePrintProc.dll" and something like that existed in "system32" folder instead of "system32\spool\prtprocs\w32x86". The file "printfilterpipelinesvc.exe" too existed in "system32" folder instead of "system32\spool\prtprocs\w32x86". The folder "system32\spool\XPSEP" does not exist. Conclusion The results means that HFSLIP did not slipstream the KB971276 correctly. And the incorrectly slipstreamed KB971276 has caused .NET Framework setup to not install the XPS printer. Also KB961118 won't be installed on the system without .NET 3.0 SP2 or later. So don't slipstream KB961118 onto the disc without slipstream .NET. I will tell Mimo to note this on his list.

The update.inf inside KB2564958 seems to be incomplete. Just look at the last line in the file. There's a substitute character, which mean that some text should be cut off after this mark. I wonder if Microsoft noticed this when building that inf file?

They are not slipstreamable, AFAIK. But it's worth listing. People who install Office 2003 are likely to install this Compatibility Pack.

Sounds like you're stuck in this screen. http://img512.imageshack.us/img512/1631/presets.png (screen of selecting nLite presets) Just click "Next" if you're running nLite the first time. You don't have "previous settings" for now.

My batch script is ready and attached. By the way... I didn't check that, but I think they are updated. What's the point you are going to make anyway?

Before I test that, I want to make sure which part of the registry you are talking about. Do you want me to check this HKLM\Software\Microsoft\Windows\CurrentVersion\SideBySide\Installations\* or this HKLM\Software\Microsoft\Windows NT\CurrentVersion\Hotfix\* or both? EDIT: I tried today installing on a VirtualBox system. As I expected, only these registry entries are written. HKLM\Software\Microsoft\Windows NT\CurrentVersion\Hotfix\KB2296011 HKLM\Software\Microsoft\Windows NT\CurrentVersion\Hotfix\KB2638806 HKLM\Software\Microsoft\Windows NT\CurrentVersion\Hotfix\KB2659262 Files in WinSxS folder are same as the original disc, and this registry key HKLM\Software\Microsoft\Windows\CurrentVersion\SideBySide\Installations\* is also not updated.

Oh no, nLite did not directly integrate these updates completely. KB960803 KB2296011 KB2638806 KB2659262 Did anyone notice that?

This bug affects three updates for Windows XP Professional x64 Edition. WindowsServer2003.WindowsXP-KB2296011-x64-ENU.exe (MS10-081) WindowsServer2003.WindowsXP-KB2638806-x64-ENU.exe (MS12-006) WindowsServer2003.WindowsXP-KB2659262-x64-ENU.exe (MS12-034) All of these updates have ASMS folder within. nLite does not integrate the files inside that folder. This means the nLite'd installation of Windows will still be vulnerable, even though Windows Update would detect that the update are "installed". In short, nLite fails to directly integrate these updates completely. Steps to reproduce: 1. Run nLite. 2. Locate a Windows XP Professional x64 Edition (Service Pack 2) disc. 3. Select to integrate "Hotfixes, Add-ons, and Update Packs" 4. Insert these updates: WindowsServer2003.WindowsXP-KB2296011-x64-ENU.exe WindowsServer2003.WindowsXP-KB2638806-x64-ENU.exe WindowsServer2003.WindowsXP-KB2659262-x64-ENU.exe 5. When asking "Do you want to start the process?" Answer Yes. 6. After slipstreaming, open AMD64\ASMS01.CAB that's on the slipstreamed disc. Result: The following files should be present in the cabinet, but they are not actually. amd64_Microsoft.Windows.Common-Controls_6595b64144ccf1df_5.82.3790.4770_x-ww_D89390E2\comctl32.dll amd64_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.3790.4770_x-ww_3807D667\comctl32.dll amd64_Microsoft.Windows.GdiPlus_6595b64144ccf1df_1.0.6002.22791_x-ww_FAE9D734\GdiPlus.dll amd64_Microsoft.Windows.WinHTTP_6595b64144ccf1df_5.1.3790.4929_x-ww_32307663\winhttp.dll Manifests\amd64_Microsoft.Windows.Common-Controls_6595b64144ccf1df_5.82.3790.4770_x-ww_D89390E2.cat Manifests\amd64_Microsoft.Windows.Common-Controls_6595b64144ccf1df_5.82.3790.4770_x-ww_D89390E2.manifest Manifests\amd64_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.3790.4770_x-ww_3807D667.cat Manifests\amd64_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.3790.4770_x-ww_3807D667.manifest Manifests\amd64_Microsoft.Windows.GdiPlus_6595b64144ccf1df_1.0.6002.22791_x-ww_FAE9D734.cat Manifests\amd64_Microsoft.Windows.GdiPlus_6595b64144ccf1df_1.0.6002.22791_x-ww_FAE9D734.manifest Manifests\amd64_Microsoft.Windows.WinHTTP_6595b64144ccf1df_5.1.3790.4929_x-ww_32307663.cat Manifests\amd64_Microsoft.Windows.WinHTTP_6595b64144ccf1df_5.1.3790.4929_x-ww_32307663.manifest Manifests\wow64_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.3790.4770_x-ww_8D2E3180.cat Manifests\wow64_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.3790.4770_x-ww_8D2E3180.manifest Manifests\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_5.82.3790.4770_x-ww_A689AB02.cat Manifests\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_5.82.3790.4770_x-ww_A689AB02.manifest Manifests\x86_Microsoft.Windows.GdiPlus_6595b64144ccf1df_1.0.6002.22791_x-ww_C8DFF154.cat Manifests\x86_Microsoft.Windows.GdiPlus_6595b64144ccf1df_1.0.6002.22791_x-ww_C8DFF154.manifest Manifests\x86_Microsoft.Windows.WinHTTP_6595b64144ccf1df_5.1.3790.4929_x-ww_00269083.cat Manifests\x86_Microsoft.Windows.WinHTTP_6595b64144ccf1df_5.1.3790.4929_x-ww_00269083.manifest Policies\amd64_policy.1.0.Microsoft.Windows.GdiPlus_6595b64144ccf1df_x-ww_AE43B2CC\5.1.6002.22791.cat Policies\amd64_policy.1.0.Microsoft.Windows.GdiPlus_6595b64144ccf1df_x-ww_AE43B2CC\5.1.6002.22791.policy Policies\amd64_policy.5.1.Microsoft.Windows.WinHTTP_6595b64144ccf1df_x-ww_DD275069\5.1.3790.4929.cat Policies\amd64_policy.5.1.Microsoft.Windows.WinHTTP_6595b64144ccf1df_x-ww_DD275069\5.1.3790.4929.policy Policies\amd64_policy.5.82.Microsoft.Windows.Common-Controls_6595b64144ccf1df_x-ww_C5361FA2\5.82.3790.4770.cat Policies\amd64_policy.5.82.Microsoft.Windows.Common-Controls_6595b64144ccf1df_x-ww_C5361FA2\5.82.3790.4770.policy Policies\amd64_policy.6.0.Microsoft.Windows.Common-Controls_6595b64144ccf1df_x-ww_BD997995\6.0.3790.4770.cat Policies\amd64_policy.6.0.Microsoft.Windows.Common-Controls_6595b64144ccf1df_x-ww_BD997995\6.0.3790.4770.policy Policies\wow64_policy.6.0.Microsoft.Windows.Common-Controls_6595b64144ccf1df_x-ww_5C2DC83C\6.0.3790.4770.cat Policies\wow64_policy.6.0.Microsoft.Windows.Common-Controls_6595b64144ccf1df_x-ww_5C2DC83C\6.0.3790.4770.policy Policies\x86_policy.1.0.Microsoft.Windows.GdiPlus_6595b64144ccf1df_x-ww_4e8510ac\5.1.6002.22791.cat Policies\x86_policy.1.0.Microsoft.Windows.GdiPlus_6595b64144ccf1df_x-ww_4e8510ac\5.1.6002.22791.policy Policies\x86_policy.5.1.Microsoft.Windows.WinHTTP_6595b64144ccf1df_x-ww_7D68AE49\5.1.3790.4929.cat Policies\x86_policy.5.1.Microsoft.Windows.WinHTTP_6595b64144ccf1df_x-ww_7D68AE49\5.1.3790.4929.policy Policies\x86_policy.5.82.Microsoft.Windows.Common-Controls_6595b64144ccf1df_x-ww_65777D82\5.82.3790.4770.cat Policies\x86_policy.5.82.Microsoft.Windows.Common-Controls_6595b64144ccf1df_x-ww_65777D82\5.82.3790.4770.policy wow64_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.3790.4770_x-ww_8D2E3180\comctl32.dll x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_5.82.3790.4770_x-ww_A689AB02\comctl32.dll x86_Microsoft.Windows.GdiPlus_6595b64144ccf1df_1.0.6002.22791_x-ww_C8DFF154\GdiPlus.dll x86_Microsoft.Windows.WinHTTP_6595b64144ccf1df_5.1.3790.4929_x-ww_00269083\winhttp.dll Update 2012-05-31: I've written a batch script for this. It will create a patched ASMS01.CAB for you. See the attachment. You also need these binaries: ASMS01.cab (Must be SP2 version. You can get one from extracting the SP2 installer.) cabarc.exe (You can get this from Windows XP Support Tools, or just Google it.) WindowsServer2003.WindowsXP-KB2296011-x64-ENU.exe WindowsServer2003.WindowsXP-KB2638806-x64-ENU.exe WindowsServer2003.WindowsXP-KB2659262-x64-ENU.exe Then run "update_asms01_cab.cmd". Update 2012-11-21: Revision 2 of the script. I fixed a version number typo in one of the entries.ini file. Before: amd64_policy.1.0.Microsoft.Windows.GdiPlus_6595b64144ccf1df_5.1.3790.22791_x-ww_DFCD8D4F After: amd64_policy.1.0.Microsoft.Windows.GdiPlus_6595b64144ccf1df_5.1.6002.22791_x-ww_DFCD8D4F Update 2012-11-22: Revision 3. See the last post.

For some updates, MS doesn't even think they are "replacements" at all. I have one case, KB2695962 ActiveX Kill Bits update: although MS did say that KB2695962 contains KB2618451.

Off-topic, but I'm confused about this in Mimo's update list. The three updates seems to be deactivated for a long time. Where's the problem and how can I test it?

I thought I needed to send a .patch file or something to help update the Office 2003 list. Now it's done. Great job, Mimo!

That's strange. It worked for me. I use Cabarc 5.1.2600.0.

It isn't an error. nLite can extract cabinets compressed with LZX algorithm. I prefer LZX because it often has better compression with MSZIP. This doesn't affect the slipstreamed disc, though.

I've updated my script. No Microsoft binaries this time. But... HFSLIP misses some registry entries when integrating KB2564958.

I tested this on HFSLIP 1.7.10 beta J v8, slipstreaming updates of Windows XP Professional (x86). It seems like HFSLIP does not recognize the registry entries in the [OleAcc.Add.Reg] and the [uIACore.Add.Reg] sections in KB2564958 "update.inf" file. This makes the file UiAutomationCore.dll unregistered in the slipstreamed Windows. (AFAIK, it is fine to ignore the [OleAcc.Add.Reg] section, because the Windows setup will add the entries automatically, when registering Oleacc.dll.) To check this bug: 1. Let HFSLIP slipstream the KB2564958 update. 2. Install the HFSLIP'ed Windows XP on a computer or a virtual machine. 3. Open regedit, and find each of the following registry keys: HKCR,AppID\{60a90a2f-858d-42af-8929-82be9d99e8a1} HKCR,CLSID\{60a90a2f-858d-42af-8929-82be9d99e8a1} HKCR,CLSID\{6e29fabf-9977-42d1-8d0e-ca7e61ad87e6} HKCR,CLSID\{ff48dba4-60ef-4201-aa87-54103eef594e} HKCR,Interface\{146C3C17-F12E-4E22-8C27-F894B9B79C69} HKCR,Interface\{40CD37D4-C756-4B0C-8C6F-BDDFEEB13B50} HKCR,Interface\{4ece4541-81d4-44ac-9df6-d199ef66f904} HKCR,Interface\{C270F6B5-5C69-4290-9745-7A7F97169468} HKCR,Interface\{E81D1B4E-11C5-42F8-9754-E7036C79F054} HKCR,TypeLib\{8acc2016-04a3-4343-b8e1-1870e35d6a41} HKCR,TypeLib\{944DE083-8FB8-45CF-BCB7-C477ACB2F897} Expected result: All of these keys should exist, and contain values. Actual result: They are all missing. Despite this little bug, Windows Update can still detect the presence of the UiAutomationCore.dll, and the user won't be notified that KB2564958 did not install completely. I have a simple workaround for this. On the installed, HFSLIP'ed Windows, you can run this command to have the DLL registered correctly: regsvr32.exe uiautomationcore.dll Or, on the HFSLIP'ed disc, put this line in the [HFSLIPREG] section of "I386\HFSLIPWU.INF": HKLM,"SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce",KB2564958,,"regsvr32.exe /s uiautomationcore.dll"

In the current version of nLite, it will complain that it cannot directly integrate the updates KB2564958 and KB2661637, and will try to use the regular integration methods. However, I have a way to directly integrate both of them. The reason nLite will not directly integrate these updates is because they have files not present on the Windows XP CD. But nLite can accept these if I convert them into add-ons. So I made two add-ons for these updates. They work with the English version of Windows XP (x86). Update: I've removed the Microsoft binaries. And the script will work with updates of any language. The only binaries needed are: Cabarc.exe, WindowsXP-KB2564958-x86-XXX.exe, and WindowsXP-KB2661637-x86-XXX.exe Second update (2013-10-06): Attachment WindowsXP-KB2661637-x86.zip removed. Please use the updated version attached in the last post. WindowsXP-KB2564958-x86.zip

Yes, I get it. Time to blame Microsoft. (Tested today on a freshly-installed Win XP x64 on VirtualBox)

Okay, may you guys help me try this thing? Keep the KB2638806's "Installed" registry entry and remove the KB960803 one. Then check Windows Update and see if it still offers KB960803. I think the answer would be no, but I don't have the time and hardware to try that out.