snoopy81

No, don't work ! I supose it's language related. French WinXP SP3 don't work. I'm looking after the right way to add the patched file (with 3rd party patcher) in the ISO. Anyways, just replacing the file in the ISO-> File is missing a 1st installation stage.

Simple solution: Replace IE7 version of iernonce.dll (v7.0.2900.20661) with IE6 version (v6.0.2900.2180), but change the version info in this file. Tools: PEID and few plugins (FixCRC & XNressource editor) or similar tools... -> take the last IE6 version of iernonce.dll, and edit version ressource: change all version info to 7.9.2900.2180 -> Use FixCRC plugin to fix... the CRC ! -> Makecab this file -> replace IE7 iernonce.dl_ on the ISO with this one.

Finally, all is working OK now. I investigated and removed all IE6 cumulatives updates, keeping the KB937143. Now the bug: This KB has a little issue: - the file "spru040c.dll" is not already installed by previous KBs - so nLite reverts to standard integration, queeping KB937143.EXE, and the unpacked files in i386. - this way, the file xpsp3res.dll is not properlly installed - so previous xpsp3res.dll stays, then WU want to apply the KB after the installation. My fix: - I put the file SPRU040C.DL_ in 1386 folder before using nLite. - nLite integrates the good way this Hotfix. - after nLite, I put the last xpsp3res.dl_ in i386 and voilà !

With nLite v1.4beta, there is 2 integration methods: A nice one - Direct HotFix integration - - The files are replaced in i386 folder by the new version (packed) - Registry keys are also replaced - CAT files are kept for sfc in needed (option to remove) A rubish one - Regular method - - The hofix is named KB909090.EXE, kept for later run (T-13 ?) - Files are extracted (by HotFix ?) in the i386 folder, but stay there unpacked. - This regular method seems mendatory when hotfix contains a new file (not already present in i386) ie: KB947143 contains spru040c.dll, absent if previous cumulative IE6 update was not added before. The nasty result, is that on you CD, those hotfixes use alot MB ! The idea would be to sort hotfixes (Direct HotFix integration->Advanced-> Check "Display reports" then you'll see what hotfix causes problem, and with what file. -> 1st solution would be to put a single missing file in the i386 folder, to cause nLite to revert to Direct HotFix integration. -> 2nd solution, don't integrate, but fix later...

Currently building XP SP2 CD, I experimented a similar issue. IE6_KB937143_Fra was apparently splipstreamed in CD, but WUpd wanted to install this fix again. NB: Unlike most HotFixes, the WindowsXP-KB937143-x86-FRA.exe is renamed KB937143.exe in the I386\SVCPACK\ alogside the cat file. danim.dll v6.3.1.148 is same before and after reinstallation of KB937143... After some more investigation: (nLite 1.4beta) ISO N°1: Tested on Virtual PC, in \system32\: - xpsp3res.dll version is lower than expected with KB937143 (VirtualPC: v5.1.2600.3100, ISO: v5.1.2600.3059, expected: v5.1.2600.3157) I've no idea of the source of later v5.1.2600.3100... - iedw.exe is missing, but it's there in the ISO. - KB937143.CA_ only on the ISO, no EXE ! - Windows update ask for reinstallation of KB937143 - KB928090 (cumulative IE6 feb07) is in the ISO ( I now guess it's useless !) - KB933566 (cumulative IE6 jun07) is absent ( after checking onMS knoledge base, the fix include the same files ) - then I replaced xpsp3res.dll with last version; removed WU, rebooted, activated WU again, then... no more prompt for KB937143 Installed on my PC, then I performed the Automatic update for KB937143 - iedw.exe still missing - xpsp3res.dll version is as expected with KB937143 ISO N°2 (not tested), checked hotfixes dates<->order - I added KB933566 (cumulative IE6 jun07) - After nLite, there was a KB937143.EXE in i386\SVCPACK\ ! - I removed older Timezone fixes, and a few KB that stayed as KBxxxxxx.EXE in i386\SVCPACK\ (flash fixes, msagent) - discarted due to other reason... ISO N°3 (not tested, will discard), checked hotfixes dates<->order - After nLite, there was a KB937143.EXE in i386\SVCPACK\ ! - All files from the KB937143 in the i386 are not makecab_ed... and from KB - xpsp3res.dll is the only makecab_ed file from KB937143 So, I'll try again, without previous IE6 cumulative updates, and I'll try to inject xpsp3res.dll somewhere at the install's end.

After long time trying and understanding many aspects of improvement of WindowsXP installation CD, I obtainned a nice and clean installation CD using nLite 1.3rc2 over WindowsXP pro. But to use this Windows XP on my notebook, I needa home version, according to my Win licence. So, I used the same procedure to XP Home, and... nLite absolutelly want me to add a new user, telling (rough translation of French nLite) "WindowsXP home can't create an administrator account". Of course, after 2nd reboot, the Window's intro asks me to say who will use this computer, resulting an installation with 2 users. After some investigation, ( non nLited XPhome never do that ! ), I figured out the problem: This "new user" is created by nlite.inf file: [TO] HKLM,"SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce","nlite_post_00",0x00000000,"nhelper net1 user """"Nouvel Utilisateur"""" /add" HKLM,"SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce","nlite_post_01",0x00000000,"nhelper net1 localgroup """"Administrateurs"""" """"Nouvel Utilisateur"""" /add" ... ... HKU,".DEFAULT\Software\Microsoft\Windows\CurrentVersion\RunOnce","nltide_3",0x00020000,"rundll32 advpack.dll,LaunchINFSectionEx nLite.inf,C,,4,N" But removing those lines endsup with a partially customised installation. (Either nLite cutomisation, or personal one using cmdlines.txt)... maybe it has something to do with later line ? Any way to fix this annoying issue ?