GreenMachine

If you have not slipstreamed your hotfixes (you have not: they are run upon reboot) you are most certainly vulnerable to, for example, MSBLASTER, during install. Your network is wide open, TCP/IP has long been installed, and you are a sitting duck. You are also vulnerable during the GuiRunOnce phase, until you reboot and your hotfixes take effect. Either slipstream the critical hotfixes, particularly the Security Rollup, or keep that suckah unplugged during setup. I'm a bit surprised no one yelled at you earlier ... This is one of the main reasons behind Hotfix Slipstreaming ...

OK, for Windows 2000 maybe not hundreds, but plenty. Works for both. Just like this (cut and pasted from a working and tested copy) "ENU_Q8~1.EXE /Q:A /R:N /C:""DAHOTFIX.EXE /Q /N"""

I'll be moving my lab this weekend, so there will be very little input from me until at least Tuesday. Have a nice wekend!

Ideas? I would suggest you look for the source of the problem, not the workaround. That syntax works fine in SVCPACK.INF. Hundreds of unsuspecting XPCREATORS use it daily ... "Q832483.exe /C:""dahotfix.exe /q /n"" /q:a" (Your batch file may be next to SVCPACK.INF, but I do not think that is the working directory for SVCPACK, thus it does not recognize your hotfix as an application.)

@sixpack: 1) Correct 2) CDIMAGE /? will get you the switch info. Best off copying the switches from the Unattended Guide: to use mine requires 8.3 UPPERCASE. 3) Use Nero as before, however that was ... I just use CDBURN command line. No time for more detail ...

You da man!

Sorry, I have to butt in here ... As a software developer, I believe THIS article. The software you linked to is ... not good. Please read this link, and if you agree, link to the correct version of the program, and not the ... other. For PCI identification, nearly all available software is based on Craig Hart's PCI work. His site has links that should help you find what you need. EDIT:: Link above has been changed to that of the original software, not the low life stolen version. Shame on you, you software thief.

Now that you mention it, I think I may have already tried: I see I have that file. Guess I gotta strart keeping notes ... (Or stop drinking?)

Important Note: Of course, doing someting so silly on XPCREATE files would be frownd upon, totally unsupported and unnecessary ... I only use it when creating DOS CDs ...

You guys ... Admins should do this, they should do that. Man, this is the Internet, this is the last foothold of true freedom of speech THIS IS ANARCHY ! Admins? Those poor slobs put enough time and effort in. You have any idea what kind of job you are talking about? So, click on the bottom left somewhere, get this page in one document, your choice for the type, clean it up, and make a nice web page, or pages, host it on Yahoo for the "Admins" to look at, and if it looks good, I am sure they would be happy to provide a permanent home. Waiting on you!

You think your users are better at knowing the hardware than XP? Let XP install the drivers, then in your install script, determine which driver has been installed, either by the registry, or a known file. Remember Murphy's Law, and that computers always do as they are told.

OK, you caught me: I didn't specify my OS! So, if anyone get's it running from either SVCPACK.INF, or CMDLINES.TXT in WINDOWS XP, in otherwords BEFORE setup finishes and reboots, I would like to know how ... Strange thing, in both instances I install DX9, then the CORRECT update. 2K is fine, XP isn't. I'll try 2K3 tonight.

You know, that's the real reward here. I write the code, I decide the rules! I kind of suspected something like that. I'll look into it for a future release. But beware, those are few and far between! The bottom line is that writing productive code is interesting, but writing error checking code is ... boring ... just a bit less boring than troubleshooting. So, thanks for narrowing it down with me, and next time I pass by that code, I'll keep this in mind.

I got tired of doing that by hand, so now I just right click, and select either MakeDataISO or MakeBootISO. The code below assumes CDIMAGE.EXE in the path (e.g. System32), the boot image, BOOT.BIN, in the C drive at the root, and the output is E:\DATA.ISO. You may also want to adjust the switches. ... of course, what good is an ISO with a a way to burn it, thus the last two reg entries add "Burn To K:" to the right click of WinImageISO files (my ISO file type). Again, you can adjust the switches to make it work for you. You will need CDBURN.EXE in the path. Now I know, that this is probably not what Dominix was looking for, but I've found it usefull ... Windows Registry Editor Version 5.00 [HKEY_CLASSES_ROOT\Folder\shell\MakeBootISO\command] @="CDIMAGE.EXE -LDATACD -YD -N -H -X -BC:\\BOOT.BIN -OCI -M -D \"%1\" E:\\DATA.ISO" [HKEY_CLASSES_ROOT\Folder\shell\MakeDataISO\command] @="CDIMAGE.EXE -LDATACD -YD -N -H -X -OCI -M -D \"%1\" E:\\DATA.ISO" [HKEY_CLASSES_ROOT\WinImageIso\shell\BurnToK:] @="Burn To K:" [HKEY_CLASSES_ROOT\WinImageIso\shell\BurnToK:\command] @="CDBURN.EXE K: \"%1\" -SPEED 24"

Yea, idn't it? I want have a chance to look into it before next week, but that does make it stranger. Especially since in both cases I run the same DX9 install just before. You said it: wierd ...

Seems we scared him away ... good luck, JohnA ...

If you could try again, install in a clean directory, and don't change XPCREATE.INI, it would help me track it down. XPCREATE should be able to initialize everything correctly. LOGFILES.CAB is in the directory NEWFILES, after successfull completion.

Well, I was impressed! (But I like tooting my own horn.) The best part is ... the DX patch works fine as well. 2000 boots first time needing nothing. Go figure ...

Hmmm ... Hard to say, as I've never done it. Basically, think of it as two different steps. First, create your XPCREATE CD (as you've done), next, pretend that is the "original XP CD" needed for what ever instructions are in that guide, ignoring anything that may have to do with hotfixes or updates.This is kind of a specialty shop: XPCREATE updates the Windows components, the whole rest of "Unattended" is done as usual, with it's own guide and forum. In other words ... If you've got your CD up to date and working, you're outta here! The Unattended Forum is really where you want to be, but I do believe you should be able to find all you need in the Unattended Guide

That'll do ... I'm more interested in resolving the problem, not the symptom ... for that. I'll need the log files ... I forgot ... Welcome to MSFN!

I think Bonedaddy already confirmed that method ... however, if anyone get's it running from either SVCPACK.INF, or CMDLINES.TXT, in otherwords BEFORE setup finishes and reboots, I would like to know how ...

Put a boot image file named XPCTBOOT.BIN in the BOOT directory, that will overcome the problem. However, the real question is why it could not extract your boot image. The answer to that mystery is probably buried deep inside the LOGFILES.CAB log archive ...

Welcome, belkin, to MSFN! Never heard of that, but I can't say as I've ever actually tried it myself ... I would thnk that function is NOT in the I386 part of the CD. The other parts are not touched by XPCREATE itself, though SP1 may update files there. The best test would be to either manually slipstream SP1 to a CD, or get an MS CD with SP1 integrated, and see if that gives the same results. I doubt I'll be tracking this down myself just now, but if you find the problem, I'll add the solution to XPCREATE.

@WwTIPPYwW: To get back on target ... I have only managed successfly post install, i.e. RunOnceEx in my case (GuiRunOnce, RunOnce, are also fine). Both SVCPACK.INF and CMDLINES.TXT seem to not work,

@sixpack: Not really. It is an SFC question. you could copy there and System32, but if you do that, you don't need to even bother with the installer. @bonedaddy: Spill the beans, did you call that batch from SVCPACK.INF or CMDLINES.TXT? Just to be clearer ... the problem is not in calling/finding the patch, the problem is that the patch, properly called, does not install. The error log shows that it did run.