Dogway Posted March 18, 2013 Posted March 18, 2013 (edited) On XP x64, but building XP x86. I must have built like more than 20 isos one after another trying to figure out what was causing the issues. They are actually only present when installing XP on VBox, not while building.I managed to narrow one, while XP is registering components I was getting error messages like:system32/regsvr32.exe: windows has no access....same for cmd.exe, nhelper.exe, rundll32.exe, grpconv.exe, nlite.cmd, etcIt was being caused by the IE8 addon built on DXUPAC.Still I was getting some conflicts and in the end I decided to test the simplest. No nlite tweaks, hotfixes or addons. No nothing, compress, and test. This is my last_session.iniThe errors I get are:-while registering components->"Windows can't load internet configuration library ICFGNT.DLL..."-And then I have configured a RunOnceGUI command for a bat, which calls a .vbs file. Well, the thing is it doesn't work because it seems that WSH.inf (windows script host) hasn't been installed by nlite, that means that there are application I can't install either, etc-can't access msconfig from run box, and who knows what else might not be working....What is happening here? can having a likely faulty XP x64 (it needs a format indeed) have an incidence on nlite iso buildings?I have enabled VT on BIOS, and old custom builds done in XP x86 do install fine on VBox so it isn't a VBox problem either.edit: If the problem is XP x64, I can lastly do one experiment, install my old working build on VBOX, install nlite and build my XP there... Edited March 30, 2013 by Dogway
Kurt_Aust Posted March 18, 2013 Posted March 18, 2013 On the batch file front, your GuiRunOnce should look like this if you want the batch file to run BEFORE the user account is initialised:[GuiRunOnce]Ping -n 41 127.0.0.1 > nulCMD /R %Source%OTROS\RUN.batIf you want the batch file to run AFTER the user account is initialised it should look like this:[GuiRunOnce]Ping -n 41 127.0.0.1 > nulStart %Source%OTROS\RUN.batwith the first line of the batch file being:Ping -n 121 127.0.0.1 > nulThe way you have it currently the batch file will execute at the same time that the user account is created.
Dogway Posted March 18, 2013 Author Posted March 18, 2013 (edited) mmm well thanks for the advice, I had the ping command inside the batch file. But maybe that wasn't ideal.Anyways, any idea about my issues? ICFGNT.DLL and WHS.dll not being installed? As I said my old build is setup same as this one (concerning ping, etc) and it works, so that's not the problem.EDIT: Built ISO in virtual XP x86, run in VBOX from XP x64 with same issues. Next test, VBOX inside VBOX. I also found some threads talking about this issue here, seems like an old and random bug.This is my setuperr.log.My healthy setuperr.log looks like this, although not sure now if that is healthy at all. Edited March 19, 2013 by Dogway
Kurt_Aust Posted March 19, 2013 Posted March 19, 2013 (edited) When running nLite, did you turn off your anti-virus? I find leaving mine running while nLite is processing causes problems.I've attached a known to work XP sp3 last session created under XP x64.LAST SESSION.INI Edited March 19, 2013 by Kurt_Aust
Dogway Posted March 19, 2013 Author Posted March 19, 2013 I have no antivirus, because my laptop broke and now I'm on a temporary system until I format. I checked with another XP source and it builds without problems.What I found out is that this source doesn't like my OS, because my old custom build was using the same source but built on my laptop XP SP3 x86 and it worked (installed) as always. So what I can try is to borrow a friend's system with XP SP3 x86 and try to build it there because building inside a XPSP3 VM didn't work either. It's a bit a hit or miss but I don't think I need to do all the hassle explained on RyanVM, I hope not to.For the time being I will try to update and improve other areas of the unattended.
Dogway Posted March 20, 2013 Author Posted March 20, 2013 (edited) Well I have to retract from what I said on my OP. The IE8 addon built on DXUPAC is OK, it's just that it triggered more errors when added on the problematic source.What I wanted to remark is a sentence from the next post:"Using nLite on a 64bit OS in a 32bit environment will for the most part fail. (32bit OS's don't have the capability of handling 64bit files properly)"That could explain the problems I am having if that's true for the inverse, 32bit OS on a 64bit environment. "For the most part" could explain why one source failed and the other didn't. But what annoys me is that I couldn't trick nlite building the OS on a VM with 32bit XP. It really looks like nlite relies a lot on OS environment, but I can only check this next day when I test on a true XP SP3 x86 system of a friend, and see if it fails or not.Another thing, where is the driver signing check in nlite? I can't for the life of me find that option. It's that or disable by command line, I heard bcdedit.exe can be used for vista onwards, what about XP?edit: looks like nlite adds that option automatically? I found it's already added in HIVESFT.INF (with one zero though). Anyways I also saw the reg. entry in this post, I will add both. Edited March 20, 2013 by Dogway
Ponch Posted March 20, 2013 Posted March 20, 2013 As far as I remember, there is no "Driver Signing Policy" option in nLite, What you see as result is the settings of the original cd.XP does not have a bcd, Equivalent of "bcdedit" is editing Boot.ini .
Dogway Posted March 23, 2013 Author Posted March 23, 2013 I copied again my ISO and now it works. It seems it was faulty, now I don't know how a digital copy can be faulty, but now this works, so thanks god.
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now