HFSLIP.CMD is deleting the HFSLIP folder!

[LeveL]

Here's what I did:

1 - Got XP with SP2 already slipstreamed as my source.

2 - Put all the hotfixes and other files in the relevant folders.

3 - Ran HFSLIP (v1.6.2)

4 - Stripped WMP and IE out with nLite. (I added all the files

from HERE to the advanced box in nLite)

5 - Tried to install the OS and got a message saying it cannot find C:\WINDOWS\HFSLIP\HFSLP200.INF

(It says this for the #200 all the way to the last file #281) if I get past the 81 errors, Windows installs

fine after this.

I realized the problem - in the file I386\SVCPACK\HFSLIP.CMD it says:

RD/Q/S %SYSTEMROOT%\HFSLIP

So I put REM in front like this:

REM RD/Q/S %SYSTEMROOT%\HFSLIP

Tested the ISO again and its fine.

I don't know why the HFSLIP.CMD is removing that folder before the INF files are accessed.

[Tomcat76]

Something else must've gone wrong. The INF files should be processed before SVCPACK.INF is. HFSLIP.CMD is called from SVCPACK.INF so at that point it should be safe to remove the %SYSTEMROOT%\HFSLIP folder.

Do all the HFSLPxxx.INF files still exist in the source after running nLite? Are they still referred to from TXTSETUP.SIF?

[LeveL]

Do all the HFSLPxxx.INF files still exist in the source after running nLite?

Yes, they are all still there in I386.

At one point I even added the HFSLPxxx.INF files to the advanced box in nLite, just to make certain they were kept, but they were all kept anyway.

Are they still referred to from TXTSETUP.SIF?

Yes. This is whats so strange.

The [WinntDirectories] section still lists 999 = HFSLIP too!

I have managed to work around it by just removing the line in HFSLIP.CMD that does RD /Q /S %SYSTEMROOT\HFSLIP and simply removing the HFSLIP folder later on when Windows logs in (its unattended so it always had a few apps installing and tweaks after install)

Here's the log:

HFSLIP_LOG.zip

Edited August 19, 2007 by LeveL

[Tomcat76]

Your log seems to be fine at first glance, though I'm not sure WGAPluginInstall.exe is supported properly.

Can you make an installation without nLite? I want to make sure it doesn't mess up the RunOnceEx that occurs right before SVCPACK.INF is accessed.

[Tomcat76]

If you want, you can try out test release 70820a which removes the %SYSTEMROOT%\HFSLIP folder at first GUI logon.

But I'd definitely try to figure out the cause of your problem because your situation isn't normal.

[whitehorses]

Hello Tomcat Hi LeveL

I have EXACTLY the same problem. I have gone throught those five steps exactly the same way, and had errors hfslp200.inf to hfslp287.inf (i think MS made some hotfixes during the time ) It is interesting, because I have HFSLIP15*.inf-s also, those seem to install fine.

I have used the latest final 1.7.0. ... I see that the RD %SYSROOT%\HFSLIP command has moved to HFSLPGUI since then. Now the problem still comes up after first gui logon WHY?!?

Uh..what if the HFSLPGUI RunOnce would be changed to RunOnceEx ZZC ?

By the way I'm just making a test install with pure HFSLIP (without nLite) so I will come back with the results.

EDIT:

Back with the results, and good news: it installed fine, so primarily it's not a problem with hfslip.

@Tomcat

Do you have any ideas what nLite messes up? where can it interact with HFSLIP files for such results? Is it possible to do this without modifying HFSLIP files, because I can check easily if that's the case?

Edited November 24, 2007 by whitehorses

[tommyp]

I had some probs with the latest version of nlite, setup stalled at t-9. Perhaps the latest nlite 1.4 is a bit too buggy (which kind of surprises me because nlite always worked fine in the past for me).

[Tomalak]

Hello,

I always had problems with HFSLIP in combination with nLite (even older versions than the current 1.4, I have not tested this one yet), similar to the ones above but not exactly the same. As soon as I used nLite's unattended functionality, e.g. for user information, display settings and automatic updates, it broke the first-logon installations previously prepared by HFSLIP: DotNET 3.0 was not installed, the Windows power shell was missing, and so on. No error messages appeared during the installation.

I never tried to analyze that further (I didn't touch the "RunOnce" tab in nLite at all, that's not the culprit), even TC76's tool to list the added files and put them in the nLite "keep box" didn't help. Any idea what to look for and how to detect what was destroyed by nLite? Which files should I compare before and after its run, and which sections have eventually to be restored?

If necessary I can do some (virtual) test installations today or tomorrow and provide more details as long as you tell me what information you need

Thanks a lot!

Tomalak

[Tomcat76]

If necessary I can do some (virtual) test installations today or tomorrow and provide more details as long as you tell me what information you need

I don't know what other info I might need. Try the latest test release; it delays the installation of first logon installs until the system is out of setup, and the temporary %SYSTEMROOT%\HFSLIP folder is only deleted after that.

[whitehorses]

As I remember nLite never touches HF*.INF files, so if the added files are not removed from SOURCESS, then there should be no problem. HFSLIP should work separately, but still somehow they seem to interact. The problem is that nLite is closed source, and no one knows if nuhi is making an A-bomb behind the scenes

EDIT:

-----------------------------

I was using HFSLIP v1.7.0 Final, when the problem occured. I changed HFSLPGUI.INF like this:

HKLM,"SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnceEx",ZZZ,0x20000,"CMD.EXE /C RD/Q/S %WINDIR%\HFSLIP"

Well actually after the install I found the HFSLIP dir so it wasnt working but I tried at least End it's still better than deleting it before running. So to say, I will check the latest test release then.

As I said I also wanted to remove WMP(9&6), while slipstreaming WMF9 codecs. I did the following:

1.) I created a removal set for HFCLEANUP, which is very safe, at least it does everything the originals, plus adheres to the "nLite keepbox list" at tommyp's HFCODECS guide.

2.) After this I used nLite with Sound Drivers and Windows Media Player 6 DESELECTED, so not to mess up anything.

The RESULTS are:

--------------------------------

So far it works like a charm. I use MPC and it plays .wmv and .wma files fine. No errors suring install, setuperr.log is 0Kb, so I'm statisfied with this. Everithing installed fine. Here is a screenshot:

I have some QUESTIONS though:

----------------------------------------

1.) I made the HFCLEANUP removal files, so that they keep wmnetmgr.dll and sl_anet.acm among others, because they were in the "keepbox" stuff. Are they needed? (most of these files I am talking about are in MultiMed_WindowsMediaPlayer9a.rem that is)

2.) In the TOTAL remover I used the ZZZZZ original, and put in msoobci.dll and wmsetsdk.exe plus made a filter for HFSLIPWU.INF not to create folder in Program Files. I dont really found anything about these files... what are they for? Streaming I think not at least...

whs_logs.zip

Edited November 25, 2007 by whitehorses

[Tomcat76]

The thing is that HFSLIP 1.7.0 removes the HFSLIP folder at first GUI logon provided that no serious error occurs during Windows setup which causes the system to reboot internally and consequently run the RunOnce(Ex) at too early a stage.

The latest test release, on the other hand, additionally checks (through HFSLIP.CMD) if the system is still in setup or not before executing the first GUI logon installs (and the command to remove the HFSLIP folder). If the system is still in setup, HFSLIP.CMD won't execute the intended commands and will instead add a new RunOnce entry into the registry to call itself again at the next RunOnce event. Even if the system reboots 5 times internally, HFSLIP.CMD created by the latest test release should be able to pick that up nicely. Only if the system is out of setup will the first GUI logon installs be performed (and the HFSLIP folder be removed).

Concerning your other question... I suggest you read the new information on the Important things to know page on the HFSLIP web site. It links to a utility which creates a list of new binaries slipstreamed by HFSLIP.

[whitehorses]

Here is a list of files which nLite removed, and were in the generated NEWBIN.TXT too

archvapp.inf
authroot.sst
axaltocm.dll
basecsp.dll
bcsprsrc.dll
cobramsg.dll
delroots.sst
drmupgds.exe
guitrna.dll
ifxcardm.dll
MFPLAT.dll
migisma.dll
migwiz.htm
migwiz.man
migwiz2.htm
migwiza.exe
pintool.exe
roots.sst
scripta.dll
spmsg.dll
sysmoda.dll
updroots.exe
updroots.sst
uWDF.exe
verclsid.exe
WdfApi.dll
WdfMgr.exe
wmdrmdev.dll
wmdrmnet.dll
wmdrmsdk.dll
wmvadvd.dll
WMVADVE.DLL
wpd_ci.dll
wpdconns.dll
wpdmtp.dll
wpdmtp.inf
wpdmtpdr.dll
wpdmtpus.dll
WPDSp.dll
wpdtrace.dll
wpdusb.sys
xpsp3res.dll

Also these files are ALL what HFSLIP added except the HFS*.INFs, so everything was removed. I mean it is possibly not an error, if these are only what I asked nlite to do. TommyP, can you see anything in this list that must not be removed in any case at nLite removal? (esential system component or something) If not, then I think everything is ok, since the install was smooth, there was not a single entry in errorlog too, so...

Edited November 25, 2007 by whitehorses

[whitehorses]

Yawn...

By the way i made a test run with the current test release and the problem was still there, ie. that HFSLIP folder gets deleted before RunOnceEx entries of HFSLIPWU.INF get their turn. It seems to happen only if nLited after hfslipping for some reason.

I have searched for some RunOnceEx info, and after what I found I don't realy understand the method here. RunOnceEx supposed to execute its entries in order, so I don't see why not to use it.

HKLM,"SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnceEx\ZZA","999",0,"CMD.EXE /C RD/Q/S %10%\HFSLIP"

EDIT:

After a few hours of deciphering text, it turns out that I was wrong, because by just adding that it does not assure anything that other RunOnce entries (directx?) will be able to run. I think it can not be easily solved for now, because hfslip uses all kind of methods to run the inf files (for example HFSLPDY). Why not using only RunOnceEx, it would be any easy way to solve this...

I have to sleep I think...

Edited November 25, 2007 by whitehorses

[Tomcat76]

TommyP, can you see anything in this list that must not be removed in any case at nLite removal? (esential system component or something)

These are new binaries. If you don't want them, why are you slipstreaming them in the first place?

By the way i made a test run with the current test release and the problem was still there, ie. that HFSLIP folder gets deleted before RunOnceEx entries of HFSLIPWU.INF get their turn. It seems to happen only if nLited after hfslipping for some reason.

HFSLIPWU.INF, the file which adds the RunOnceEx entries to install the HFSLPxxx.INF files, is called from SYSOC.INF somewhere in the middle of Windows setup. At the next event RunOnceEx is supposed to kick in (somewhere around T-13), those RunOnceEx entries should be executed. The new HFSLIP.CMD, which removes the HFSLIP folder, can only run if the system is out of setup (after the final reboot).

Theoretically, it is impossible that the HFSLIP folder gets removed before the HFSLPxxx.INF files are executed... unless nLite makes Windows identify itself as being "no longer in setup". HFSLIP.CMD checks the value of SystemSetupInProgress under the HKEY_LOCAL_MACHINE\SYSTEM\Setup registry key for that. Only if the value is "0" (dword:00000000) will it perform the installs intended to be run at first GUI logon.

HKLM,"SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnceEx\ZZA","999",0,"CMD.EXE /C RD/Q/S %10%\HFSLIP"

That code is not based on what the latest test release writes.

I think it can not be easily solved for now, because hfslip uses all kind of methods to run the inf files (for example HFSLPDY). Why not using only RunOnceEx, it would be any easy way to solve this...

The stuff in HFSLIPDX.INF and HFSLIPDY.INF need to be run at different stages; HFSLIP makes use of the fact that RunOnceEx and RunOnce occur at different times.

[Tomalak]

I don't know what other info I might need. Try the latest test release; it delays the installation of first logon installs until the system is out of setup, and the temporary %SYSTEMROOT%\HFSLIP folder is only deleted after that.

Yes, this does work indeed - DNF30 and MS power shell got both installed, with the "Unattended" section on nLite used (to besure I populated its keep list with the output of your "POST_getnewfiles" script). I used version 1.7.1beta_71124a.

I have some other problems with it right now, but will have to investigate that further next weekend: the critical updates 939653 and 938127 (both for IE7, was the allowed naming scheme changed?) as well as the optional 920342 got not installed (at least Microsoft Update thinks so). Oh, and the renaming of "Windows Update" to "Microsoft Update" as well in the start menu as in IE7 didn't work. However, this only affected the names, not the functionaliy, using MU worked flawlessly.

Thanks, TC76, for your help and resolving the issue with the HFSLIP-nLite combination!

Tomalak

HFSLIP.zip