Extract Boot.wim From Iso

[Prospero Barela]

I am currently learning windows 10 deploy. I have Microsoft Deployment toolkit update 2013 update 1 installed. When I try to import operating system, system tell me can not find install.wim in windows sources. I did some research found out that current windows 10 home/pro installation media comes with install.esd instead install.wim. Is there anyone know to to extract install.wim from install.esd. I have looked at few ways online, none of them working.

You can get the WIM file from any media other than the Media Creation Tool download (or Windows Update). You could also use the Media Creation Tool installation media on a virtual machine and then Sysprep and capture from that VM.

And that is very different from what MrAdam has posted and is also roughly how I have attempted to get this done up until this point without success (however I was using rufus to write the ISO). Does MrAdam have a guide for his method at all? I am attempting to create a WinPE environment with WAIK and it is failing to extract files (most notably the WinPE.wim) to the root of C: via the following command: CopyPE.cmd amd64 C:\WinPE_amd64 from this page here:

I've been trying to create a bootable CD/DVD/ISO from a bootable USB flash drive. Google search brought me to try using ImgBurn for this, so I downloaded and installed, it, but it doesn't seem to work in this case.

Just to be clear, I'm trying to create a bootable CD with the Seagate "SeaTools Bootable" package , so I can run hard drive diagnostics. No, Seagate does NOT have a downloadable ISO on their web site -- at least not that I can find. Instead, you download a windows executable, which will format your flash drive and copy all the utilities onto it. This flash drive boots up fine on multiple boxes that I've tried. I thought it should be relatively easy to convert this to a bootable CD. Boy, was I wrong about that.

As I say, this DOES NOT WORK. ImgBurn says is successfully created the ISO and there are no errors messages (log attached), but the resulting ISO is not bootable. If I try to boot it, I just get "Missing operating system". I spent several hours and burned a bunch of useless coasters trying different variations: different sized flash drives, different media, CD versus DVD, trying to boot different computers, different optical drives, trying to boot Virtual Box with the ISO, etc. Nothing worked. Always the same result: "Missing operating system".

Digging down, I found that what the ImgBurn "Extract Boot Image" function does is, it makes a binary copy of the FAT32 partition on the flash drive, but it does not read the MBR (master boot record) from the flash drive. The .ima file produced is a binary disk image, but ImgBurn prepends it's own MBR boot code and creates a partition table in the image de novo. (Background: hard drives are formatted with an MBR at sector 0 which contains the partition table, and -- optionally, if the drive is bootable -- some bootstrap code in bytes 0x0 thu 0x1BD of that sector.) Examining the MBR that ImgBurn writes to the .ima file, the only thing I noticed that seemed off was that the field for the "number of sectors in the partition" in the partition table entry was wrong (see _boot_record#PTE). The number there was the LBA or sector number of the end of the partition, i.e. the start sector plus the size, instead of just the size. This really shouldn't matter; I don't think the bootstrap code looks at that field. In any case it wasn't causing the failure.

When ImgBurn creates the ISO, it does a binary copy of the .ima disc image into the ISO file, without modifying it. Those bytes are stored contiguously in the .iso file, and it's relatively easy to find the location. (In my case, it was always at offset 0x81000.) I verified that the MBR with it's bootstrap code hadn't somehow gotten mangled in that step.

I have some code I wrote a while back to read the MBR of a hard drive or flash drive (actually, the entire "hidden" system area from sector 0 to the start of the FAT partition) and write that to a file. This is how I know that the MBR that ImgBurn writes to the .ima isn't the same.

I used Visual Studio Community Edition's binary editor to open up the ISO file, and copy bytes 0x0 thru 0x1bd from the flash's MBR to the MBR image at offset 0x81000 of the ISO. And that worked! Now the ISO produces a CD that actually is bootable! (Well, OK, it doesn't boot successfully everywhere, but it does boot up on the system I wanted to used it for. And in none of the failure cases am I getting the "missing operating system" error anymore, so those failures must be some other problem. A problem with the payload, not the ISO creation process.)

I don't know why ImgBurn is ignoring the correct (at least in my case) bootstrap code from the source drive and substituting it's own. I assume there I some reason for this. But the boot code that ImgBurn provides is obviously not robust enough to work with any operating system. (The Seagate tools use SYSLINUX and something called "Tiny Core Linux".)

You said you're trying to create an ISO from files from a bootable flash drive with ImgBurn? ImgBurn doesn't support bootable flash drives for boot images as far as I know. So, even if you extracted the boot image from a bootable flash drive, copied over the contents from the flash drive, and created an ISO, I don't think it would work. LUK might know some bootable settings to change to do this, but as far as I know, this won't work.

Regarding the program, I don't think anything other than floppy and optical drives have really been used / tested with the extract boot image stuff - although I guess at the time of implementation, I must have done something or the code wouldn't exist at all.

The program doesn't actually dump the entire drive, it only dumps the partition (corresponding to the drive letter) you select - partition is specifically mentioned in the message box that pops up. So that's why the MBR is different to that of the actual drive, it doesn't read the one on the physical drive - It has its own within the code... one from MS I guess, as that's what I'm running.

Thank you for reporting the issue with the partition's 'number of sectors' field in the partition table. I was using a variable containing the size of the entire boot image rather than just the size of the partition. That has now been corrected.

Actually, there shouldn't be any problem with reading the entire physical drive, or just the MBR. As I said above, I wrote code to do that a long time ago. (I wanted create backup copies of hard drive partition tables after having been burned too often by partition utilities -- Partition Magic; Windows disc manager -- corrupting the partition tables.) If ImgBurn is doing a direct binary copy of the entire partition, I'm guessing you're running with sufficient privileges to access the rest of the drive as well.

I'm guessing the MBR you insert was written to work with some versions of Windows pre-execution environment, but short of disassembling the bootstrap code I couldn't say specifically why it doesn't work with other OSes.

One experiment I did, which I omitted from my post, was to create an image file of the entire flash drive myself, and use that, but then ImgBurn complained that the signature of the MBR didn't match what it expected, so it went ahead and substituted it's own bootloader anyway. :-(

The warning about unknown signatures isn't an issue (for people that know their MBR is correct), it's just to give people a heads up that things might go wrong. Seeing that message doesn't substitute in the program's built in MBR, so if you extracted your own dump of a full physical disk, that's what you'd have ended up with in the ISO - unedited.

I was playing around with SeaTools on a 4GB stick yesterday doing various things and I couldn't get it to boot in vmware (at all), which is a shame. I guess I need to dig out a 2nd real machine to test it on - mine never really gets rebooted.

I didn't ever get a message about missing OS though, it just came up with a syslinux message and sat there forever. That was with an ISO made where I'd only fixed the 'number of sectors' issue and ISO's where the full physical drive was being dumped and used as the boot image. Maybe I should give VirtualBox a go too to see if it behaves differently.

Off topic, I know, but you actually had problems with Partition Magic? It was one of the few utilities that did what it did that I found that actually worked. I miss it tremendously, along with PowerQuest's Drive Image. DI was also the first utility of its kind I ever used that did what it did and did it well.

Yes, on the whole Partition Magic was a great utility and I used to use it a lot back in the day. To be fair I only recall it failing and corrupting the partition tables just once in many, many, uses. IIRC, the way PM worked was it would not actually execute your changes right away, but just keep them queued up until you told it to commit the changes to the disk. The one time I had problems, I decided that maybe I had accumulated too many changes for it to do all at once (delete this one, shrink that one, move this one, and then expand it...). After that incident, I was always careful do just one change at a time, commit it and then reboot, before making the next change. and never had a failure again.

Yeah, for whatever reason, when tasks are queued, there's a greater likelihood one task won't work for whatever reason. Plus, if one task doesn't complete, the rest of the queue is abandoned and you lose all the work you put into them. Hence, I learned a long time ago to just queue up 1 task at a time.

3a8082e126