LiveXP/WimBoot failure

After loading the RAMdisk for a USB stick using grub4dos, in the middle of a black screen:

"The device associated with the following device driver will not work on this compute: winsfs.sys.
The device drive is not compatible with the x86-based version of WIndows your computer is running.
This device driver may be required to complete Windows Setup.
Please contact the device manufacturer to obtain drivers compatible with the x86-based versiopn of Windows.

Press any key to continue."

Press a key and it reboots.

Hi JonF,

Does the md5 checksum of the files inside %GlobalTemplates%\WimBootWaikFiles match with the ones

inside section [Md5info_of_Files_In_Project] of the wimboot script?

If yes can you post the checksums of that files from inside the not booting boot.wim?

Hi, JFX. Haven't "seen" you for some time.

Two checksums don't match:

wmgapi: 9c901aaa59cc959f2eb3ff056daefa3b
wimfsf: e3c2accfc25fdf2a528a7c8572c0a60d

I downloaded the WAIK from the link in the script, installed in in my XP VM, and got an wmgapi with an MD5 of 50528bfc7c8c9abd23d16a5b5dc9021b (which doesn't match either) and no wimfsf.sys

Yes I'm very silent watcher of winpe forums, since some time


these 2 checksum are form the amd64 versions.

If you have installed it already, right versions should be there:


%ProgramFiles%\Windows AIK\Tools\x86\wimgapi.dll

open %ProgramFiles%\Windows AIK\Tools\PETools\x86\winpe.wim with 7Zip

extract \1\Windows\System32\drivers\wimfsf.sys

RamBoot.7z 

This is very strange.

In C:\WinBuilder\Workbench\Common\WimBootWaikFiles I have wimfsf.sys., 61kb, MD5 02c863078600ea925128244e46736ff2.

In the log I have:
FileCopy - Copied [%BaseDir%\Workbench\Common\WimBootWaikFiles\wimfsf.sys] to: [%BaseDir%\Target\LiveXP\I386\System32\drivers\wimfsf.sys]

In the resulting ISO I have boot.wim, and in boot.wim in I386\system32\drivers I have wimfsf.sys, 51 kb, MD5 69bd7080d3a6b9d5c9fb2166a608a455. This doesn't work.

In C:\Program Files\Windows AIK\Tools\PETools\x86\boot.wim I find the 51K wimsfs.sys.

WTF??

Hi JonF

> In C:\WinBuilder\Workbench\Common\WimBootWaikFiles I have wimfsf.sys., 61kb
it should be 51 kb ;) and md5 correct

> In the resulting ISO I have boot.wim, and in boot.wim in I386\system32\drivers I have wimfsf.sys, 51 kb, MD5 69bd7080d3a6b9d5c9fb2166a608a455. This doesn't work.

this is correct, some files are patched during build,

here is a brief list:

Code: [Select]

SETUPLDR.BIN 4352373BC08FFA6D8FFDB20A3BA5BC9A  291 KB (298.096   bytes)
boot.sdi     22d9945b4aae36dd59620a918f2e65f4 3:02 MB (3.170.304 bytes)
fbwf.sys     77a786e15a46215b2549662e189a85c2 68:0 KB (69.632    bytes)
imagex.exe   b7529745928b8831c01aee147dc7223b  381 KB (390.720   bytes)
ramdisk.sys  94644648375f9f5f10a0b783e90d3a2a 22.0 KB (22.528    bytes)
wimfltr.sys  090a2b8f055343815556a01f725f6c35  127 KB (131.000   bytes)
wimfsf.sys   02c863078600ea925128244e46736ff2 51.0 KB (52.224    bytes)
wimgapi.dll  98ac67e24b18c21d3cf15d9fe75e1054  320 KB (327.744   bytes)

just for info - after patches of script (values can change in time)
wimfsf.sys   69BD7080D3A6B9D5C9FB2166A608A455 51.0 KB (52,224    bytes)
ramdisk.sys  8C87F2C123081642FA8103A857718209 22.0 KB (22,528    bytes)
setupldr.bin md5 changes due to selection

I do not know what is hapening there, wimboot works very solidly to everybody so far,
common mistake was mostly using wrong files, but since jfx provided you the right ones............

things:
better not to use "File Based Write Filter - Starter" with wimboot (I do not know if it has effect on your failure but it is pretty useless with wimboot)
also try without "Universal Video Driver"

and can you provide your 4nt script again ;) I lost the one you'd given...  .......

I'll keep trying.

I don't know if I ever gave you the 4NT script, but it's too big to attach. I'll upload it to my server a bit later. It includes a few aliases:

x = exit
p = ping
pa = ping altavista.com
sdel = select del [*.*]
s* = select /oe

hi JonF,

some more tips just came to mind:
test with smaller builds ;) to shorten build times (+tip: move apps folder elsewhere temporarly)
you can use wb77rc2 for faster tests 
and on your previous test, if you still have .iso at hand, be sure your emulator have enough ram

Good luck.   

aside: please clarify the fog about vistapecapi here http://theoven.org//index.php?topic=75 .........

I still haven't cleared my own fog about VistaPE.

One thing that the WIMBoot definitely does wrong; it doesn't copy SETUPLDR.BIN into %IsoDir%\HDDBoot\I386. That has to be done manually before copying to a USB stick.

If I burn the ISO to a CD and try to boot it complains that it can't find NTLDR. That's becasue NTLDR isn't in the ISO, althjough it is in %IsoDir%\HDDBoot.

Aha! Building without FBWF starter and universal video now gives me somethng that wil boot from a flash drive!

Now I'm going to put NTLDR into the ISO and see if that boots...

Nope, still comes up with "can't find NTLDR". The grub4dos menu never show.  But the flash drive boots. Progress.

Hi JonF,

maybe helps,
here is log of a test build using last Galapo's LiveXP (v888) distribution, by only using Basic+wimboot scripts all with default settings.
vmware opens iso nicely here
does your emulator open iso nicely ?

http://www.mediafire.com/?8ebf1dxpyfo68xz

does your emulator open iso nicely ?

No, the grub4dos menu does not show up and the message is CDBOOT: Can't find NTLDR,

I'll try with no apps.

try without changing setting grub4dos, default settings use bootsect.bin.
Good luck 

OK, with no appas and no drivers it works. Now to figure out which script ...

This is downrighjt strange.

I pput my drivers back in and it didn't boot, but for a new reason; the RAMdisk loaded and then it complained about a bad entry in tsxtsetup.sif.

After a bunch of testing I figured out:

• DPs-Build_MassStorageDrivers.script doesn't work with the new DriverPacks.net site, and seems to have issues even if I manually download and place the driver pack and base.
• DPs-Build_MassStorageDrivers-Bin.script is somewhat out-of-date.
• I can't get DPs-MassStorageDrivers_MSST.script to work.
• dp_mass_integrate.au3 from DPs-MassStorageDrivers_au3.script doesn't work with the new DiverPacks.net site, and the site where it got the nightlies is down, and it creates a bad entry in txtsetup.sif because one of the sections in DriverPack_MassStorage_wnt5_x86-32.ini contains null hwids.

So I updated DPs-Build_MassStorageDrivers-Bin.script (http://www.fleming-group.com/Misc/Scripts/DPs-Build_MassStorageDrivers-Bin.7z). I fixed dp_mass_integrate.au3 so it works with the new site and the only site where I can find nightly builds (http://tppc-support.nl/driverpacks/Nightlies/NT5/), and I changed it to skip entries with null hwids. So it all works now.

But is there something else it should do with null hwids? The section in question is:

Code: [Select]

[C]
ms_count=3
ms_1_deviceName="Compaq HP ProLiant SCSI"
ms_1_tag="symc8xx"
ms_1_sysFile="CPQ32FS2.sys"
ms_1_hwids="PCI\VEN_1000&DEV_0001,PCI\VEN_1000&DEV_0003,PCI\VEN_1000&DEV_000a,PCI\VEN_1000&DEV_000b,PCI\VEN_1000&DEV_000c,PCI\VEN_1000&DEV_000f,PCI\VEN_1000&DEV_0012"
ms_1_isBusExtender=false
ms_1_exc_skipIfOS="w2k"
ms_1_exc_replaceIfOS="wxp,w2k3"
ms_2_deviceName="LSI Logic C8100 PCI SCSI Host Adapter"
ms_2_tag="symc810"
ms_2_sysFile="CPQ32FS2.sys"
ms_2_hwids=""
ms_2_isBusExtender=false
ms_2_exc_skipIfOS="w2k"
ms_2_exc_replaceIfOS="wxp,w2k3"
ms_3_deviceName="LSI Logic C896 PCI SCSI Host Adapter"
ms_3_tag="sym_hi"
ms_3_sysFile="CPQ32FS2.sys"
ms_3_hwids=""
ms_3_isBusExtender=false
ms_3_exc_skipIfOS="w2k"
ms_3_exc_replaceIfOS="wxp,w2k3"
What does ms_2_hwids="" mean? Use the previous hwids? Or what?

• I can't get DPs-MassStorageDrivers_MSST.script to work.

Why ?

I don't remember. I'll try it again. I seem to have gotten the old DPs Build MassStorage Script script to work.

OK, for some unknown reason all three driver pack scripts are working for me. I have an updated DPs-Build_MassStorageDrivers-Bin.script with the 1006 base and 1011 drivers. I have an updated DPs-MassStorageDrivers_au3.script which has the current URLs. DPs-Build_MassStorageDrivers.script and the script it builds work. DPs-MassStorageDrivers_MSST.script works once I pointed it correctly to the driverpack.

None of them handle that weird section correctly. Maybe it doesn't matter. In the driverpacks forum I've been told that it's a non-standard workaround for the situation where one new driver replaces three drivers included in WIndows XP and Server 2003. That is, all references to symc8xx.sys, symc810.sys, and sym_hi.sys should be removed from txtsetup.sif (and it wouldn't hurt to remove the files) and CPQ32FS2.sys should be asociated with all the hwids associated with the removed drivers.

It seems to me that it's not critical to implement this, because the goal (at least my goal) is to have as many working drivers as possible, not necessarily the best available driver.

Plus it looks kind of kludgy to me. The program must read and parse and save pretty much the whole of each bracketed section, because the line that tells you this is a special case comes pretty late in the section. I haven't looked at dp_mass_integrate.au3 to see how it might be implemented, but I don't see any clever algorithm

Any comments?

Hi JonF !

None of them handle that weird section correctly. Maybe it doesn't matter. In the driverpacks forum I've been told that it's a non-standard workaround for the situation where one new driver replaces three drivers included in WIndows XP and Server 2003. That is, all references to symc8xx.sys, symc810.sys, and sym_hi.sys should be removed from txtsetup.sif (and it wouldn't hurt to remove the files) and CPQ32FS2.sys should be asociated with all the hwids associated with the removed drivers.

There is a real acknowledgement of it?
I can see references where this driver was discussed?
I have seen CPQ32FS2.inf a file there there is no unusual information on the driver, besides, that it is the old version (section  [version]
)

If it in a reality so, that is necessity to write an additional script making corresponding corrections in txtsetup.sif.
It is impossible to consider all non-standard situations.

With best regards