boot.wim error

[Ulaiphur]

I applied boot pe and boot setup. Captured them using the options: compress /maximum /verify and /norpfix. I also added the /boot parameter for the boot pe image.

And I'm getting the error:

"Windows pe cannot start because the actual SYSTEMROOT directory (x:windows) is different from the configured one (X:$windows.~bt\windows).

Please help.

Thank you.

[JFX]

Giving exact commands used would be easier to know what's happen.

Seems the boot index is wrong, the winpe index 1 is not suppose to run from WIM Ramboot.

Change the index to boot the "setup" image:

imagex -info boot.wim -boot 2

Edited February 12, 2012 by JFX

[Ulaiphur]

First I captured the boot pe image with this command:

imagex /capture H:\s2 H:\s1\sources\bootpe.wim "Microsoft Windows PE (x86)" "Microsoft Windows PE (x86)" /boot /compress maximum /verify /norpfix

Then, I captured the boot setup image with this command:

imagex /capture H:\s2 H:\s1\sources\bootsetup.wim "Microsoft Windows Setup (x86)" "Microsoft Windows Setup (x86)" /compress maximum /verify /norpfix

At finally I exported bootsetup.wim to bootpe.wim:

imagex /export H:\s1\sources\bootsetup.wim 1 H:\s1\sources\bootpe.wim "Microsoft Windows Setup (x86)" /compress maximum

[Kullenen_Ask]

If you make

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE_00\Microsoft\Windows NT\CurrentVersion\WinPE]
"Version"="3.0"
"InstRoot"="X:\\"

[HKEY_LOCAL_MACHINE\SOFTWARE_00\Microsoft\Windows NT\CurrentVersion]
"SystemRoot"="X:\\Windows"

everything will be OK.

[JFX]

At finally I exported bootsetup.wim to bootpe.wim:

imagex /export H:\s1\sources\bootsetup.wim 1 H:\s1\sources\bootpe.wim "Microsoft Windows Setup (x86)" /compress maximum

This was wrong, right would have been:

imagex /export H:\s1\sources\bootsetup.wim 1 H:\s1\sources\bootpe.wim "Microsoft Windows Setup (x86)" -boot

to fix this simply use

imagex -info H:\s1\sources\bootpe.wim -boot 2

@Kullenen

how does this affect all the pathes inside HKLM\Classes? Will they be auto adjusted during boot or still point to the old location ((X:$windows.~bt\window) ?

[Kullenen_Ask]

I did not had any problem.

"Windows pe cannot start because the actual SYSTEMROOT directory (x:windows)"

this one corresponds to

[HKEY_LOCAL_MACHINE\SOFTWARE_00\Microsoft\Windows NT\CurrentVersion\WinPE]
"Version"="3.0"
"InstRoot"="X:\\"

and

"is different from the configured one (X:$windows.~bt\windows)." corresponds to

[HKEY_LOCAL_MACHINE\SOFTWARE_00\Microsoft\Windows NT\CurrentVersion]
"SystemRoot"="X:\\Windows"

in same manner

X:\\ --> X:$windows.~bt

X:\\Windows --> X:$windows.~bt\windows

can work. i did not test. it will be closer to original.

[Ulaiphur]

Thanks for the help guys. I'll try them ASAP.

@Kullenen_Ask

But I am curious as to where do I find the "HKEY_LOCAL_MACHINE\SOFTWARE_00\Microsoft\Windows NT\CurrentVersion" key. Is it in the SOFTWARE hive of the boot pe image?

@JFX

What is the "-boot" parameter? I haven't been able to find any information about it.

LE: It works with the -boot parameter

Edited February 13, 2012 by AlexCeed

[Kullenen_Ask]

Yes it is.

[daremo]

For the boot.wim (winpe ramdisk image), you need to use DISM utility-

First, mount the boot.wim-

Dism /Mount-Wim /WimFile:

D:\data\boot.wim

/index:

1

/MountDir:

D:\data\tmpWimMount

which mounts the boot.wim file (located at D:\data\ folder) to a new folder (D:\data\tmpWimMount)

Then ask for PE environment settings-

Dism /image:

D:\data\tmpWimMount

/Get-PESettings

One of these information displayed is the windows root directory (such as "X:$windows.~bt\windows")

Alternatively, you can also get the Windows Root Directory information directly by issuing the following command-

Dism /image:

D:\data\tmpWimMount

/Get-TargetPath

You can reset the root directory to something you want. Most of the time, for custom WinPE, and especially when building Win7PESE via winbuilder, or for LastOS custom PE via the lastos builder, you need to set the windows root directory to "X:\". You must issue-

Dism /image:

D:\data\tmpWimMount

/Set-TargetPath:

X:\

As an aside, there are some registry hacks you can perform, (this is especially useful for INSTALL.WIM inside a VHD, but also applicable to boot.wim and any VHD in general). While the boot.wim file is mounted, you can load the registry hives of boot.wim, and change the following settings to prevent use of a pagefile and automatic expansion of vhd files (these registry hacks can be handy if you have enough RAM and do not want a pagefile, and when you use boot.wim inside a VHD, especially inside a dynamic VHD)-

First you must load the SYSTEM hive of boot.wim from the mounted folder-

run REGEDIT,

click on hklm root,

from File menu, choose load

browse to the mount folder where boot.wim is mounted; you need to go to the mounted folder, and search the "D:\data\tmpWimMount\windows\system32\config" folder for the "SYSTEM" hive

When asked, give the external SYSTEM hive a name such as "_w7_bootwim_sys"

The external SYSTEM hive (of boot.wim) will be loaded below the HKLM, as follows-

HKLM\_w7_bootwim_sys\.......

Hack-1: Prevent automatic expansion of a VHD file-

HKEY_LOCAL_MACHINE\_w7_bootwim_sys\ControlSet001\services\FsDepends\Parameters

Browse to the following key:

VirtualDiskExpandOnMount

change the setting to a value of 4.

(If there's more than one "ControlSetxxx", perform the same hack on each of them for the "FsDepends" service!!!)

Hack-2: Prevent creation of a Pagefile-

HKEY_LOCAL_MACHINE\_w7_bootwim_sys\ControlSet\Control\Session Manager\Memory Management

Browse to the following key:

PagingFiles

and remove the values.

(If there's no "ControlSet", but more than one "ControlSetxxx", perform the same hack on each of the "ControlSet00x", by locating the "Session Manager\Memory Management" and PagingFiles key!!!)

PS: see further below for further manipulation of boot.wim (or install.wim as needed) to inject drivers in the section "Addendum- Inject boot drivers"

Finally, you have to commit the changes and unmount the boot.wim image-

Dism /Unmount-Wim /MountDir:

D:\data\tmpWimMount

/commit

Usually, in boot.wim file there are 2 images; first image (index=1) is the windows PE environment, and the second image (index=2) is the Windows Setup. (Important! index-2, windows setup files have nothing to do with windows OS files used for actually installing/configuring windows, which are actually located inside the install.wim file! The Windows Setup (index-2) in boot.wim refers to the initial installer that comes on screen after the system is booted with windows PE , and later, this setup calls and installs the OS from install.wim)

NOTE:

You have to do windows root directory assignment ONLY on index-1 image file in boot.wim image.

Because boot.wim index-2 is NOT winPE! and the DISM winPe servicing commands do not work on that image!

False. It is a custom winpe with setup packages preinstalled in it and winpe servicing commands works on it.

CORRECTION!!!

(Added by Daremo on 27-feb-2012 as a result of notice by Kullenenask - see above quotes!)

:

Based on the above correction, you should mount boot.wim

index-2 image

and

repeat the operations

outlined for ndex-1 on the index-2 as well!

If you want to make sure your boot.wim file has the smallest size, you can export it to a new boot.wim file (which actually, cleans up and optimizes the contents of the boot.wim file)-

the syntax is:

imagex /export <src_file> <src_number> <dest_file> /compress [maximum | fast | none]

<src_file>: the source wim file, in this case "D:\data\boot.wim"

<src_file>: image index no, you can either use "1" here, because that was the image index you worked with, or use "*" so that all the images inside boot.wim are exported. Event though I may not use the index-2 contents (windows initial setup app) in a boot.wim, I usually use "*" as "src_number" while exporting!

<dest_file>: is the new boot.wim file. As an example, I'll use "D:\data\NEW_boot.wim"

imagex /export

D:\data\boot.wim

*

D:\data\NEW_boot.wim

/compress

maximum

Note: You can delete the old boot.wim file and rename New_boot.wim to boot.wim

Addendum- Inject boot drivers

If you have access to driver packs (from driverpack.net), you can inject some neded drivers for boot-time, especially for WinPE (i.e. boot.wim image index=1).

Download at least the chipset and mass storage driver packs, and extract the contents into a folder. It doesn't add too much to the size of the wim file, and if you want to reduce the size of boot.wim and injection process time, you can browse through the unzipped folders, and remove the unwanted drivers. Personally, for mass storage, I only need all the various AMD, Intel, Jmicron, LSI, and VIA storage drivers... I don't need the Areca, or Marvell, or ITE, or whatever... you know what I mean? Same thing with chipset drivers; definitely the ATI and NVidia, and a few others to keep, and rest to remove! As long as I know the general manufacturer of the motherboards and video cards of my PCs and laptops, etc., I remove the rest!!!

As an example I have unzipped the contents of the two driver packs to D:\data\drv\ as follows-

D:\data\drv\

DP_Chipset_wnt6-x86_1202\x86

D:\data\drv\

DP_MassStorage_wnt6-x86_1202\x86

So, now I can start injecting them into boot.wim-

DISM.exe /image:

D:\data\tmpWimMount

/Add-Driver /driver:

D:\data\drv

/recurse /

ForceUnsigned

Note: you can remove the /ForceUnsigned option out if you don't want to use unsigned drivers!!!

This may take some time, but eventually it will finish processing. Since the image is manipulated extensively, you should probably commit and unmount the image, and then export it to a clean, new wim file with maximum compression, so that your new wim image is ready for use.

If you also have time, you can inject the same DRV folder contents into your install.wim file, so that at least mass storage and chipset drivers are available when installing your OS.

Edited February 27, 2012 by daremo

[Kullenen_Ask]

Woow very impressive. "NOTE:You have to do windows root directory assignment ONLY on index-1 image file in boot.wim image." should be true. Because mostly i have that error when i try to make a winpe from index 1 image. If command "Dism /image:D:\data\tmpWimMount /Set-TargetPath:X:\" works it will make everything very easy.

[daremo]

Woow very impressive. "NOTE:You have to do windows root directory assignment ONLY on index-1 image file in boot.wim image." should be true. Because mostly i have that error when i try to make a winpe from index 1 image. If command "Dism /image:D:\data\tmpWimMount /Set-TargetPath:X:\" works it will make everything very easy.

As I mentioned, the only winpe image is index=1. The index=2 image is for windows initial setup application (the one that presents you with the windows 7 install screen asking about keyboard, etc, and agreement to terms of use, and then moves onto selecting disk for use to install the OS!)

Also you can test the DISM /Get-pe environment info or get target folder commands with index=2, and you will see that the commands give error messages. Why? Because boot.wim index-2 is NOT winPE! and the DISM winPe servicing commands do not work on that image! (see below the comments and corrections as indicated!)

Because boot.wim index-2 is NOT winPE! and the DISM winPe servicing commands do not work on that image!

False. It is a custom winpe with setup packages preinstalled in it and winpe servicing commands works on it.

Thanks Kullene_Ask!

CORRECTION (as per above quoted messages):

Boot.wim index-2 is a WINPE environment also, and the DISM

/Get-PESettings

or

/Get- /Set- Target Path

commands work on the

index-2 image

as well, and should be used to specify the System Root Directory (usually

X:\

for a custom winpe being built...)

The same WINPE Servicing commands do NOT work on the install.wim (with any index number), as none of the images within install.wim are winpe! Boot.wim index-1 and index-2 images are winpe and DISM winPE servicing commands work on both!

This definitely solves it. Personally tested it out when I was busy working with Win7PESE and LastOS builds using Winbuilder (v0.82) a few days ago. The first builds had the error, "expecting X:\ for system root... system root is windows~bt...." message (or something similar to that effect). Googling for the problem revealed you can solve it with registry hacks, and one MS technet article talked about DISM switches related to servicing WinPE images (such as Get PE environment, Get/Set Target Path, and so on), thus is the solution.

The next builds worked flawlessly after pre-modifying/readying boot.wim with DISM.

As an aside (and a tip), I prefer to do some of the stuff winbuilder does, manually myself (such as injecting mass storage, chipset drivers, and regisstry hacks) before delivering the boot.wim for use with winbuilder, and then in winbuilder, I set the boot time and other driver injectionfolders (and options) EMPTY, so that I have precise control over the build process. Assuming you are using win7, another nifty trick to perform befre using winbuilder is to extact the contents of WIM files to 2 separate VHD files (eg. boot_wim.VHD, and install_wim.VHD) using Imagex /apply command. Then create a differencing disk for each vhd (boot-diff.vhd, install-diff.vhd) file and mount the differencing VHD files in Disk manager to directories (instead of assigning drive letters). Start winbuilder, and ask it to use Extracted contents of wim files, and point the relevant directories (for "extracted content of boot.wim file and install.wim file") to the relevant folders where the DIFF.vhd files are mounted at!

Why?

There are several advantages:

1. Original content of boot-wim.vhd and install-wim.VHD file are NOT modified and they are available anytime you need them.

2. Any modification of content done (by winbuilder or any process) on the boot-wim.vhd and install-wim.vhd is done on the differencing disks and when not needed you can delete the existing differencing disks after use, and if need be recreate new differencing disks and mount them for use with winbuilder for any new builds you work on.

3. If you have more than one physical disk and disk controllers, you can obtain good performance by putting the vhd files on different disks (and partitions). The best procedure is:

create a fixed type VHD for each wim file,

defrag the physical disk (or partition) where the VHD files reside

Mount the VHD files with drive letters assigned

Defrag the VHD files (since they will be available in a defragger with their assigned drive letters

Since the parent VHD files are of fixed size and the vhd file itself is defragged, it is allocated a contiguous and fixed location on the physical disk. The inside contents of the VHD file is also defragged, so any read write operations go to always the same physical sectors (this is not eactly correct, but close enough as an approximation of the idea)

Dismount/detach the parent VHDs.

Now, create 2 differencing VHD files (child VHDs) on another physical drive (and hopefully attached to a different disk controller), and mount them into empty folders!

The position and references to the contents of a parent VHD are kind of fixed. So any modification to be made on the parent VHD, happens on the child VHD, so the parent VHD will not change. Another point (from performance point of view) is that the work done on parent VHD will always be a Read operation, whereas on the child VHDs, a read/write operation may be performed, and hopefully the R/W operations are performed through another disk controller if the child VHDs reside on a physical disk with a separate disk controller! :-)

4. An advantage of working with extracted contents of WIM files, is that Winbuider functions faster because you can select (within winbuider) to work with extracted wim file contents. So, winbuilder doesn't need to use dism or other utility to first mount a wim file to work with the contents of the wim file, so use of VHDs mounted to empty folders work quite nicely.

Besides (and this is important), if something goes wrong with winbuilder while unmounting a wim file, you will have a hell of a time to remove the temporary folder where a wim file has been mounted by winbuilder. I had to mvoe many files from one partition to another, and then had to forcefully format a partition one time due to this kind of problem (frozen/failed unmount operation when winbuilder was running). So, it is in fact easier to dismount and delete a differencing disk and recreate the differencing disk to attempt winbuild again! :-)

5. Eventually you can use the existing VHD files and their contents by transferring them to a physical partition and set up your PC or using the VHDs themselves in VMs (with hyper-V or virtual PC (or any other virtualization product that accepts VHD files) for testing purposes or use them to Native VHD boot for installations!

6. You can also use an empty VHD file (attached with a drive letter and formatted) for winbuilder to use as the destination-USB-drive, and instead of the ISO file creation, ask winbuilder to direct the USB creation operation to the new VHD file. Later you an transfer the contents to a USB flash disk, or just use the VHD file itself as native VHD boot drive, or within a virtualization product for testing! :-)

Do I need to say it? OK!, Personally, I find VHDs a lot handy, and flexible, much more useful than ISO images or USB drives :-)

Edited February 27, 2012 by daremo

[jaclaz]

Do I need to say it? OK!, Personally, I find VHDs a lot handy, and flexible, much more useful than ISO images or USB drives :-)

Though I can see an interesting use of USB drives, as the PC's I have do not have a port/connector to which I can connect a VHD.

jaclaz

[Kullenen_Ask]

Because boot.wim index-2 is NOT winPE! and the DISM winPe servicing commands do not work on that image!

False. It is a custom winpe with setup packages preinstalled in it and winpe servicing commands works on it.

[daremo]

Because boot.wim index-2 is NOT winPE! and the DISM winPe servicing commands do not work on that image!

False. It is a custom winpe with setup packages preinstalled in it and winpe servicing commands works on it.

DARN! Sorry! :-) I stand corrected. I was too quick to browse through my notes while I was writing that message I posted. I mixed it up with the Install.wim file. WinPE servicing commands do not work on install.wim.

I will edit and put the corrections on my previous two posts for boot.wim dism servicing comands section!

[daremo]

Though I can see an interesting use of USB drives, as the PC's I have do not have a port/connector to which I can connect a VHD.

jaclaz

LOL.... Point taken, but think of the following two issues (and I believe the points 2, 3, and 5 especially address the "VHD Port" you mentioned so tounge-in-cheek manner <LOL, vhd-port inded!!!>, and the rest addresses other issues and presents some advantage of one form or another):

1. USB port speed, limits and slows your boot up time and getting a mobile/portable win(pe) OS running from the USB disk, especially compared to intern HD speeds when a native VHD boot is used, or even working with a VHD within a virtualization product such as Virtual PC, Hyper-V, etc.

2. Again on speed issue... You can mount a VHD on a PC, share the drive over network, and access contents from another PC, and I believe file transfer speed over the network still beats USB file transfer speeds!

As variation to the idea, you can also set up tftp servers or even use Apache (for windows for example) and make the contents of a VHD available via http protocol by publishing the VHD drive by mounting it to a public folder in Apache... there are many other creative ideas, variations with similar themes...

3. You have to jump through several hops (depending on your hardware and its abilities) to configure your USB correctly, and be able to boot, and if you have a quirky BIOS... well... :-)

4. Size limit is no concern; you are only limited by the free space on your HD, and the max VHD you can create!

5. VHD is a bit of a software solution, together with a bootmanager (win7 bootmgr), and circumvents hardware related issues and all the jumps and hops of prepping a usb disk

6. If you are using hyper-V, there's no support for USB (and I guess I'm a bit biased, because I work a lot with hyper-V based VMs), so USB is a definitely NO - NO for me. A workaround the issues of attaching/detaching a USB drive online (i.e. hotswab drive) while a VM is running, is to use a VHD file and attach it as SCSII HD in the VM setting/configuration or create an ISO image and insert/eject the ISO image in the VM configuration. The problem with ISO images is that, first you have to go thorugh full modification / creation process when you need to update or modify the contents before attaching it to a VM. Second, virtual CD/DVD drives are available as IDE devices within Hyper-V VMs, and thee's a limit on the number of simultaneous ISO images you can attach. In contrast a VHD can be quickly created (especially if you use the VHDTOOL v2), conents injected into the VHD, and updated easily, and the resulting VHD can be attached/detached to a running VM via the SCSII HD settings, and you can add quite many VHDs as SCSII HD.

7. If you are working with extracted contents of an installation set, such as install.wim, the data/content size can be a real isssue with USB, as well as speed. VHDs (and ideas in points 2 and 5) can help in this regard. Besides, you can also pre-create and populate individual VHD files with portable applications and specific driver pack sets, and once you are in a winpe environment, attach the VHDs via diskpart, and make use of drivers and portable apps (even in your normal win 7 environment). This helps keeping drivers and apps separate, modular, and neat, as you only need to edit the contents of individual VHDs to keep them up-to-date. Yes, you can set up folders on your physical drive for the same puposes, but if you have multiple OSes on your PC, you can make use of differencing VHDs (child VHD for each parent VHD where a parent VHD is a driver pack or portable application or even data environment) so that each OS receives a custom differencing disk with only modifications written to the differencing disk, while you keep/maintain an unmodified master VHD (parent VHD) as the starting point/root for different situations. VHDs offer an unprecedented flexibility. I like the ability to use streamlined/job specific OS + App environment rather than all the apps available within my OS.

Anyways... I agree that USB is needed, but if I can get away from USB, and do it with some kind of gain in some aspect of an operation, I will go for it! :-)