I've recently got my hands on one of those SanDisk Extreme 64GB sticks and started tinkering with it. During this story, please keep in mind that this is a model where removable bit is set to 0 (which means Windows sees all its partitions by default - each is shown as a single disk in explorer).

Objective

To have multiple functioning Windows installers on a single partition. This either means getting the installer to function from .iso image without unpacking (this is the way which is being pursued in this thread) or editing BCD in such a way to allow installers co-exist on a single partition (alternative way, secondary to the first one).

Investigation

Now originally this all started as a question [1] on SuperUser. This was also discussed on RootAccess [2] chat room. This is where the link [3] was discovered. After digging it for 4 straight hours, I was able to successfully get to the screen of Windows installer (this was all attempted on Windows 7 installer but it seems Windows 8 installer is no different - correct me if I'm wrong) where you need to select (create, delete, modify) disk partitions.

Current setup

Simple Windows .iso was used as a starting point for customization. It's boot.wim (\sources\boot.wim) was modified to have ImDisk driver available for installation at the time of running setup.exe. The following commands are used to make our .iso available after switching to protected mode (during setup.exe):

Second line makes our .iso available in form of UDF drive (essentially a CD-ROM).

This script is tested and working (since we are able to select Windows version for installation). It can either be run manually (to be sure what exactly is happening and when) or automatically by using Winpeshl.ini. The modified boot.wim is written back to the .iso file by using WinISO. After that, YUMI [6] is used to boot this iso from the second partition of SanDisk Extreme (using GRUB .iso boot).

Current issue

When selecting a partition for Windows installation - a message is displayed saying that 'installer was unable to create or locate the existing system partition'. Accessing the setupact.log during this time reveals that disk0 (the fully empty laptop internal hard drive) was skipped due to not being 'the computer's boot disk'. This same error is described in article [4] (last one):

[BLOCKING reason for disk 0: CanBeSystemVolume] The selected disk is not the computer's boot disk.

Already tried

1. Making the second partition on SanDisk non-bootable. SYSLINUX's altmbr.bin was used to boot second partition by number - not by boot flag. Same issue.

2. Writing Windows installer to another boot stick with unpacking - the usual easy case. When having both sticks plugged in and trying to install from disk with unpacked installer does NOT result in error (although SanDisk is obviously still detected as non-removable hard disk).

Questions

1. Not sure why this error is even displayed. How in the hell is it able to determine if it is the boot disk or not. Why in the hell would it even care .

2. How can I make it forget this nonsense?

3. Maybe there is altogether different way? Like custom installer described here [5].

I am not sure whether you are risking to re-invent the wheel (which is nice, as long as the result will be a rounder wheel, BTW ).

Not to correct your English, but this is a common cause of misunderstanding, the *whatever* gets a drive letter in Windows (or Explorer) is NOT a "disk" it is a "drive" or better "partition" or even better "volume", the "disk" is the WHOLE thing, containing volumes, which can be (if primary) partitions.

As a matter of fact, I have to make my compliments to you as your is one of the better "first posts" ever made, simple, clear, mentioning previous research, citing the scope and the current status, in one word, perfect .

Welcome to the board!

BUT installing from USB device has been experimented for years by now.

The "news" introduced by sticks like yours are not really "news", in the sense that (apart the higher speed) your stick is in no way different from a "common" USB stick (but with the "removable bit" flipped) or from a USB hard disk.

And there are several solutions that can be used to install from .iso residing on a "hard disk" type of device.

I am not sure whether you are risking to re-invent the wheel (which is nice, as long as the result will be a rounder wheel, BTW ).

Not to correct your English, but this is a common cause of misunderstanding, the *whatever* gets a drive letter in Windows (or Explorer) is NOT a "disk" it is a "drive" or better "partition" or even better "volume", the "disk" is the WHOLE thing, containing volumes, which can be (if primary) partitions.

As a matter of fact, I have to make my compliments to you as your is one of the better "first posts" ever made, simple, clear, mentioning previous research, citing the scope and the current status, in one word, perfect .

Welcome to the board!

BUT installing from USB device has been experimented for years by now.

The "news" introduced by sticks like yours are not really "news", in the sense that (apart the higher speed) your stick is in no way different from a "common" USB stick (but with the "removable bit" flipped) or from a USB hard disk.

And there are several solutions that can be used to install from .iso residing on a "hard disk" type of device.

Rounder wheel is always better. Your back hurts less as long as the road is the same

Thank you very much for the feedback regarding this post.

Yes, I an aware that there is the difference between disk partition and volume. There is some semi-sane concept behind partitions and volumes in Windows. For one, uncle Gates decided that hidden partition is NOT a volume for some reason and therefore can't be mounted.

Thank you for providing those links. I will look into those over the course of this week.

Meanwhile, if there are additional suggestions, I am always open to discussion .

Also, checking your original link on Superuser, this is not entirely accurate:

This is where control is transferred from MBR. This one has to be primary to be able to be transferred control from MBR.

this only applies to some "standard" MBR code.

But once you load - say - grub4dos you can boot from Logical Volumes inside extended alright, though you will need to "fix" the sector before data in the VBR (depending on the actual OS you want to boot), see:

seems to me nothing more than one of the common "technical rants" (understandable because coming out of actual frustration) but that adds nothing of use, basically Mr.Richards attempted to install a Windows 8 in a way that does not fit the "MS standard" and started whining because it did not work as expected.

And he had a similar results with a Linux.

I would say "normal", if you go out of the "paved main road" you must be ready to dirty your hands with some "tricks" to survive in the woods .

The real issue is, in the immortal words of Douglas Adams:

A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools.

Over the years we have seen tens or hundreds of similar cases, as a matter of fact the time spent in writing the "core" of *any* program or batch/script is usually a small fraction of the time needed to implement all kinds of "safeties" to avoid people self-creating issues through a "different" or "peculiar" use of the program/script, usually outside the originally intended paradigm.

If such a "safeguard" was not implemented in the ""standard" Windows install, do you have an idea on how many people would have botched their systems by installing to the "wrong" disk/drive by mistake?

Latest WinSetupFromUSB versions do all what you have described as a goals, making use of ImDisk, taking care of with a few possible hiccups you haven't came across yet .

As a side note, the original ISO is not modified and the extracted and modified boot.wim + bootmgr + bcd are used to boot the PE. Why- firstly for UEFI compatibility, if you boot in such mode, you can't use grub4dos to mount the ISO as an emulated optical disk, and grub2, which has UEFI port, can't do the job, or at least I couldn't make it so. And second- if you have to mount each ISO with grub4dos to chainload bootmgr, it has to be defragmented, which imposes another limitation. Loading the ISO in memory, to be able to use fregmented files is not an option to be mentioned.

Over the years we have seen tens or hundreds of similar cases, as a matter of fact the time spent in writing the "core" of *any* program or batch/script is usually a small fraction of the time needed to implement all kinds of "safeties" to avoid people self-creating issues through a "different" or "peculiar" use of the program/script, usually outside the originally intended paradigm.

If such a "safeguard" was not implemented in the ""standard" Windows install, do you have an idea on how many people would have botched their systems by installing to the "wrong" disk/drive by mistake?

Wonko

You see, I am completely with Tom Richards on this - if you have 1000 and 1 safeguards, you also should have one --force to rule them all.

Right.. I have tried WinSetupFromUSB today.

I have to say, this is a pretty good program. It only weighed 22MB when downloading and has a few useful tools as well as 'Test in Quemu' thingie - which I enjoyed tremendously.

While it was successful in booting my Windows .iso if I let it format my drive,its bootmgr threw an error when I attempted to boot it from my own SYSLINUX (from YUMI).

The error was 0xc0000225 Error occured while attempting to read BCD. Bootmgr was started from SYSLINUX with usual command line: chain.c32 ntldr=/bootmgr

Not sure what kind of error could that be, but if I will be able to get it working without re-formatting, I think this will be pretty close to what I am trying to achieve.

Well, just like Mr. Richards in the mentioned article, you are attempting to use the tool either outside it's usage paradigm or according to your own workflow/ideas and NOT along it's intended usage/as per instructions.

In the case of WinsetupFromUSB we are talking of a tool that has helped to install Windows in thousands (or tens or thousands or more) cases, and Ilko - historically - has proved to be a very attentive developer, I cannot remember a single case in the last several years where an issue has not been solved (or worked around) in a timely fashion.

Since I expected this since post #1 , I also pointed you to a couple of places where you can find the "base" information and most of the "theory of operation", so that you can develop your own solution/script/program/whatever, while taking advantage (with very little modesty) of the fact that you are standing on the shoulders of giants.

For the record, 22 Mb is what I personally call "an awful amount of bloat" , but of course beauty (and size appreciation) is in the eye of the beholder.

In any case, back to your failed attempt, if you provide an EXACT report of what you attempted, I am pretty sure that we can find where the issue is and/or suggest you the manual fixes to apply.

More generally, both WinsetupFromUSB and Steve's Easy2boot use as "main", base bootmanager grub4dos.

This choice is not "casual", we all know Syslinux since long before grub4dos ever came out, yet, for these projects grub4dos was chosen.

Would you not think that there are reasons for this choice?

If you prefer, while you can use Syslinux allright as "main" bootmanager, you will need to "pass control" to grub4dos anyway, as some of the features of these tools rely on grub4dos' features that are missing in both Syslinux and GRUB (and GRUB2).

But again, if you are "only" interested in Vista , 7 and later, the easiest solution is to boot a minimal PE and use the JFX's little nice tool (or manually apply the .wim).

Default WinSetupFromUSB configuration works, let grub4dos load Windows as it is. As mentioned, it was chosen for a reason.

If you do need to boot syslinux as well, use the provided option, or install it manually if you need other version. Be prepared for version conflicts- syslinux 4.x most likely will not work with 5.x com modules and vice versa, this is a little mess to deal with when multibooting, NTFS could be troublesome as well.

Back to WinSetupFromUSB, select advanced options, check "Do not check for and install grub4dos MBR", select the second partition in the drop-down menu, select Windows NT6 ISO or whatever you need to add, press GO.

Boot files go to the primary partition, that's on purpose, some BIOS-es have troubles reading beyond certain boundary. Rest of the files go to the selected partition. Test works in QEMU.

Lets try to move all files from the first partition to the second one. Test works in QEMU, all files are in the second partition.

Lets add syslinux- select the second partition in the drop-down menu, make sure advanced option "Do not check for and install grub4dos MBR is selected". Press GO.

Syslinux files are in the second partition, bootable. Create syslinux directory and config file, copy com32 modules as above.

Test in VirtualBox works. This is just for the test, not recommended. Use default grub4dos to boot Windows. It does more than simply chainloading bootmgr.

Thank you guys for all your detailed replies, I have troubleshooted the previous error using note about grldr.

The issue was that this utility simply thought it would be a good idea to put grldr and its files on FIRST partition (WHY??!11 it's not boot volume, its not distinguished by anything, sorry for failing to see that earlier) and my .iso and all files on SECOND (that's what I pointed it at, that's why I never knew there would be grldr in the first place, there was only bootmgr).

I have installed Windows now to make sure it's 100% OK and so far the solution is exactly what I'm looking for. I will test other tools (fast installers look especially tempting) eventually and keep this thread updated.

For now, second issue remains. This whole setup does not work from hidden partition (understandable). The script which WinSetupFromUSB put in place is 'unable to detect USB disk' (and if this check was not in place, Windows installer would show 'y'all got any more of those drivers for CD/DVD?' error).

During the next iteration of this investigation , I will check out the link provided by Wonko first. However, after a quick look it seems that link proposes changing partition flags/settings (I'm probably wrong) as opposed to mounting it as it is (which is not acceptable).

Thank you very much again. 1 day with you guys got me further than a week on SuperUser (and numerous days of investigation on my own) .

Attached Files

Thank you guys for all your detailed replies, I have troubleshooted the previous error using note about grldr.

The issue was that this utility simply thought it would be a good idea to put grldr and its files on FIRST partition (WHY??!11 it's not boot volume, its not distinguished by anything, sorry for failing to see that earlier) and my .iso and all files on SECOND (that's what I pointed it at, that's why I never knew there would be grldr in the first place, there was only bootmgr).

Boot files go to the primary partition, that's on purpose, some BIOS-es have troubles reading beyond certain boundary. Rest of the files go to the selected partition.

In addition- there has to be a "main" partition to hold those boot files + the main grub4dos config file menu.lst, first one is a reasonable choice, for the above reasons.

For now, second issue remains. This whole setup does not work from hidden partition

When do you like to unhide the partition? At boot time, when Setup is loaded, never?

What is the goal here, I don't get it.

However, after a quick look it seems that link proposes changing partition flags/settings (I'm probably wrong) as opposed to mounting it as it is (which is not acceptable).

Why not acceptable? For you or impossible to implement? mnt.exe can mount hidden partitions. You can find it cab compressed in <WinSetupFromUSB>\files\winsetup\

Just changed partiton type of the second partition on the same USB disk from 07 to 17 using PTEdit32 and replugged it. Next :

MNT.EXE P: \Device\Harddisk1\Partition2

and the partition is accessible. That's under XP, not tested under Vista and other.

And - as a side note - grub4dos deals fine with "hidden" partitions, finding both grldr and menu.lst without issues on them.

If I recall correctly (the mentioned thread is over 4 years old), the difference between good ol' mnt.exe and the other mentioned tools is that these latter ones are "automagic" i.e. they need not to be supplied "exact" parameters , so for one that would like to have a --force-all parameter, mnt.exe is a better advise .

For the record, mnt.exe is an old tool, by Christoph H. Hochstaetter, dating back to 1995 (a clear sign on how recent Windows versions are very different from NT 3.51/4.00 ), and ilko posted some ideas on how to use it here:

So I am now trying to get the drives to show. Regarding the issue itself - programs like showdrive and MountStorPE and even mnt are exactly what I want: do not change partition itself, just mount it.

Now I have tested 3 versions of showdrive and 1 MountStorPE. They all (except 1 version of showdrive but who cares) work fine on my Windows machine.

They don't work on WinPE I'm using because it's 64bit (ah, crap) and is missing WOW64 (shows 'missing subsystem to open image'). Who knew..

Googling for the 64bit versions of those programs (as well as mnt.exe) did not yeild results (seems they are all from era of WinXP when no one really bothered with 64bit compatibility). Adding WOW64 to WinPE does not seem to be an easy process.

Now I have some programming knowledge, but I am not aware of any technique that would let me cross-compile a 32-bit executable to a 64-bit version from binary (de-compile and re-compile again? not sure if even possible for such a specific app)

So I am now trying to get the drives to show. Regarding the issue itself - programs like showdrive and MountStorPE and even mnt are exactly what I want: do not change partition itself, just mount it.

Good, as expected

Adding WOW64 to WinPE does not seem to be an easy process.

Said by someone attempting to re-invent the wheel it is preoccupying .As a matter of fact it is not particularly difficult, as it has been done in several PE projects, besides the nice wimb's thingies , like:http://reboot.pro/to...drive/?p=166821

Now I have some programming knowledge, but I am not aware of any technique that would let me cross-compile a 32-bit executable to a 64-bit version from binary (de-compile and re-compile again? not sure if even possible for such a specific app)

Am I missing something?

No/yes. Decompiling a binary and compiling the thus obtained "source" to 64 bit might be more difficult than plainly take the mnt.exe sources (that are included) and modify them for x64 or maybe easier get the .au3 that JFX kindly posted on the mentioned thread (as mount.zip):http://reboot.pro/to...ge-2#entry88887

Looking at the original objective, direct from ISO can be done using E2B, but because you are using a 'Fixed disk' type of USB Flash drive, you will also need a small 'Removable type' Helper USB Flash drive connected at the same time.

If you are prepared to drop the 'direct from ISO' requirement, you can use E2B to boot from any Win Vista/7/8 Installer in either UEFI mode or MBR mode using E2B and a partition image.

1. Run the MakePartImage.cmd script and convert your Windows Install ISO file into a .imgPTN file - this only takes a minute or so.

2. Copy the .imgPTN file to your E2B drive

3. Run WinContig on the E2B drive to ensure the file is contiguous (use RMPrepUSB - Ctrl+F2)

Rinse and repeat for every Windows Install ISO you have (Vista and later OS's).

Now you can MBR or UEFI boot from any of these partition images.

P.S. You can also boot linux liveDVDs in the same way (UEFI or MBR boot).

As far as I understood it involves attaching some custom PE to my (any one that I will have) .iso image which is not desirable. Additionally, I have tried using WinBuilder once (it seems that WinBuilder is needed to build that PE) aaaaaand... frankly, I have not understood a god damned thing . I understand that it uses some scripts to try and make a .wim image with special custom properties.. maybe .

Also it seems newer WinBuilder is available which has CLI-only interface and it's not making it any easier .

The alternative installer (WInNTSetup) is already being considered for testing.

Good, as expected
Said by someone attempting to re-invent the wheel it is preoccupying .
As a matter of fact it is not particularly difficult, as it has been done in several PE projects, besides the nice wimb's thingies , like:http://reboot.pro/to...drive/?p=166821

No/yes.
Decompiling a binary and compiling the thus obtained "source" to 64 bit might be more difficult than plainly take the mnt.exe sources (that are included) and modify them for x64 or maybe easier get the .au3 that JFX kindly posted on the mentioned thread (as mount.zip):http://reboot.pro/to...ge-2#entry88887

and "convert it" to x64 or to C, C+ etc. (whatever suits you).

Wonko

So I thought..

I have looked at the script which adds WOW64. The problem with it is that it needs WinBuilder which I am trying to avoid for reasons outlined above (it's hard for me to use and I think it will also be hard for someone who will look at the resulting guide which I'll make, it seems unnecessarily complex for this task).

I also looked at mnt's sources. It doesn't seem to be a complicated program though I have yet to understand how exactly does it achieve mounting partitions.

Last I have looked at AutoIt file. AutoIt seems to be one of the most appropriate solutions because it has appropriate 64-bit switch..

But..

Two of the above can be (re-)compiled for 64 bit usage (which is good since I at least know how to do that) but they both have to be altered (meaning I have to rework them not to accept any arguments and mount all partitions which I am not sure how to achieve besides brute-forcing all possible letters and device nodes in system)

I have not had any luck de-compiling ShowDrive or MounStorPE and their sources do not seem to be available anywhere (which is strange).

Srsly, ain't there a 64 bit wheel available? Never thought I'd have a problem with executable compilation settings . Being so close to the fully working solution yet so far from it really gets to me .

Looking at the original objective, direct from ISO can be done using E2B, but because you are using a 'Fixed disk' type of USB Flash drive, you will also need a small 'Removable type' Helper USB Flash drive connected at the same time.

If you are prepared to drop the 'direct from ISO' requirement, you can use E2B to boot from any Win Vista/7/8 Installer in either UEFI mode or MBR mode using E2B and a partition image.

1. Run the MakePartImage.cmd script and convert your Windows Install ISO file into a .imgPTN file - this only takes a minute or so.

2. Copy the .imgPTN file to your E2B drive

3. Run WinContig on the E2B drive to ensure the file is contiguous (use RMPrepUSB - Ctrl+F2)

Rinse and repeat for every Windows Install ISO you have (Vista and later OS's).

Now you can MBR or UEFI boot from any of these partition images.

P.S. You can also boot linux liveDVDs in the same way (UEFI or MBR boot).

Now this seems tempting except the helper drive (which is completely unacceptable because this project aims to be as portable and fool-proof as possible when ready). Thank you very much for the suggestion, I'll keep that in mind.

So with that all said, best options right now seem to be (in order of complexity):

Find a program which does same thing as showdrive but is 64-bit compatible and be done with it.

Find a way to add WOW64 (which consists of few registry keys and few dlls as I understood) to an already built .wim.

Find a way to re-write mnt or Mount.au3 to be able to handle all available drives without targeting.

Find and attach non-customized 32-bit PE to my .iso. This is the least desirable alternative.

There are others already outlined before but I think it would be better to stick with those for now. Not sure if all (or some) of them are even possible.

Thanks for the replies. Also, I apologize for the delay, it seems I started this investigation at the least appropriate time in my life.

So I am now trying to get the drives to show. Regarding the issue itself - programs like showdrive and MountStorPE and even mnt are exactly what I want: do not change partition itself, just mount it.

Now I have tested 3 versions of showdrive and 1 MountStorPE. They all (except 1 version of showdrive but who cares) work fine on my Windows machine.

They don't work on WinPE I'm using because it's 64bit (ah, crap) and is missing WOW64 (shows 'missing subsystem to open image'). Who knew..

Googling for the 64bit versions of those programs (as well as mnt.exe) did not yeild results (seems they are all from era of WinXP when no one really bothered with 64bit compatibility). Adding WOW64 to WinPE does not seem to be an easy process.

Now I have some programming knowledge, but I am not aware of any technique that would let me cross-compile a 32-bit executable to a 64-bit version from binary (de-compile and re-compile again? not sure if even possible for such a specific app)

Am I missing something?

Thank you.

About mount and umount on x64, note that vmount will do it (next to vhd support) on x32 and x64 machines :