[RickRollNW]

Greetings,

Let me start off by saying what a pain in my backside this project has been, I am by no means the smartest person in the world but I cannot for the life of me figure this out.

I have created multiple iso's over the past year that have combined 32 and 64-bit editions of Windows 7, all worked fine. But as of a week ago I noticed they had a fundamental flaw. They're loaded using the 32-bit boot.wim. Meaning, if/when the time comes specific drivers have to be installed (RAID drivers specifically in this case) the proper version won't work. Example. I can load the 32-bit raid driver, and it will see the raid volume, and install just fine. But when it comes time to boot, it says the driver is corrupt. When attempting to use the proper driver, it won't see any of the volumes. I was baffled at first, until it hit me what the problem was, and I used and actual plain 64-bit disc to install and everything went fine. So. My undertaking has been to try to create a menu within my iso that will let me choose either the 32-bit or 64-bit boot.wim so I can load the proper drivers. I've searched for days with only pieces of anything even related to my case. Here is where I sit:

Renamed boot.wim to boot32.wim and added 64-bit boot.wim labeled boot64.wim.

Used BCDedit to edit boot\bcd to seek 32-bit wim properly and added option for 64.bit.

Upon testing via VM, works fine on 32-bit end, doesn't work on 64-bit, get prompt for missing CD/DVD driver.

I use the ISO on my thumbdrive via grub4dos emulation on a regular basis, being that I work as a technician in a retail outlet and I am always either installing Windows or using it to do repairs on others. It worked great until I figured this out, so, my goal now is to buff out the last (hopefully) remaining dent in this theory.

If ANYONE could PLEASE shed some light on this process or on what I'd have to do, I'd appreciate it. I am open to any suggestions at this point (short of splitting the versions into two isos, takes up too much room.) I will also provide any information as needed.

Thank you.

[submix8c]

Hmmm... I will NOT swear to this BUT... there's a way with newer OSCDIMAGE to allow for multiple boot configurations.

Just a quick-and-dirty HTH... I'm sure some other more knowledgeable member can shed more light.

[jaclaz]

See if you can find anything in here (this one actually needs duplicate .iso's - which you do not want):
http://reboot.pro/9076/
http://www.rmprepusb...iskautounattend
http://www.rmprepusb...ials/firawiniso
but since it was born to remove the "required CD/DVD" issue, it may contain the solution to this issue.
First one uses IMDISK second one Firadisk, possibly the first one could be more suitable, even if slightly more complex to setup.


jaclaz

[allen2]

Your approach seems logical but not fully (as 32bit exe can run under 64bit OS but not the reverse): I would have taken the 64bit disc and do the renaming to boot64.wim and add boot32.wim and use bcdedit as you did.
But perhaps this won't work either if the problem is coming from the raid driver.

[Tripredacus]

The RAID driver that the boot.wim uses is just for WinPE to be able to write to the drive. It isn't related to the RAID driver in your install.wim. WinPE/Setup writes everything (contents of install.wim) to the disk and the next boot doesn't have anything to do with it.

You can use a 64bit boot.wim to install x64 images only, but x86 boot.wim can install both archs.

[allen2]

Tripredacus, on 07 June 2012 - 07:22 AM, said:

The RAID driver that the boot.wim uses is just for WinPE to be able to write to the drive. It isn't related to the RAID driver in your install.wim. WinPE/Setup writes everything (contents of install.wim) to the disk and the next boot doesn't have anything to do with it.

You can use a 64bit boot.wim to install x64 images only, but x86 boot.wim can install both archs.

Yes but as the OP already tried installing with the x86 boot.wim and get an error then there may be a slight difference between the x86 (used to write the install.wim x64 or x86 to the disk) and the x64 raid driver used only when booting to the newly installed raid array. As i suppose it is a semi-software raid based most likely on an intel chipset, that wouldn't be too much of a surprise. If this kind of problem happened with a real raid controller (like a 3ware/Lsi one), it would be a complete different story.

[RickRollNW]

Hi all,

Thank you for the replies, was surprised to see so many. Let me lead in with a comment in regards to the raid drivers. This happened on two different controllers; An LSI 9260-8i in a server I was building for a customer, what first shed light on the flaw, as I would load the 32-bit driver and it would show the raid's VD's fine. But when I loaded the 64-bit, they'd disappear from the drive selection screen. I was forced to load with a 64-bit dvd, where the 64-bit drivers worked as expected. Otherwise, when attempting to install with the 32-bit drivers, when it came time to boot to continue the installation, I got the notification about the corrupt drivers. The same results happened on a lower end video editing system another customer had purchased on the 2011 platform, ASUS P9X79 Deluxe motherboard with an Intel raid controller, went to load 64 bit drivers, nothing appeared, 32 bit, drives appeared, finished first half of install, boot, iastor.sys is corrupt and/or missing, just as the above.

In regards to the links provided to resolve the CD/DVD issue, I actually do map the iso in question with Firadisk already, but I've also tried just a straight iso emulation without it, and the result is the same either way, the x86 half works as it always has, but the added x64 does not, so the provided links may or may not be all that helpful.

I am not against switching out of an ISO format either, I am fine with working with a raw directory install as I've seen some configurations where grub4dos can chainload certain images within .wim files. I will separate the 32 and 64-bit install.wims too if necessary, as that in itself doesn't take up that much more space, it's having to duplicate everything else along with them that does.

My end goal is to have 32 and 64 bit bootloaders so I can select the appropriate drivers, doesn't matter if install.wim's have to be separated, though I don't know how to point each setup file to the different install.wim's if I do. I don't know if 32-bit really can load 64-bit drivers, but my experiences so far tells me that isn't the case.

I'll keep attempting to tear into this, see if I come up with anything, hope to hear some more from you guys soon.

Edit: Also, it should be noted that while attempting to troubleshoot this, I removed the original install.wim and replaced it with a straight 64-bit install.wim. The same error occurred. I also copied the entire 64-bit sources folder over when doing this, though kept the 64-bit boot.wim labeled as boot64. The 32-bit end still continued to function correctly, the 64-bit remains nonfunctional. Not sure what I am missing to bridge the gap, as it were.

This post has been edited by RickRollNW: 07 June 2012 - 06:09 PM

[jaclaz]

RickRollNW, on 07 June 2012 - 06:07 PM, said:

In regards to the links provided to resolve the CD/DVD issue, I actually do map the iso in question with Firadisk already, but I've also tried just a straight iso emulation without it, and the result is the same either way, the x86 half works as it always has, but the added x64 does not, so the provided links may or may not be all that helpful.

Yep , I had guessed that (since you completely failed to mention firadisk, as well as any actual detail on how you have currently setup your iso ), the suggestion was to try using IMDISK instead (as it comes in 64 bit version and signed) but the not-so-hidden attached strings was YMMV .

jaclaz

[Tripredacus]

RickRollNW, on 07 June 2012 - 06:07 PM, said:

I don't know if 32-bit really can load 64-bit drivers, but my experiences so far tells me that isn't the case.

Of course not. WinPE (boot.wim) doesn't support WoW, so you need to match archs for either build.

I use x64 boot.wim to do everything nowadays tho.

[bphlpt]

Tripredacus, on 07 June 2012 - 07:22 AM, said:

You can use a 64bit boot.wim to install x64 images only, but x86 boot.wim can install both archs.

Tripredacus, on 08 June 2012 - 07:53 AM, said:

RickRollNW, on 07 June 2012 - 06:07 PM, said:

I don't know if 32-bit really can load 64-bit drivers, but my experiences so far tells me that isn't the case.

Of course not. WinPE (boot.wim) doesn't support WoW, so you need to match archs for either build.

I use x64 boot.wim to do everything nowadays tho.

Tripredacus, if RickRollNW is anything like me, I'm sure he's just as confused. Could you please clarify the apparent contradiction?

Cheers and Regards

This post has been edited by bphlpt: 08 June 2012 - 01:03 PM

[Tripredacus]

Ah yes. The 32bit setup.exe can show either a 32bit or 64bit index from install.wim.
The 64bit Setup.exe can only show a 64bit index from install.wim

Note I chose the term "show" as in will appear in the image selection window. For example: I never tried to force 64bit Setup to install a 32bit install using an answer file.

My 64bit boot images do not use Setup.exe.

[bphlpt]

Actually, I don't know if I understood your explanation any better. I also thought that your original statement was correct: That you can install either an x86 install.wim or an x64 install.wim with an x86 boot.wim.

Tripredacus, on 07 June 2012 - 07:22 AM, said:

You can use a 64bit boot.wim to install x64 images only, but x86 boot.wim can install both archs.

Isn't that correct? Yes, I know that you probably can't install 64bit drivers with the x86 boot.wim, but I thought the you can install the x64 install.wim and install the 64bit drivers once you have booted into the x64 OS. Isn't that the way it works?

Cheers and Regards

This post has been edited by bphlpt: 08 June 2012 - 05:26 PM

[RickRollNW]

jaclaz, on 08 June 2012 - 05:00 AM, said:

RickRollNW, on 07 June 2012 - 06:07 PM, said:

In regards to the links provided to resolve the CD/DVD issue, I actually do map the iso in question with Firadisk already, but I've also tried just a straight iso emulation without it, and the result is the same either way, the x86 half works as it always has, but the added x64 does not, so the provided links may or may not be all that helpful.

Yep , I had guessed that (since you completely failed to mention firadisk, as well as any actual detail on how you have currently setup your iso ), the suggestion was to try using IMDISK instead (as it comes in 64 bit version and signed) but the not-so-hidden attached strings was YMMV .

jaclaz

My apologies, I hadn't thought it relevant because the issue seemed to persist regardless of mapping, I will be sure to include such details next time. I did, however, attempt the IMDISK method, and the results were the same. So. It appears to be something on the image's end.

bphlpt, on 08 June 2012 - 01:02 PM, said:

Tripredacus, on 07 June 2012 - 07:22 AM, said:

You can use a 64bit boot.wim to install x64 images only, but x86 boot.wim can install both archs.

Tripredacus, on 08 June 2012 - 07:53 AM, said:

RickRollNW, on 07 June 2012 - 06:07 PM, said:

I don't know if 32-bit really can load 64-bit drivers, but my experiences so far tells me that isn't the case.

Of course not. WinPE (boot.wim) doesn't support WoW, so you need to match archs for either build.

I use x64 boot.wim to do everything nowadays tho.

Tripredacus, if RickRollNW is anything like me, I'm sure he's just as confused. Could you please clarify the apparent contradiction?

Cheers and Regards

Yes, I was indeed a tad confused by this at first, but I had figured out what he'd meant later.

My attempts thus far have been unsuccessful, does anyone else have anything that can shed some light? Should I attempt to do it the other way around, using a 64-bit image and adding in the 32 images and boot.wim after?

[jaclaz]

RickRollNW, on 08 June 2012 - 05:48 PM, said:

Yes, I was indeed a tad confused by this at first, but I had figured out what he'd meant later.

Could you share your understanding (since besides bphlpt I am confused at well)?

Right now I simply have no meaningful data to think about, I guess unless you try describing EXACTLY your setup, and the EXACT error and EXACTLY when it happens, I doubt that - besides me - anyone can really suggest you something of use.

RickRollNW, on 08 June 2012 - 05:48 PM, said:

My apologies, I hadn't thought it relevant because the issue seemed to persist regardless of mapping, I will be sure to include such details next time. I did, however, attempt the IMDISK method, and the results were the same. So. It appears to be something on the image's end.

Maybe it would be useful if you provided such details this time.
There are SEVERAL ways in which you may have used either Firadisk or IMDISK, several ways in which you could have edited the BCD and most probably n other factors that I am completely forgetting .

So, the mere fact that I extorted from you that you used firadisk and your subsequent report that you also tried IMDISK are of no actual relevance.

It is possible that if you DETAIL as much as possible your attempts someone can (hopefully ) spot where the issue lies.

Right now it seems to me that this thread till now is about people giving maybe 1/10 to 1/5 of the needed informations and other people giving "vague" guesses in such a way that they can be ambiguously interpreted.

Compare with:
http://homepage.ntlw...ard-litany.html


jaclaz

[johnhc]

Quote

My 64bit boot images do not use Setup.exe.

Tripredacus, I am curious how you do this. Is it the 32/64 nature of setup.exe that is causing the 'Load driver' function to fail to find a mass storage driver? Is this a work around for that problem? Thanks and enjoy, John.

[RickRollNW]

jaclaz, on 09 June 2012 - 09:15 AM, said:

Maybe it would be useful if you provided such details this time.
There are SEVERAL ways in which you may have used either Firadisk or IMDISK, several ways in which you could have edited the BCD and most probably n other factors that I am completely forgetting .

So, the mere fact that I extorted from you that you used firadisk and your subsequent report that you also tried IMDISK are of no actual relevance.

It is possible that if you DETAIL as much as possible your attempts someone can (hopefully ) spot where the issue lies.

Right now it seems to me that this thread till now is about people giving maybe 1/10 to 1/5 of the needed informations and other people giving "vague" guesses in such a way that they can be ambiguously interpreted.

Very well... I'll try this again. Coupled with the above, this is my current Firadisk map, as well as the Windows boot manager readout.

title Install Windows 7 SP1 AIO
set MYISO=Win7.iso
dd if=()/firadisk/au.xml of=()/AutoUnattend.xml
map --mem (md)0x800+4 (99)
map /ISO/%MYISO% (0xff)
map (hd0) (hd1)
map (hd1) (hd0)
map --hook
write (99) [FiraDisk]\nStartOptions=cdrom,vmem=find:/ISO/%MYISO%;\n\0
chainloader (0xff)/BOOTMGR || chainloader (0xff)

Windows Boot Manager
--------------------
identifier              {bootmgr}
description             Windows Boot Manager
locale                  en-US
inherit                 {globalsettings}
default                 {default}
displayorder            {default}
toolsdisplayorder       {memdiag}
timeout                 30

Windows Boot Loader
-------------------
identifier              {default}
device                  ramdisk=[boot]\sources\boot32.wim,{7619dcc8-fafe-11d9-b411-000476eba25f}
path                    \windows\system32\boot\winload.exe
description             32-Bit Bootloader
locale                  en-US
inherit                 {bootloadersettings}
osdevice                ramdisk=[boot]\sources\boot32.wim,{7619dcc8-fafe-11d9-b411-000476eba25f}
systemroot              \windows
detecthal               Yes
winpe                   Yes
ems                     Yes


Windows Boot Loader
-------------------
identifier              {613fe2f0-2356-11de-bf6a-001e4cdc40b1}
device                  ramdisk=[boot]\sources\boot64.wim,{7619dcc8-fafe-11d9-b411-000476eba25f}
path                    \windows\system32\boot\winload.exe
description             64-Bit Bootloader
locale                  en-US
inherit                 {bootloadersettings}
osdevice                ramdisk=[boot]\sources\boot64.wim,{7619dcc8-fafe-11d9-b411-000476eba25f}
systemroot              \windows
detecthal               Yes
winpe                   Yes
ems                     Yes

The methodology I use here seems to be nearly identical to the Firadisk link you sent me, with a few minor alterations on my end. This map has never failed me, and should be noted, does have 64 bit drivers to map with, as I've used this method to map two separate Vista iso's for repair purposes, as for some reason when their archs are combined, the setup slows to an absolute crawl. The IMDISK method I used was copied and pasted exactly from the page you linked me.

Since taking the steps I did above with the boot.wims, my attempts so far have been to first boot from the Firadisk method. I get, as was hopefully expected, the boot Windows boot manager, asking me to choose which bootloader I want. I chose 64 for the attempted install, and each time, regardless of Firadisk, Imdisk, or direct emulation from Grub4dos, it still resulted in a missing CD/DVD driver error, yet whenever I booted into the 32-bit bootloader (also regardless of method) it worked fine. I am baffled. So, my reason for leaving out the above is that again, it seems to be an issue with the images themselves and not how they're mapped, but.. I could very well be wrong. The USB drive from which I am booting is NTFS as well, not sure if that matters, but I don't want to leave out any information again.

[jaclaz]

RickRollNW, on 09 June 2012 - 07:57 PM, said:

The methodology I use here seems to be nearly identical to the Firadisk link you sent me, with a few minor alterations on my end. This map has never failed me, and should be noted, does have 64 bit drivers to map with, as I've used this method to map two separate Vista iso's for repair purposes, as for some reason when their archs are combined, the setup slows to an absolute crawl. The IMDISK method I used was copied and pasted exactly from the page you linked me.

Since taking the steps I did above with the boot.wims, my attempts so far have been to first boot from the Firadisk method. I get, as was hopefully expected, the boot Windows boot manager, asking me to choose which bootloader I want. I chose 64 for the attempted install, and each time, regardless of Firadisk, Imdisk, or direct emulation from Grub4dos, it still resulted in a missing CD/DVD driver error, yet whenever I booted into the 32-bit bootloader (also regardless of method) it worked fine. I am baffled. So, my reason for leaving out the above is that again, it seems to be an issue with the images themselves and not how they're mapped, but.. I could very well be wrong. The USB drive from which I am booting is NTFS as well, not sure if that matters, but I don't want to leave out any information again.

What I suspect (though having NO actual way to test/compare) and still related to the "missing CD/DVD" is the following:
with firadisk:
when chosing 32 bit wim firadisk (32 bit driver) maps BOTH the .iso at "boot time" and at "GUI install" since everything is 32 bit, everything works
when chosing 64 bit wim firadisk maps the .iso at boot time but results in "a suffusion of yellow" at GUI install since for *whatever* reason (driver conflict or 32 driver partially or fully loaded) the iso is not mapped properly

with IMDISK
when chosing 32 bit wim IMDISK (32 bit) maps the .iso at GUI install and since everything is 32 bit, everything works
when chosing 64 bit wim IMDISK (64 bit) maps the .iso at GUI install BUT for *whatever* reason (driver conflict or 32 driver partially or fully loaded) the result is "a suffusion of yellow"

It is also possible that for *any* reason the IMDISK that is installed throught the method here:
http://www.rmprepusb...iskautounattend
is the "wrong" version or that the version included (which is fairly old) has some issues together with your drivers.

In order to troubleshoot, if I were you I would try using the initial more manual method sketched here:
http://reboot.pro/90..._25#entry123384
https://sites.google...utorials/winiso

jaclaz

[RickRollNW]

jaclaz, on 10 June 2012 - 05:01 AM, said:

What I suspect (though having NO actual way to test/compare) and still related to the "missing CD/DVD" is the following:
with firadisk:
when chosing 32 bit wim firadisk (32 bit driver) maps BOTH the .iso at "boot time" and at "GUI install" since everything is 32 bit, everything works
when chosing 64 bit wim firadisk maps the .iso at boot time but results in "a suffusion of yellow" at GUI install since for *whatever* reason (driver conflict or 32 driver partially or fully loaded) the iso is not mapped properly

with IMDISK
when chosing 32 bit wim IMDISK (32 bit) maps the .iso at GUI install and since everything is 32 bit, everything works
when chosing 64 bit wim IMDISK (64 bit) maps the .iso at GUI install BUT for *whatever* reason (driver conflict or 32 driver partially or fully loaded) the result is "a suffusion of yellow"

It is also possible that for *any* reason the IMDISK that is installed throught the method here:
http://www.rmprepusb...iskautounattend
is the "wrong" version or that the version included (which is fairly old) has some issues together with your drivers.

In order to troubleshoot, if I were you I would try using the initial more manual method sketched here:
http://reboot.pro/90..._25#entry123384
https://sites.google...utorials/winiso

jaclaz

This is starting to get very annoying... heh. I did the above in the RMPrep tutorial almost exactly, the only thing I changed was their section on the two runiso.cmd edits. Being that I had no need for multiple ISO prompts, I changed it just to automap my single ISO. Now comes the funny part. Even having two separate and external boot.wims and two separate grub4dos enteries, it still didn't load it when I went to choose the 64-bit option, and yet, as almost predicted, the 32-bit continued to function correctly. Here is the code snippet from the grub enteries.

title Windows 32-bit OS Install Menu (bc1)\nIf you want to install a 32-bit OS
map --mem /bootmgr (rd)
write --offset=0x105E (rd)+1 \xEB\x08
write --offset=0x54696 (rd)+1 1
chainloader (rd)+1
root ()

title Windows 64-bit OS Install Menu (bc2)\nIf you want to install a 64-bit OS
map --mem /bootmgr (rd)
write --offset=0x105E (rd)+1 \xEB\x08
write --offset=0x54696 (rd)+1 2
chainloader (rd)+1
root ()

As well as my RUNISO.cmds.

TITLE WINDOWS 32-BIT OS INSTALL
@echo off
cls
echo.
echo.
SET MYISO=\ISO\Win7.iso

call \imdisk\MountDrive.cmd %MYISO%

TITLE WINDOWS 64-BIT OS INSTALL
@echo off
cls
echo.
echo.
SET MYISO=\ISO\Win7.iso

call \imdisk\MountDrive.cmd %MYISO%

When I selected the 64-bit option, it booted, came up, and when it went to map the ISO, I kid you not... it said 'The subsystem needed to support the image type is not present.'

What's going on with the image? Should I try the inverse of starting with 64-bit and adding 32?

[jaclaz]

RickRollNW, on 10 June 2012 - 01:11 PM, said:

When I selected the 64-bit option, it booted, came up, and when it went to map the ISO, I kid you not... it said 'The subsystem needed to support the image type is not present.'

What's going on with the image? Should I try the inverse of starting with 64-bit and adding 32?

Hmmm.
Steve6375's instructions/tutorials are usually VERY accurate.

Ideas :

• Try replicating it EXACTLY without introducing ANY change
  
• Try manually.
  
• Have you changed the startnet.cmd in both .wims?
  
• Did you experiment - like in the tutorial - with boot1.wim and boot2.wim or did you use directly the files inside the .iso?

jaclaz

[Tripredacus]

johnhc, on 09 June 2012 - 05:43 PM, said:

Quote

My 64bit boot images do not use Setup.exe.

Tripredacus, I am curious how you do this. Is it the 32/64 nature of setup.exe that is causing the 'Load driver' function to fail to find a mass storage driver? Is this a work around for that problem? Thanks and enjoy, John.

I use Imagex. I do have normal DVDs that use setup.exe, but their install.wim only have 1 image in them. The only time I used one with multiple in the install.wim was with WDS which was I saw this issue where the Setup boot.wim from 7PRO64 would not display 32bit images.

From my understanding, setup.exe uses drvload to install the mass storage drivers. As far as drivers not being found, I've encountered this before, but usually to do with either a corrupted ISO or with poorly written drivers.

Quote

When I selected the 64-bit option, it booted, came up, and when it went to map the ISO, I kid you not... it said 'The subsystem needed to support the image type is not present.'

What's going on with the image? Should I try the inverse of starting with 64-bit and adding 32?

Either the 32bit or 64bit boot.wim does not support WoW. So if you got that error while running a program on the 64bit boot.wim, then your program or required libraries were not 64bit.