koitsu

I'd like to bring to everyone's attention the termination of the Autopatcher utility, as a result of Microsoft's cease-and-desist-development request: http://autopatcher.com/ I have a lot of concern over this, not because I used Autopatcher (I didn't), but because it makes me wonder what Microsoft is up to. I cease to understand their motive for the termination of that project, and fear that nLite might be next. I hope not, or else we're in a lot of trouble (as SAs and tech-savvy users)...

The past 2 pages of discussion in this thread are completely off-topic. Please focus on the issue at hand, folks...

What "patch" are we talking about? Why is there a patch (re: DLL modification) needed to integrate drivers into XP? Are you saying the workaround is to enable SFC under the Patching section of nLite, or am I misunderstanding something (highly likely)?

Hmm, nope, the only differences between nLite and AutoStreamer for slipstreaming are that nLite chooses to leave boot.bin and boot.catalog on the CD. (Sorry, I had to change my method of output in the .txt files between my last post and now; it seems DIR /O:N /S does not recursively sort directories alphabetically, as one would think. I had to use DIR /S /B /L | SORT...): D:\>diff -ruN sp2_nlite.txt sp2_autostreamer.txt --- sp2_nlite.txt Mon Jun 13 10:03:02 2005 +++ sp2_autostreamer.txt Mon Jun 13 10:03:18 2005 @@ -1,6 +1,4 @@ f:\autorun.inf -f:\boot.bin -f:\boot.catalog f:\cmpnents f:\cmpnents\netfx f:\cmpnents\netfx\i386 So, the problem we're experiencing with WFP isn't related to the Slipstreaming process in nLite.

I've begun to try and research this problem. I'll post to this thread with my findings, which for everyone's information, could be red herrings. nuhi will have to figure out what's really going on. (For those not familiar with this term in English, "red herring" means something that distracts or takes away focus from the real problem; people also use it to mean "false alarm"). The first thing I did was use nLite 1.0b2 to make an ISO of XP + slipstreamed SP2. Then I made another ISO of XP + slipstreamed SP2 + custom driver installation (but DID NOT add any drivers!). I then mounted each ISO, and took a directory listing using DIR /O:N /B /S, and saved the output to a file. Finally, I ran diff -ruN against each directory listing. Here's the results: 06/13/2005 09:10 161,950 sp2+emptydrivers.txt 06/13/2005 09:10 161,927 sp2.txt D:\>diff -ruN sp2.txt sp2+emptydrivers.txt --- sp2.txt Mon Jun 13 09:10:36 2005 +++ sp2+emptydrivers.txt Mon Jun 13 09:10:56 2005 @@ -4732,6 +4732,7 @@ F:\I386\SYSRESTW.CH_ F:\I386\SYSSETUP.DL_ F:\I386\SYSSETUP.IN_ +F:\I386\SYSSETUPO.DL_ F:\I386\SYSTEM.AD_ F:\I386\SYSTEM.CH_ F:\I386\SYSTEM.DR_ What this means is that nLite, when you choose "Integrate Drivers", adds a file to your XP installation called SYSSETUPO.DLL. Again: remember, I did not add ANY DRIVERS. I just chose the "Integrate Drivers" option. :-) I then looked on the host system (which was installed using nLite 1.0b1), and found the following: 06/05/2005 11:09 984,576 syssetup.dll 08/04/2004 00:56 984,576 syssetupo.dll Now, despite these DLLs being the same size, they are *NOT* the same: D:\>fc /b C:\windows\system32\syssetup.dll C:\windows\system32\syssetupo.dll Comparing files C:\WINDOWS\SYSTEM32\syssetup.dll and C:\WINDOWS\SYSTEM32\SYSSETUPO.DLL 00000148: C5 1A 00000149: F7 92 00033694: 33 56 00033695: C0 56 00033696: EB 56 00033697: 29 56 0003393D: 33 8B 0003393E: C0 FF 0003393F: C2 55 00033940: 04 8B 00033941: 00 EC Is this DLL the problem? What I'm trying to figure out is if nLite is breaking Windows (re: WFP notifications) due to a) the driver integration part of nLite, or B) the slipstreaming process. I'm going to try using AutoStreamer to slipstream SP2, and compare nLite's XP+SP2 slipstream ISO to AutoStreamer's XP+SP2 slipstream ISO.

And if we didn't? There are those of us who use nLite to do NOTHING MORE than slipstream SP2 + add third-party drivers (Dell 2405FPW monitor profile, 3Com 3C940 NIC, and HP printer INFs). We do not apply or adjust ANY OTHER SETTINGS in nLite... yet we get WFP notifications. Again, this is not a case of people picking wild-wacky-action-options -- this is an issue of nLite doing something it shouldn't be doing, and therefore inducing WFP. This did not happen a couple versions back, which implies something is going on behind the scenes inside nLite. Please shed some light on this, and do not post "one-liners" asking us to start replacing random .sys files in \System32. :-)