Wimboot Won't Load System Image Recovery from Windows Repair

[vphoebe]

Hello all,

I currently have Wimboot 2.5.2 and the iPXE ISO set up to load the Windows Recovery Disk over our network. Wimboot loads up the disk just fine, but when trying to access the System Image Recovery tool, it throws an error 0x80070002, which says the system cannot find the file specified. If you try to run the actual program (bmrui.exe) in the command prompt on the disk, it gives the same error. Here is a screenshot: http://i.imgur.com/b50Bfye.png

Strangely, if you load the same files in their original ISO with MEMDISK, the function works as intended, so the files don't seem to be corrupted or wrong. Any ideas?

[NiKiZe]

I'd say that the ISO goes out the window as soon as the windows kernel takes over, and thus there is no files available from the emulated iso, but that is exactly what happens in the memdisk case, so we should be able to rule that out.

Maybe this can help us narrow down what the issue is: https://social.technet.microsoft.com/For...proinstall

One difference with wimboot is that it emulates a boot from harddrive which could affect how things are detected inside WinPE.
Most of this should be related to the BCD but not all.

[vphoebe]

Does wimboot require a custom prepared BCD to function properly, or will the standard one provided with the disk image be adequate?

[NiKiZe]

Any BCD that refers to the correct name of boot.sdi and boot.wim is sufficient. Minimal set I use can be found at: https://github.com/NiKiZe/wimboot-bcd (there is also script for generating the bcd with some explanations)

[vphoebe]

Okay, I downloaded your BCD, and I'm getting the same error. For what it's worth.

[NiKiZe]

Did you check the logfiles mentioned in that msdn post?

Can you post the script you are using? What is the source of the wim? (Win ver and bitness) And could you share your image?

[vphoebe]

The Panther directory where those logs are supposed to go doesn't exist, I think it puts it on a C drive once an installation has started. This is just a recovery disk so nothing is being installed. I can't find any logs that would provide any more info. My script is below.

Code:

#!ipxe

kernel tftpboot/wimboot
initrd images/recovery/boot/BCD BCD
initrd images/recovery/boot/boot.sdi boot.sdi
initrd images/recovery/sources/boot.wim boot.wim
boot

The WIM is stock taken right out of a 64-bit Windows 7 recovery iso from MSDN. Like I said, the same files work as an ISO in MEMDISK, so it can't be anything with the files. It must be something with how wimboot is emulating the ramdisk WinPE makes, and for some reason it can't find this file. Anyway, I tried to upload it here but it says it's too large.

[NiKiZe]

(2016-08-02 21:31)vphoebe Wrote:  The Panther directory where those logs are supposed to go doesn't exist, I think it puts it on a C drive once an installation has started. This is just a recovery disk so nothing is being installed. I can't find any logs that would provide any more info.

I have seen logs on the winpe virtual disks (when there is an issue during windows installation before the target partition is created) so I was hoping that maybe it was there, hmm.

(2016-08-02 21:31)vphoebe Wrote:  The WIM is stock taken right out of a 64-bit Windows 7 recovery iso from MSDN. Like I said, the same files work as an ISO in MEMDISK, so it can't be anything with the files. It must be something with how wimboot is emulating the ramdisk WinPE makes, and for some reason it can't find this file. Anyway, I tried to upload it here but it says it's too large.

I'd argue that the issue is with windows (not least so due to the "very verbose" error message ) but also how it interprets whatever it interprets from wimboot.

What wimboot does in legacy boot is to generate a minimal virtual FAT32 filesystem, and populates it with the files given to it and then chains into bootmgr (which it extracted from the wim if not given) from there it is bootmgr that loads the other files and does what it normally does. When the NT kernel is then started the pointers to the FAT fs is thrown out the window. ([url=http://ipxe.org/appnote/wimboot_architecture]wimboot details[/url})
So to me it seems to be bootmgr that does things differently between memdisk and wimboot load, those differences is probably in the registry somewhere.

We still don't know which file it can't find(?)

To find and create a workaround for this mcb30 probably needs to be able to reproduce the issue, I might be able to help and narrow down what is causing this, but can't say for sure. Maybe you have a link to MSDN?

[vphoebe]

The file it can't open is bmrui.exe, which is the System Image Recovery part of the Recovery disk. Trying to launch that is what throws the error. I don't have a link out to MSDN since you need a login to access it, but you can produce the same recovery image on Windows - you just have to burn it to a DVD first. It's just the standard Windows 7 recovery disk. It's weirdest of all because you can DIR the System32 folder and see all the files. You can even launch CMD (obviously) and regedit and all the other exe files in there, just not bmrui.exe. I know it just sounds like an image problem but I've tried WIMs from multiple clean downloads. I feel like something crazy just happened and I think I'm going to rebuild everything and start over.

Bmrui.exe should be in any Windows disk, so if you have any set up for wimboot, you can try it in your config and see if it launches.

[NiKiZe]

If i read it correctly bmrui.exe can actually start (the file does exists) but that in turn tries to find something that does not exist, and the name of whatever file that it does not find is not displayed?

What happens if you run "bmrui.exe /?"

Just for reference, are you running ipxe in EFI or legacy mode? and what kind of partition type do you have on the disk? (MBR/GPT)

[vphoebe]

So, the file exists and can be "run", but it just throws the error, as if the file isn't actually there. Maybe it is instantly going out to find another file that it can't reach, then throws the error. But the same thing happens if I add the /? flag. I'm using ipxe in legacy BIOS mode. I'm no longer using the ISO and instead set up chainloading, so now any PXE boot chainloads iPXE which then runs my script. Not sure what partition type it's using. Do you mean the disk on the computer?

Just found something interesting, it throws that error no matter where I try to run that file. Even though it shows up in DIR in X:\Windows\System32, I just accidentally tried to run it in X:\Windows and it threw the same error, even though the file isn't even in that folder. EDIT: Nevermind, that's just cause the System root is an environment variable.

[NiKiZe]

(as you noted) bmrui.exe is located in one of the directories that is in your PATH environment variable, meaning that no matter where you are and type bmrui that file will start (searched by the order of the path variable)

This is the same as with for example notepad.exe
So yes bmrui.exe does indeed exist no issue there, you can also see that from the title of the error dialog. So the question is what file it is bmrui.exe can't find.

To test you can try and run "doesnotexist.exe" and see what you get to compare.

I'm assuming this runs on a machine with a disk, with the intent of creating or restoring a image?

What is the partition type of the disk? if it is a GPT partition layout then most windows tools will refuse to work with it if you have started in Legacy. (and the other way around if you boot in EFI and try to do anything with a MBR partition layout) But on the other hand memdisk is Legacy as well so that shouldn't be the issue here.

[vphoebe]

The disk is MBR. It's already got Windows on it actually, it's just a spare. I've run it in a VM too with no disk and it does the same thing. Do you think there's anyway to analyze what file it's going after? Maybe there are different logs somewhere.

---

Alright, I've made some progress. If I use our USB key with the Windows recovery disk on it, I can reproduce the same error if I pull the USB drive out before trying to access that file. That means it's going back to the image (probably the boot.wim) to get more files. Wimboot doesn't mount the original media as a drive like it does with a USB key or MEMDISK.

[NiKiZe]

I find it really hard to believe that the original memdisk iso is still available from within windows. (you wrote boot.wim but the boot.wim contents is the x: and is fully available to you regardless of boot method)


Using Process Monitor it should be possible to see exactly which calls bmrui.exe does.

[vphoebe]

Here is a full filtered procmon log for it trying to run through wimboot. https://www.dropbox.com/s/x4zhwctfjngd2u...e.PML?dl=0

[NiKiZe]

Can't find anything that sticks out.
Comparing the output from working with the one that is failing to find differences might be the next step.

Did notice the access to X:\Windows\Logs\CompletePcRestore\ Maybe something can be found there.

Maybe also dumping what HKLM\System\CurrentControlSet\Control\SystemStartOptions contains in the two cases. (the log shows Buffer overflow lenth 144) but then succeeds with
MININT REDIRECT RDIMAGEOFFSET=8192 RDIMAGELENGTH=3161088 RDPATH=MULTI(0)DISK(0)RDISK(1)PARTITION(1)\SOURCES\BOOT.WIM

For reference a easily readable log: https://paste.fedoraproject.org/400963/61537147/ (tip: click wrap up in the corner)

[vphoebe]

Sorry it's been forever on this issue!! If you're still here, here's what I found between the two registries. This has to be the issue.

Booting from USB (and getting bmrui to load), these are a few registry keys in HKLM\System\CurrentControlSet\Control

Code:

"SystemStartOptions"=" MININT  REDIRECT RDIMAGEOFFSET=8192 RDIMAGELENGTH=3161088 RDPATH=MULTI(0)DISK(0)CDROM(0)\\SOURCES\\BOOT.WIM"

"SystemBootDevice"="ramdisk(0)"

"FirmwareBootDevice"="multi(0)disk(0)cdrom(0)"

and here's those keys from wimboot

Code:

"SystemStartOptions"=" MININT  REDIRECT RDIMAGEOFFSET=8192 RDIMAGELENGTH=3161088 RDPATH=MULTI(0)DISK(0)RDISK(0)PARTITION(1)\\SOURCES\\BOOT.WIM"

"SystemBootDevice"="ramdisk(0)"

"FirmwareBootDevice"="multi(0)disk(0)rdisk(0)partition(1)"

I'm thinking for some crazy reason it's trying to get back to the actual wim file (it's accessible when booting from USB), and it can't because wimboot doesn't mount the boot media as an accessible drive. Who knows why it needs to do this because obviously the wim is unpacked as the X drive.

[NiKiZe]

So for usb boot it shows cdrom as well?

(2016-08-12 16:35)vphoebe Wrote:  Booting from USB (and getting bmrui to load), these are a few registry keys in HKLM\System\CurrentControlSet\Control

Code:

"SystemStartOptions"=" MININT  REDIRECT RDIMAGEOFFSET=8192 RDIMAGELENGTH=3161088 RDPATH=MULTI(0)DISK(0)CDROM(0)\\SOURCES\\BOOT.WIM"
"FirmwareBootDevice"="multi(0)disk(0)cdrom(0)"

and here's those keys from wimboot

Code:

"SystemStartOptions"=" MININT  REDIRECT RDIMAGEOFFSET=8192 RDIMAGELENGTH=3161088 RDPATH=MULTI(0)DISK(0)RDISK(0)PARTITION(1)\\SOURCES\\BOOT.WIM"
"FirmwareBootDevice"="multi(0)disk(0)rdisk(0)partition(1)"

I'm thinking for some crazy reason it's trying to get back to the actual wim file (it's accessible when booting from USB), and it can't because wimboot doesn't mount the boot media as an accessible drive. Who knows why it needs to do this because obviously the wim is unpacked as the X drive.

The wim itself is likely irrelevant, but the boot partition is "cdrom(0)" vs "partition(1)" which bmrui likely uses to try and find other files it needs, or maybe just the existence. with wimboot the partition likely does not exist at all.

Could you test dumping the "cdrom" reg, and importing it into wimboot started, and then trying to run bmrui again, and see what it says.

Full logs of procmon when it fails (stopping the log when the error dialog is shown) and when it works, and then comparing the two logs should narrow down the possibilities.

[vphoebe]

It worked!! I was on a week vacation so I wasn't in to try it until now. If I import that key into the PXE booted PE, it works perfectly. Now to figure out how I can get it to permanently use that key instead of the one that doesn't work. I can edit the registry of the WIM offline, but it looks like it generates the CurrentControlSet on boot.

[NiKiZe]

(2016-08-23 15:07)vphoebe Wrote:  It worked!! I was on a week vacation so I wasn't in to try it until now. If I import that key into the PXE booted PE, it works perfectly. Now to figure out how I can get it to permanently use that key instead of the one that doesn't work. I can edit the registry of the WIM offline, but it looks like it generates the CurrentControlSet on boot.

Nice!
And yes CurrentControl and a lot of other things is populated on boot.
What you want to do is to use reg add, or reg import in a cmd file.

See startnet.cmd at https://technet.microsoft.com/en-us/libr...10%29.aspx