Being a newbie, I naively chose Method 1, since I didn't think I needed the apparent complexity of Method 2.

At any rate, I submitted a bug report via bugtracker per your suggestion.

basil.

Well, I just tried Method 2; everything else the same; namely just text-mode Mass Storage drivers, and all worked perfectly without any tweaking at all.

Problem of skipping dp initial setup screen is a function of Method 1.

Basil.

I"m not sure what you mean by boot image. I assume everything on my ISO is sourced from an XP PRO retail upgrade disk, SP2, and DriverPacks, except the boot sector supplied by nlite, which, according to the inline help "is a boot sector for all Windows versions which will initiate normal boot with i386/amd64 folder.".

I can see now that Method 2 makes sense for what I want to do, since, presumably $OEM$ and winnt.sif wouldn't be generated

At the time, though, I didn't consider using Method 2, as I didn't understand that text-mode drives are a different set (or at least a subset) of drivers than the MassStorage DriverPack drivers, and I didn't understand that the text-mode drivers were integrated into microsoft source files.

In fact, because I had thought the disk drivers wouldn't unpack until well into the operating installation process, that there would be no way that Method 2 would work for me.

Now I see Method 2 would work because the text-mode drivers are directly integrated, and Method 2 would prevent $OEM$ and OEM entries in winnt.sif from being generated.

Bottom line, it seems to me that just adding text-mode hard disk drivers and nothing else ought to produce a working Recovery-capable CD, whether using Method 1 or Method 2, without a bunch of manual file manipulation afterwards.

Basil.

OK, I just ran the test and everything worked just like I wanted it to! So I'm finally a happy camper!

I added only the text mode Mass Storage drivers, and then nuked both the unneeded/unwanted winnt.sif file and the rump finisher-only $OEM$ afterwards, and then ran nlite to burn the ISO.

The resulting CD performed exactly like I expected and wanted it to; worked perfectly on the  SATA laptop I've been using for testing, including appearance of the initial dp screen, and subsequent test of Recovery Console.

It does seem like in MassStorage text-mode only case that winnt.sif and $OEM$ shouldn't be generated, and prevents a useful function, namely generation of recovery-repair-only CDs that include a nice set of modern disk drivers, and therefore will function on a wide variety of machines.

All of this has now made me wonder what is the source of the text-mode drivers. Are these a subset of drivers extracted from the MassStorage DriverPack?

Perhaps a couple more lines of explanations about this issue in the tutorials would be useful.

Also, since the two subsets of drivers are mutually exclusive, it might make things a bit less confusing if the "DriverPack MassStorage text mode" wasn't separated by spaces from the main list. As is it now stands, I thought this was some kind of option, rather than a DriverPack. In fact, move this to right below "DriverPack MassStorage 7.11" in the DriverPack list.

Even better, list these next to each other and rename as follows:

"DriverPack MassStorage text-mode drivers 7.11"
"DriverPack MassStorage plug-n-play drivers 7.11"

"If you just want a disk that doesn't require you to hit f6 and provide a driver.  Just only check textmode mass storage and unselect all other packs. (if you simply delete folders you will create problems. We don't add stuff that is not needed."

That is exactly what I want: Recovery Console functionality, Install Repair, and SCF source.
And so for that reason, I did add just the Mass Storage pack in text mode.

Except now I understand that what I really did was to add the Mass Storage pack in text mode AND ALSO CHECK the Masstorage Pack from the list. I didn't realize these two things were mutually exclusive. (This explains why I saw both a text mode and a non-text mode SQC folder.)

So, I just did that. Nothing but the finisher in $OEM$ now. But I still get a winnt.sif file with:

OemPnpDriversPath="0"
OemPreinstall=Yes
command9="%SystemDrive%\DPsFnshr.exe"

I guess this is to make the finisher run, but won't OemPreinstall=Yes still cause the initial dp screen to be skipped? And it seems like running the finisher is a moot issue for my purposes (SCF source, bootable CD-based Recovery Console execution, and bootable CD Installation Repair.)

So once again, I'm back to: if the only thing I've added with driverpacks is the text-mode Mass Storage drivers, and these have been system-iintegrated rather than inserted via $OEM$, why do I even need winnt.sif and $OEM$ (at least for my stated purposes)?

Basil Irwin.

BTW, Jeff, thanks for the help!!!



Thanks, Basil.

So, that means for the text mode Mass Storage Drivers, I could just nuke winnt.sif and all will be well as far as the added disk drivers being functional? And by direct integration, does that mean I could nuke $OEM$ also?

Thanks, Basil.

Well, the floppy option is out since modern systems don't have one anymore.

But I'm still a bit confused why the floppy trick would even work. Wouldn't the absence of
OemPreinstall=Yes cause the added drivers not to install?

basil.

I received this from Grisoft regarding my submission of AVG false positive for mute.exe:



Dear Sir/Madam,

Thank you for your email.

We analyzed your file and we can confirm, that it is a false positive.
The detection of this file will be removed in next virus update.

If you need to restore deleted files from AVG Virus Vault you can do
it this way: open AVG Virus Vault (Start -> Programs -> AVG Antivirus
-> AVG Virus Vault). Locate the file that was removed, right click on
it and choose "Restore File(s)" option.

We are sorry for the inconvenience.

Answers to the most common questions can be found here as well:
http://www.avg.com/faq/

Best regards,

Martin Hosnedl
AVG Technical Support

website: http://www.grisoft.com
mailto: technicalsupport@grisoft.com

I'm at my wits end on this, despite spending two days searching and studying why this is happening, so I need some help.

I'm trying to make an XP Pro recovery CD that can be used with SFC (easy), as well as for booting for accessing the Recovery Console and for installation repair. Want to send copies of this out to VAR clients, since most OEM disks won't do these things.

I started with a retail XP Pro Upgrade SP1, slipstreamed SP2 with nlite. The resulting CD works just like it's supposed to, though of course no SATA drivers.

To add SATA drivers, I used DriverPacks as follows:

1. Copied the slipstreamed XP SP2 source directory, ran nlite again on the new copy to remove SCSI/RAID drivers, languages and keyboards.

2. Then ran DriverPacks on the new copy to add the Mass Storage drivers (text mode on), Method 1, QSC on, and default for everything else.

3. Finally used nlite again to just burn the ISO image.

The problem is when this CD is booted, the first setup screen is skipped, the one where you can select SETUP/Recovery Console/Quit, and goes directy to SETUP, where "Searching for previous versions of Microsoft Windows" is displayed, followed by a display of discovered partition(s) and options for the different ways to install Windows relative to the disovered partition(s).

Why is the first setup screen being skipped (winnt.sif or other options, etc.) and how can I prevent it, so I can access the Recovery Console, etc.

Thanks, Basil Irwin.

Yep, I should have searched. I just looked at titles instead. At any rate, for what it's worth, I submitted the file to AVG as a false positive.

basil.

More info about avg, mute.exe and startpage.can:

http://www.virscan.org/report/32d61dbe4 … f5051.html

Well, I confirmed that disabling AVG solves all of the problems of mute.exe being unreadable, and therefore solves my nlite problem.

Would be nice if AVG folks would fix their virus definition.

basil.

AVG antivirus says \bin\DPsFnshr.7z\mute.exe is "startpage" trojan.

I can't open any copies of this file; discovered problem when nlite wouldn't make ISO image after running driverpacks to add mass store driver pack to XP SP2 source files because \$OE?$/$1\mute.exe can't be opened.

I assume AVG is preventing mute.exe  from being opened because it thinks it is contaminated.

I also assume mute.exe isn't really the startpage trojan, and that I'll have to disable AVG when I run nlite as the final step to creating an ISO image after running driverpacks.

Could someone confirm help confirm these assumptions?

Thanks, Basil Irwin.