[Dogway]

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, etc
It 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.ini

The 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...

This post has been edited by Dogway: 30 March 2013 - 01:39 PM

[Kurt_Aust]

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 > nul
CMD /R %Source%OTROS\RUN.bat

If 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 > nul
Start %Source%OTROS\RUN.bat

with the first line of the batch file being:
Ping -n 121 127.0.0.1 > nul


The way you have it currently the batch file will execute at the same time that the user account is created.

[Dogway]

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.

This post has been edited by Dogway: 18 March 2013 - 07:33 PM

[Kurt_Aust]

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.

Attached File(s)

•  LAST SESSION.INI (10.21K)
  Number of downloads: 5

This post has been edited by Kurt_Aust: 19 March 2013 - 02:57 PM

[Dogway]

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]

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.

This post has been edited by Dogway: 20 March 2013 - 03:37 AM

[Ponch]

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]

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.

[francisuk]

Question
%Source% - << dos this look on the CD ROM?