Tomcat76

Because DOS (to my knowledge) doesn't have a built-in command to query the file version. I may come up with a test release one of these days to accomodate for the new IE7 installer but I prefer not to include the "hacks" into the next final.

Haha... I was looking inside wuredir.xml instead... Thanks for the tip

I already see a few problems quickly looking over your lists... WARNING - Previously Patched Source DetectedHFSLIP wasn't designed to work with an unclean source. It must be the original CD source. MDAC253-KB927779-x86-ENU.exe MDAC281-KB927779-x86-ENU.exeYou are slipstreaming MDAC 2.8 SP1 so you should remove the update for MDAC 2.5 SP3. Can you please fix these problems first?

Does Unattended go by what's in LAYOUT.INF? If so, that's the problem. If LAYOUT.INF is edited, Windows setup will throw up on you so HFSLIP doesn't change that file. The HFSLPGUI.CMD and HFSLPGUI.INF errors are strange. I could understand if it were only HFSLPGUI.INF because HFSLIP 1.6.3 is deleting the temporary %SYSTEMROOT%\HFSLIP folder at first GUI logon now, for which HFSLPGUI.INF is used. HFSLIP 1.6.2 and previous versions removed the temporary folder at T-13 but this was changed because for some people it happened too early. I think that you had files in the HFGUIRUNONCE folder when running HFSLIP 1.6.3. At least, that's the only way I can explain the HFSLPGUI.CMD error, apart from using HFSLIP's default handling of IE7.

I advise against using the new IE7 package with HFSLIP until the next cumulative update is released. Previous package: 7.0.5730.11 New package: 7.0.5730.13 Cumulative update: 7.0.6000.20641 The problem is that the time stamp of the files in the new IE7 package is newer than the one of the files in the cumulative update, yet the cumulative update contains the newest file versions. HFSLIP can only go by the file date, so it will slipstream the files from the new IE7 installer instead of those from the cumulative update. The same problem is there with the vgx.dll update (KB938127). I can always change HFSLIP so it overwrites vgx.dll by force, but I think it's crazy to do the same for the 88 files with the wrong time stamp in the new IE7 package.

Hi bynkook Is Windows/Microsoft Update also complaining about KB917344? Do you see any error messages in the HFSLIP box when that hotfix is processed? Have you tried to delete it and to download it again? As far as KB933360 goes... It is not supported because the characters are not correctly processed. I made a time zone "plugin" for HFSLIP which is supposed to work around the character problem but Korean is not supported yet. Can you help me with that? It's very simple: 1) Install WindowsXP-KB933360-x86-KOR.exe 2) Export "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones" (complete) to a .reg file 3) ZIP the .reg file and attach it to your next post I can then add support for Korean.

Heh... It took me half an hour to figure out what you meant. I was thinking of "main thread" and just couldn't find it...

XPSP2 only.

Which version of cdimage.exe are you using? I have version 2.47 and never experienced that problem. If the version is OK, I can only think of an anti-virus or script blocker program interfering, or hard disk errors.

The first two screens should be due to not including MUAuth.cab in HFCABS. The third screen is caused by what badrad600 said. I figured this out today as well when investigating this. Basically, out of the Windows Update Agent 3.0 files HFSLIP slipstreams, Microsoft/Windows Update wants to update all except wuauserv.dll and wusetup.exe to even newer versions. The separate CAB files (cdm.cab, wuapi.cab, etc.) obtainable from the "usual" location still contain the Windows Update 3.0 file versions and I've found no record of where MU/WU are getting the new ones from. This is beyond our control....

Don't bother; it was the LegitCheckControl.dll registry key. Or better: HFSLIP 1.6.0 and newer adding it into the registry from a registry hive during the first Windows setup stage. Version 1.6.3 fixes this problem by adding it into the registry at T-13 as in version 1.5.0 and earlier.

HFSLIP can slipstream spru040c.dll properly. If you are using nLite to integrate hotfixes then I'm not sure why you're using HFSLIP. Either way, you should post that finding in the nLite forum (if no one has done so yet).

That's a non-public hotfix for IE6 which updates the way plug-ins are loaded ("Click here to activate this control") and maybe other things. Just remove it and slipstream the latest cumulative update, which supersedes it.

authroots.sst was updated. jimmsta... I think you switched the images...

HFSLIP.LOG is more for us, to see that you are using only supported hotfixes and that everything is in the intented location.

I don't know of a hotfix with "IE6" and "KB937143" in its name for XP SP2... That's certainly not HFSLIP's doing. Can you please put the original hotfix in the HF folder?I've had no issues with xpsp3res.dll. In fact, I just installed XP SP2 French and everything installed flawlessly (except for the Component Publisher update because I don't know where I can download it from). Can you rerun HFSLIP with WindowsXP-KB937143-x86-FRA.exe in the HF folder, create ISO and install -- without using nLite? If the problem persists when not using nLite, please post the HFSLIP.LOG file from that rerun.

@NtegrA If you're referring to the two instances of HFSLIP.CMD... that's intentional. It's the cleanest way to satisfy several requests (order of installation, .NET before MSI installers, etc.). I've observed the same permissions problem recently. It may have to do with the key that HFSLIP is adding for LegitCheckControl.dll on Windows XP SP2 but I need to test that. Thanks for posting this.

TommyP hasn't reviewed them yet...

He was quoting you... That's what I went by...

As far as your first problem is concerned... it was already covered a few times here. The "browseui.dll" file wasn't updated in the IE7 hotfixes, but it was in the IE6 hotfixes. The problem is that the XML file from Microsoft that HFNETCHK is using does not yet contain support for detecting IE7, so HFNETCHK thinks that you are using IE6. You can extract browseui.dll from the IE6 cumulative, compress it to browseui.dl_ and place it in the FIX folder, but you'll have to repeat that whenever a new IE6 cumulative is released. The Microsoft Windows Component Publisher is a new update. The download location wasn't recorded in WindowsUpdate.log so I can't say more on it for now.

The current RC for HFSLIP 1.6.3 aborts slipstreaming of DX9 if one of the cabs is corrupt; it does that by checking for the existence of KS.SYS after extraction. For Win2K, if there is a *DX9* hotfix present in the HF folder, HFSLIP will even abort completely because at that point the hotfix is already processed, which can't be undone (at least not easily).

The point is that MS removed it and now put it back, probably after being notified that WSH 5.7 is corrupt.

I can confirm the hash.

johndoe74-- I tried that direct link... Same problem. I've tested this with both 7-zip and WinRAR. Each program gives an error, even when just extracting the main exe.

Well... I can confirm this. With Opera 9.21 in early August -- broken With Minefield 3.0 (2007090604) today -- broken With IE6 today -- broken The June 2007 d3dx10, d3dx9 and XACT cabs inside the August redist are also broken. The redist from June is OK. I will remove the link to the August redist from my site.