Jump to content


  • Posts

  • Joined

  • Last visited

  • Donations

    0.00 USD 
  • Country


Posts posted by daremo

  1. I think you can start by investigating the bcd store on the AIO DVD, and locate the entry that points to the dART environment. It most probably is a wim file (either boot.wim, or another small wim or winre file). Say it is boot.wim. Use dism to enumerate the images included in the boot.wim file, and check the descriptions, and one of them should be the dart image. you can then use dism to mount the image using its index, and make a standalone copy or place it on USB, or add it to your own boot.wim.

    Without having a copy of the AIO iso (i found a few of them on the torrentz, which specify dart included in the iso, but I am reluctant to make use of them), I cannot offer much more than the above outline.


  2. your problem is changing the active partition. When booting, bootloader needs to know on which partition the bcd store exists. You had initially set up a partition as active and created a BCD store, then you later change your active partition, and the system is unable to find the bcd store to load a system.

    If you are using a dedicated partition for BCD store (the reserved, "system" partition), then keep that partition as the active one at all times! You can always use a win7 dvd to boot into winpe, in case you have problems boting up the system. You cana lso use bcdedit to edit the existing bcd store on a partition.

    Making one partition active at one time then another partition active on other times, you will only create a mess of confusion unless you know what you are doing.

    Personally, I use grub4dos as bootloader, becase it gives me flexibility to direct a system to boot from specific partitions. I also create for each Windows installation on different primary partitions, a dedicated bcd store on the respective partition using bcdedit command. Then I use grub4dos to boot using the bootmgr and bcd store on the relevant partition to boot into the respective windows installation (on the relevant partition).

    C:\ Windows 7

    D:\ Windows 8


    Install grub4dos on the HD0. Create grub menu (menu.lst located on c:\grub) as follows:

    title win 7 (on hd0,0)

    root (hd0,0)

    chainloader (hd0,0)/bootmgr

    title win 8 (on hd0,1)

    root (hd0,1)

    chainloader (hd0,1)/bootmgr

    title Winpe (on hd0,2)

    root (hd0,2)

    chainloader (hd0,3)/bootmgr

    Ensure that relevant partition is set active, and install the relevant OS to the partition! You will end up with the 3 partitoons, 3 OS's, and each partition containing the BCD store for the respective OS. Then you install Grub4DOS, and make the menu.lst file, and when the system is booted you will be presented with a menu to select the OS to boot into! When you select the OS to boot, the corresponding partition is set active, and the system boots into the selected OS (using the bootmgr and bcd store stored on the corresponding partition!)

    If you check out following links for info:

    Windows PE Walktrhoughs (covers various ways of Winpe boot from CD/UFD/HD/etc.)- http://technet.microsoft.com/en-us/library/dd799278%28v=ws.10%29.aspx

    Scenario 3: Performing an Advanced Deployment of Native Boot VHDs- http://technet.microsoft.com/en-us/library/gg318055%28v=ws.10%29.aspx Although this covers a case of winpe partition, and a second partition containing 2 VHDs (win7 and win 2008 R2) for a triple boot system, you can adapt/change the ideas and come up with a general case of 3-partition, triple-boot system, instead of using virtual HDs! It is very informative!



  3. JFX is right.

    While capturing an image with imagex, you must have captured the existing boot folder and bcd store data. As a default, imagex can skip certain files, but you can use the "/Config <drive:\folder\myconfig.ini" option to direct imagex to use your custom config file which should specify which folders and files to skip during capture operation.

    Since you have a single drive - single partition, your boot files (BCD store) are on the same partition, instead of the system reserved partition. Because default imagex configuration does not exclude \boot folder and files (as well as bootmgr), imagex capture operation will include the folder and the files in the wim image. When applied, you will have the boot folder, files and bootmgr written to the new disk, which will cause you the problems you indicated.

    See http://technet.microsoft.com/en-us/library/cc766147%28v=ws.10%29.aspx for info on config.ini, and how you can customize it and use it during imagex capture operation.

    You have several choices:

    1. Fixing the problem disk where image is applied: Before booting the system after applying an image containing old BCD store (boot files), boot into windows PE (using the win 7 install media), go to the drive where the image is applied, locate and take ownership of the existing boot folder and files and bootmgr, change permissions and then remove them. Use "bcdboot C:\windows /s C:" command to create a proper BCD store, and reboot the system from the drive. Ensure that the partition is set to active!!!

    2. Fixing the wim image itself (for re-use): Mount the existing wim image, remove the existing boot folder and files and bootmgr and save the image. You may need to take ownership and change permissions to be able to remove the boot files. Now, your image will be ready for use without any other modifications for the next use. You can test the image by re-applying the image to the new system (new disk).

    3. Fixing imagex capture operation issues: This option is, of course, a general case for when capturing images, and hwtahow to capture images! In principle, you might go through this process for your current situation as a test case, to confirm that your capture ops and apply ops are being performed correctly and as expected. What you need to do (if you have the time) is to create a custom imagex config.ini file, specify boot folder and files, and bootmgr as exclusions in the configuration, and then use this config.ini file during a wim image capture from an existing system (Note: the system is sysprepped with OOBE, Generalize options, and ready for capture, correct?).

    Finally, you test functionality of the new system (after the wim image is applied and new BCD store - boot files are created by issuing the BCDBOOT command) and check that the system boots correctly. Control your bcd store contents with bcdedit!. Keep a copy of the custom config.ini file with your WAIK-3 tools for re-use for other capture ops!



    On a subject related to capturing and applying images, I wanted to remind you about an issue with the sysprep - OOBE - Generalize operation to prepare a system for WIM image capture. There's a registry key "skiprearm" which may cause sysprep operation to fail, because you have exceeded rearm counts! When you try to sysprep a system that was already sysprepped previously, eventually you will run out of the rearm counts which is triggered during a sysprep - OOBE - Generalize operation (i.e. rearm count is decremented during the sysprep oper). There are ways around this issue which you may want to check by googling for "enable/disable skiprearm".

    There is also a method to reset the "rearm" count by removing a hive from the registry, and later re-installing a license, which might be of interest. Ensrure that you have good backups of your existing system before sysprepping and playing with the skiprearm registry key, and resetting rearm counts!!!

    Tip: Usually when I prepare a computer (or virt. machine) for imaging with Win7, Win 2008, I enable skiprearm, and put the system into Sysprep-Audit mode (CTRL+Shift+F3 at the initial boot of the OS after the installation of OS). I perform driver and software installs, configs, and customizations. When the system is configured as I want it, I boot the machine into WinPE, access the offline registry of the installed OS, and remove registry item related to rearm counts (WPA key under HKLM\System) [source info: http://www.zimbio.com/Windows+Vista/articles/ahWKUTCstH9/Unlimited+Rearm+Windows+7+Forever+Usage+without].

    Reboot the machine into sysprep-Audit, install the product license, and keep skiprearm registry enabled (to prevent decrement of rearm count). When you check activation, you will see the license info, grace period and remaining rearm counts. I will disable skiprearm before I perform a Sysprep-OOBE-generalize before attempting an image capture.

    The enable/disable skiprearm, and deleting of WPA key enables me to overcome/resolve issues arising from activation grace period, and sysprepping a machine multiple times.

    It is good that with win 8 and win 2012, sysprepping is not limited to 3 times as it is with Win Vista/7/2008.

  4. Or you can use imagex /apply and place the contents of install.wim onto c: drive.

    Place imagex and other necessary files and install.wim on D-drive, then use imagex /apply to extract and write the contents of install.wim onto C-drive.

    Then, you can use BCDBOOT command-

    Bcdboot.exe <source> [/l <locale> ] [/s <volume-letter> ] [/v]

    <source> is windows source folder

    /l <locale> is locale (such as en-us)

    /s <volume-letter> is the target drive

    /v is verbose mode

    So you should issue-

    bcdboot C:\windows\ /l en-us /s C: /v

    to create a bcdstore on C drive (based on windows source files extracted from install.wim onto c-drive). Make sure c drive is the active partition, and boot the system, and it should start windows setup.

  5. For some type of drivers such as new network drivers (but not the sata drivers), it is possible to update the bartpe without going through the full rebuild option. You need to check out the minint folder and subfolders and see where the dll, inf, cat, and sys files are located, then for the new drivers, you should copy the relevant files to the respective subfolders. I have done that for additional or new network drivers, by extracting the bartpe iso to my hd, and copying the inf, dll, sys, cat files to the subfolders of minint, and making a new iso. However, with sata drivers or drivers that are needed during system boot up, this method doesn't work.

  6. Yeah its totally got me boggled. Its a USB key. It gives me the option to choose "Win7PE Boot Image, Ramdisk & Options" or "Grob" when I boot from USB. So I choose Win7PE and the USB key starts flashing while it says "Windows is loading files"....so I'm thinking yeah everything is cool and THEN the USB key goes black and the screen changes to the "Microsoft Corporation" status bar screen and freezes. I can't even image how it would be possible but yet here I sit writing this message. I guess I'm just going to have to take it down to the shop and let them pull the drive I'm just afraid they are going to MUCK it up........

    I had a similar problem with a HP laptop booting BartPE and WINPE1 from USB stick several years ago, and the main reason was that while the system was loading (windows is loading files), the USB bus would be reset, and the connection to the USB stick would interrupted leaving me with a black screen or the WINPE logo and no activity whatsoever (I could see the USB stick stop flashing). I could only boot the laptop with the built-in cdrom drive, and using bartpe and winpe1 burned on CDRs. Eventually, I had to reorganize the internal HD after managing to boot the system with a winpe CDR, and configured a separate partitions for winpe, Windows XP, and data, and used Grub4DOS as a boot loader.

    I think that even with a USB cd drive you may have problems, if what I suspect is correct (that is, if the issue is resetting of USB bus, instead of a problem with USB stick, then any USB external drive of any sort will not work). If you have network adapter and the drivers, perhaps you can build a custom winpe with the network drivers, and then try loading winpe via tftp, using another PC as the ftp server (there are free tftp progs available such as tftp32), as long as your NIC allows booting your netbook pc...

    Another option you might try is:

    1. depending on your RAM, create the absolute smallest bartpe, winpe or whatever recovery system you want as an iso file. Probably need to use your dekstop PC for that.

    2. Get a copy of grub4dos, and install it on your usb stick.

    3. place a copy of the system recovery iso file on your usb

    4. Use wincontig or similar utility to ensure that your iso file on the USB stick is contiguous (not fragmented and is contiguous in one piece)

    5. Prepare your grub menu for loading/booting the iso image into your ram (see grub4dos documentation for using iso images for booting with the grub MAP command for details)

    When you boot your netbook with the usb stick grub will take conrol and load the iso image to ram, and this may help bypass the USB bus reset issue, since the system recovery iso will be already loaded into ram, and will pass the control to continue booting your system from the ram! (that is why it is important that you have to create the absolute smallest ISO image).

    Note: there are similarities between this method and using tftp server (booting from network), as during the network boot (with tftp), the netbook will read the boot image (your iso file or any boot image file you prepared) and load it into ram, and then boot your system from ram. In the above method instead of loading the boot image from tftp, you are loading it from USB via grub4dos. Keep in mind that your USB should contain the iso image of winpe or bart pe, not the extracted contents of the winpe/bartpe cdr image. This is different than what happens if you use WIMB's sugegstion item-2 method, where the contents of the winpe ISO are extracted to the USB. With the normal method (winpe files extracted to USB), the syste will try to load windows files from the USB, and sometimes during/after loading windows files, USB bus will be interrupted/reset, and will not be able to proceed with booting the system. If you load the WINPE into RAM (grub map into memory/ram the winpe.iso image file) then the windows system will be already in the RAM, and when the system starts loading winows files, any USB bus reset or interruption should not have any effect, since the files are available in the RAM, where the pc will be loading the stuff!!!

  7. I don't know, but logically thinking I expect the security settings to be reset, since part of sysprep is creation of new SIDs... therefore something must be going on regarding file security and the new security principals, right?

    File comparison:

    there are many file comparison utlities both free and commecial that use different comparison methods (incl. full binary comparison, md5 or other file hash comprison, same name, same size, etc.). I have mostly used NoClone, and it can compare thousands of files wherever they recide. It will list identical files (duplicates) with their full paths.

    If you are looking for a utility to hilight the differences between two versions of a file (what is different in between two files that are supposed to be identical) then you need to look for something like DIFF utility, but the little I have seen of such utilities require a pair of files to be fed into the utility, so I can't say I know of a utility that can take compare files in two different locations (a drive, folder, etc.) and list differences between the files..

  8. I have some explaining to do, Iput the new bootscreen in the reverse integrated one after reboot the bootscreen was the new one . Then sysprepd with the generalized checked then I used oobe. then I copied it to a clean version of Windows setup drive then created an ISO. WHen I tested in VMware Workstation 7. It returned it to the Original Bootscreen. Why? how does windows know that the files were changed and what does it compare them to? John

    I am not sure I understand what you are trying to figure out, as the above explanation is not clear enough for me, but based on what litle I gleaned from the above post and others, I can point out the following which may or may not help you in the right direction...

    1. Since you are using virtualization, you can always mount the Virtual Disk (VD), and look at the contents of a bcd store in detail; before and after a sysprep. So you have a means of comparison you can use to determine what changes (and possibly where those changes may come from).

    2. You can also extract the boot.wim or install.wim (original, or modified versions), and see if they contain a bcdstore and look at the contents --mind you, original wims do not have a bcdstore, but modified wims, especially, those that you create manually [actually, images captured via imagex] which are based on a physical or virtual disk or partitions, may contain a bcd store! In the case of when you have a bcd store in such wims you can extract and compare contents.

    3. During sysprep, based on your sysprep option selections, various registry settings are configured. After the first boot, some of the sysprep registry settings are changed, indicating the status of the machine, i.e. the machine has gone through an initialization of drivers, services and such (as indicated on screen by the "setting up drivers...." and "setting up/configuring services..." messages).

    Important: The limitation of "you can only sysprep a machine [physical or virtual] only 3 times" comes from a registry setting that keeps incrementing when the machine is sysprepped.

    I suspect that registry settings regarding sysprep status and possibly machine status/readines (such as the registry settings that mean: "windows OS has initialized and configured properly" or "windows needs initialize -- i.e. it needs to set up drivers and services") may play an important role in what [i suspect] you are trying to figure out [as I understand from your messages --if I misunderstood, sorry!!!]

    A little trick you can use is to check out all bcd stores (including the bcd store you have configured yourself, or obtain by mounting a VD, or a wim file), and then edit them so that each bcd store you have access to has the following items configured (and if not configured, add the the necessary items with relevant values):

    -In the {bootmanager} item, make sure the "timeout" item is set up (with a long enough period such as 30 sec), and

    - "displaymenu Yes" item is added as well,

    Make sure that each bcdstore menu item is configured with unique descriptions, so that you can always see the menu being displayed.

    For example, the VD has a bcdstore with 2 menu items: "windows 7", and "windows 7 recovery"

    Change the decriptions to: "Windows 7 - root", and "windows 7 recovery -root"

    You also discoverd that boot.wim and install.wim have bcdstore inside the wim images. Mount the WIM files, and edit the bcdstores. First, add the bootmenutimeout and displayboot items, and then for the boot menu options add a good description such as "windows PE - boot_wim", and "Windows setup - install_wim"

    When you boot the machine, you may determine, from the boot menu displayed onscreen, which bcdstore is being loaded.

  9. ......

    I had created a wim on a wd black 500GB drive and tried to deploy that to a wd blue 320GB drive and it would not take?

    I then installed everything on the 320GB drive created my wim and tried to then deploy it to the 500GB drive and the same error.

    Because I had cleaned the 500GB drive I thought...what the hell I will try to reinstate the original wim from the 500BG drive and see what gives... and it worked?


    A question regarding your situation... Do you have both drives installed on the same computer at the same time, when you are creating and then deploying the wim file (such as HD1 and HD2)? If so, then I doubt the problem is only a matter of fixing BCd store (via repair or manual editing). There is also the issue of HD order in the BIOS, and in the Win registry (mounted drives, etc) that might come into play, besides the hardware related information being used to set up Windows Activation data.

    How about the following scenario:

    1. HD 1 (500 GB) (first HD in the BIOS)

    2. HD2 (320 GB) (second HD in the BIOS)

    3. install, configure windows on HD1, take a wim image

    4. Apply wim image on HD2

    5. Either in the BIOS or physically change HD order (i.e. HD2 becomes 1st HD, and HD1 becomes second HD)

    6. try booting from HD2 (now the first HD) and if need be fix bCD store, and see if the problem goes away.

    Basically with the above scenario there's no excessive chaneg in your hardware configuration which Windows Actiation will use, except HD order (and the way they are attached), and by swapping the HD order, you may overcome the Windows registry issues, since HD2 which has the wim image applied becomes the first HD (just like the original HD1 where windows was initially installed).

    With regards to the Regitry settings there's a neat little trick you can use (from another post in this forum):


    - Create a text file named i.e. "Unmount.reg", and paste into it the following lines:

    Windows Registry Editor Version 5.00
    <blank line>
    <blank line>

    - Doubleclick "Unmount.reg" to allow registry update at boot.

    - Shutdown

    So, before taking a wim image of your installation on HD1:

    execute the above reg hack, shutdown machine, boot into winPE, obtain a wim image of HD1, and apply wim to HD2, [possibly optional but you can still try changing HD boot order either phsycially and/or in the BIOS], and then try booting from HD2 where wim image is applied.

    Curious if this will work without sysprepping step!!! and whether it will overcome the Windows Activation issues as well (non-genuine Win message)???

  10. Playing with VHDs, and physical Disk partitions, I had successfulyl tested the following:

    1. Physcial disk partitioned into 2 primary partitions and 1 logical partition; C (1st pri, ACT, 500 MB), D (2nd pri, 10 GB), E (3rd, logical in extended partition, 20 gb)

    2. boot_wim.VHD (5gb, fixed VHD file, single partition VHD disk, pri) containing extracted contents of boot.wim file (win7), and is placed in D-drive. (Note: Initially, boot_wim.VHD is attached via disk manager, so that Boot.wim is extracted into boot_wim.VHD using "ImageX \apply".)

    3. install_wim VHD (15gb, fixed VHD file, single partition VHD disk, pri) containing extracted contents of install.wim (win7), and is placed in E-drive. (Note: Initially, install_wim.VHD is attached via disk manager, so that Install.wim is extracted into install_wim.VHD using "ImageX \apply".)

    4. C-drive contains only grub4dos and a menu.lst file. grub4dos boot record is installed on the MBR, and grldr is at the root of C-drive. Menu.lst file contains 2 entries:


    5. On both D and E drive I have setup separate bcd stores. Each bcdstore is simple and only points to the VHD file located on their respective partition



    I encountered a slight problem when native booting a winpe differencing VHD file (i.e. a standard or customized boot.wim file applied to a VHD file). I was trying to set up the following situation:

    1. Internal HD partitioned C (Active, primary) to be used for bootmgr and bcdstore (and grub), D (logical drive on extended partition) to be used to store VHD files, E (logical drive on extended partition) to be used to store differencing VHD files.

    2. bootwim.vhd (fixed vhd with 5gb cap, single partition, primary) located on D drive. Obtained by applying boot.wim file on to bootwim.vhd

    3. bootwim-diff.vhd located on E drive (which is a child of the bootwim.vhd [ "parent VHD" ] that is located on D drive)

    The reason I tried to use differencing disk is to keep the original bootwim.vhd file static, and get any changes written to the differencing disk, and if need be later merge the child vhd (differencing disk) with the parent vhd.

    Then, I configured the bcdstore on C drive to boot from the bootwim-diff.vhd (located on E drive), and while testing this configuration, I end up with bcdstore errors. I have not been able to boot from the differencing disk (on E drive)!

    However, if I set up bootwim-diff.vhd on the D drive (same drive where bootwim.vhd -the parent vhd- file is located), then I can boot from the differencing VHD.

    Unfortunately, I don't have any answers to the problem yet.

  11. The only bad thing about using dism on a attached vhd is there is no /discard to undo stuff if you screw up...whatever you do is permanent

    I'm not sure how to take this statement. If you have an attached VHD, and apply a wim file, and you're not happy with the result, you can always do a quick format of the VHD, modify your wim, and reapply.

    If this is a situation where you already had data in the VHD and are applying a wim and not happy with the results, the only UNDO option you have is making use of a differencing VHD:

    1. Keep your original data in the parent VHD (parent vhd),

    2. create a differencing VHD (child vhd),

    3. apply wim on the differencing vhd

    4. test results...

    If not happy, remove the differencing disk, recreate it, and modify what ever it is you want to modify in your wim, and re-apply the wim on the new differencing disk.

    If you're happy with the results, then merge the differencing disk with the parent disk, and then you can remove the old vhd disks, and make use of the new vhd (merged VHD).

  12. Problem is I don't have office 2007 to do tests, as I use Office 2003, so it's difficult to find out what is going on, forcing me to guess.

    Now, with the comment from Ponch, which is opposite of what Novie is saying, I'm wondering if Novice has a named/defined the range K10:M10 somewhere on the worksheet? I suspect Ponch tested this out on a clean worksheet, and that forces me suspect that Novice has a named range or something similar defined for K10:M10 on his worksheet. Perhaps selecting the first cell of a "named range" is forcing the formula to h-light/select the full named range???

  13. Assuming the system restore image was restored to the C drive, and the OS was restored to the D drive we need to edit the BCD store to tell the booloader how to load the OS.

    The BCD store is located on the C drive... the system restore partition.

    To enumerate the BCD store on the C drive you will need to use the following command:

    bcdedit /store C:\Boot\BCD

    This will give you a display of the BCD store as it sits currently. It is in a broken state, we need to repaire two entries, the device and osdevice.

    We will be pointing both the device and osdevice to the D dive if the system restore partition was restored, if there is only one partition on the drive change the following commands to point ot C:

    bcdedit /store C:\boot\bcd /set {default} device partition=D:
    bcdedit /store C:\boot\bcd /set {default} osdevice partition=D:

    The BCD will now know to run winload from the D drive (D is relational to the partiion order the BCD and bootloader sees, not what is displayed in Windows).

    You should be able to reboot and load up Windows :-)

    You can use the bootrec command to scan for the os and automatically rebuild the BCD store... you will have to do this if you did not get the BCD store in the intial WIM creation (unless you want to build it from scratch, line by line).

    The problem with bootrec is that it is hard to script properly, the two lines above are easy to scritpt and have served me very well.

    I hope this helps, please let me know if you have any quesitons. I will try to get back in a timely fashion.

    I am pretty sure the original post mentioned that after a wim file is applied to a drive, the user has also run repair operation which usually scans and fixes the BCD store issues. So, yes, editing BCD store manualllyor running repair (or booting with original win 7 DVD and choosing repair int he install screen) should fix the problem, but it user complains about blue screen + Non Genuine Windows message.

    Sooo... what is exactly going on and after doing the following:

    1. create wim

    2. deploy wim to another drive

    how can you get the system working from the new drive without issues (and solve the issues that arise?)

    I think sysprep is a necessity. I also remember (though I am not sure 100% where I have seen/read it but possibly at MS technet) that wim cannot be used as a sort of backup to restore a system...

  14. Thank you, Jaclaz, for the corrections and clarifications over MBR/PBR.

    It is unfortunate that so many companies are using terminology in an ambiguous manner (even using words interchangably and wrongly), or use technical descriptions that are imprecise.

    I have come across a good web-site on the subject of multi-boot and multi-boot process that deal with Windows and other boot managers and the details of booting (theoretical/practical) and HD boot sector/MBR, etc. which I hope would be of some use to us to get a better understanding, especially, in the light of your corrections:

    Boot and MultiBooting (as related Windows XP, Vista booting, and details of multibooting the 2 different types of Windows booting - ntldr and bootmgr)

  15. I am not sure how to turn off the help from Excel, but your problem regarding automatic selection of a range of cells reminded me what might be at play. However this is based on Excel 2003, so may not be applicable in your case.

    When you are starting a formula but especially when you use the SUM function (via the toolbar icon), Excel seems to select a range of cells in a column that are "contiguous". If, for example, in a column you have a range a1 to a5 [A1:A5] and another range from a7 to a10 [A7:A10], and you are inputting a formula or SUM at A11, then Excel hi-lights the range [A7-A10] instead of [A1:A10] as the range [A7-A10] is the first contiguous range next to A11 where the formula is being started.

    However, if you input <space> in cell A6, so it looks empty at a first glance (because <space> is not an obvious, visible character), and perform the same test, you will see that the range [A1:A10] are hilighted, since the rane [A1:A10] is a contiguous range!

    I suspect that in your case the cell M10 has some value (even if it is a space character or something similar and left over from some other operation). Thus, first check if that assumpation is correct, i.e. if cell M10 contains anything, and perhaps try a Delete and/or Clean Contents operation on M10, then try out writing your formula and see if M10 is automatically selected.

    I suspect that the issue you have is related to Formula Autocomplete function. When formula Autocomplete is enabled, as soon as you input "=" and type a letter a list of functions are displayed in a drop-down list for you to quickly select a function. However, in your case, you type "=" and then with the mouse you click on a cell, and since you have not continued your input into the cell with a character where Excel can help you out with formula autocomplete by displaying functions in a drop-down list (starting with the character you have input), but instead, you have selected a cell with your mouse, then Excel is probably trying to perform the formula autocomplete ability by hi-lighting a range selection... Perhaps you can Disable formula autocomplete.

    You might want to test the above possibility by going to the Menu system, and then Options, choose 'Formulas', and selecting 'Working with formulas' group, and looking at the choices there and reconfiguring them!

    In the meantime, if I find something specific regarding Excel's (idiotic) "helpful" hand :-) I'll post it here.

  16. Look, it's like comparing Orange and Apples, it can be done allright:


    but not necessarily using the one will be an answer to a problem that can be solved by the other.

    A Porsche 911 is much faster than a Toyota Hilux truck, but if the issue at hand is "how do I bring my apples (or oranges for that matter) to the fruit market to sell them?" the latter is a more suitable answer to the question.



    OK! I'm not trying to pick up a fight or argue the point. I agree with the right tool for the job at hand! I was just making a point about alternatives with regards to specific situations.

    On the low end I use Virtual Box, especially with the desktops and laptops where I have to conduct some tests, so for XP and similar OSes, the USB is the easiest solution. Grub4Dos works perfectly, and for a quick and dirty testing the combi (USB + VirtualBox) works excellent as well. Sometimes at work, I deal too much with XP and old OS stuff, where USB is my multi-purpose Swiss-Army-Knife. OTOH, I mentioned my bias towards VHDs, and the reasons too: I also work too frquently with Hyper-V to be able to make use of USB, and forget about grub4DOS for booting a VHD ina VM. So the point was not comparing apples and oranges (BTW, nice article that one!) but based on the tools I have at hand at any specific time (such as Hyper-V, and hi-end win7), there are alternative and creative solutions, and sometimes necessity forces you to come up with alternatives.And well, I kinda appreciate the possibilities opened up with native boot stuff, since it came up first, and the new hasn't worn off yet (say, it's kinda loooong honeymoon phase that's not ended yet <tongue-in-cheek firmly>), and am looking forward to the next virtualization or other possibilities that may come about in the future. :-))

  17. 1) A) I have another Hard Disk (which I'm working from now).

    B)I can download a live CD.

    C)I have Ubuntu on my Flash Disk but I haven't tried it yet.

    D)I have Hirents Boot

    2) I will try to do that now.

    3) I will try to do that also now.

    First, use a good AV program and do a full scan after a booting from an uninfected source!

    Since you have another disk, you can make a backup of your old OS partition using an imaging software (ghost, etc. or even imageX /capture command from MS WAIK). Then boot with your original win7 dvd and try to repair the system (boot problems) and see if this solves the issue. The other option is to use the DVD and peform an Upgrade install on the existing one (if it is possible or allowed).

    If nothing resolves your issues, once you have a backup copy of your old installation (via ghost or imagex or similar), you can do a clean install on the old HD, and you can use the backup image and extract the data files, so data loss is minimal, and the extra effort is installing/configuring OS and apps, and recovering data files from the backup image! :-)

  18. Have you tried using sysprep and hen create the wim and deploy to both HDs to see what results you get? It seems as if the drive change is being interpreted as hardware change (and perhaps incompatible hardware).

    Another issue might be the bootsector on the HDs and the bcd store. You might want to look at the bcd store configuration and edit it manually, and perhaps also apply the bootsect /nt60 /s <drive:> command to update MBR code. Also check out the status of your HD and partitions. The disk (or partition) where you apply/extract your WIM file needs to be the Active disk/partition. Since you have 2 HDs, the boot order may be causing issues in determining the OS drive/boot drive (BIOS boot order???), or some problem along those lines of thought....

    Other ideas you can try/test out:

    1. you can create a small boot partition (say 500 mb or so) on one specfic HD which is to be set as Active, and to only contain the bootmgr and the bcd store. Don't make any changes to that partition. Make your installation of win 7 on another partition or disk which will contain the OS and apps except the bootmgr and the bcdstore (which will be loacted at the designated small partition!) Create a WIM and deploy the wim to another HD or partition and see what happens?

    2. if you are using win 7 ultimate (or enterprise), then you can install win 7 to a VHD, and create a wim from the vhd. Then you can test if the wim could be deployed to either of the HDs. I know that you can just move the vhd from one physical disk (partiton) to another, and only need to edit the reference to the location of VHD file in the bcd store to get it working, but it will be interesting to see if the wim file (of a VHD) can be deployed to either of the disks with minimal issues/problems.

  19. After 2 full days of searching and researching I have come up blanks so was hoping someone could help me.

    I have hundreds of scripts written by 3rd parties that I need to incorporate into a WIM, the trouble is all the scripts are hard coded to reference an X: drive. I can not rework the scripts becuause of licensing and liabilities so need to find a way of getting WinPE to alllow me to physically set the drive letter it loads as the RAM drive and subsiquently mount a device as the X: drive.


    I can't believe MS would hardcode the drive letter so deeply that it can not be changed, I know with the intruduction of WMI the registry needs a hardcoded reference, but surely this can be dynamic up to the point of creating the RAM Drive, even if this means rebuilding the sdi.

    You can try the following:

    First, mount the boot.wim file which is the winPE-

    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:\ (or some other drive letter)

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

    Dism /Unmount-Wim /MountDir:D:\data\tmpWimMount /commit

    Repeat the above steps for boot.wim index=2 image as well, and make sure the target path is the same as what you have specified for boot.wim index=1 image. Commit changes and unmount boot.wim index-2 image.

    Then try out your scripts and see if that works.

  20. 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. :whistle:


    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! :-)

  21. 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!

  22. 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- /Set- Target Path
    commands work on the
    index-2 image
    as well, and should be used to specify the System Root Directory (usually
    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!


    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 :-)

  23. It's not that difficult to do...

    Scenario-1: you have a single partition on the host with a bcd store and bootmgr (host-store), and a VHD file also has a bcdstore and bootmgr (vhd-store), and you want to boot your system as follows:

    1. PC boot from host-store

    2. transfers control to vhd (i.e. transfers control to the bootmgr inside vhd)

    3. vhd-store takes over and executes

    Important point is the host-store; you need to lok at the windows boot loader section, and make the following changes:

    Windows Boot Loader


    identifier {default}

    device vhd=[locate]\sample.vhd

    path \bootmgr

    osdevice vhd=[locate]\sample.vhd

    systemroot \windows

    where, sample.vhd is the vhd file that you want to boot from. Make sure when editing the host-store with bcdedit, you use the "-enum all" option so that you have a detailed listing of the host-store. If need be, you can also delete the BCD file (and the log files) on the host, and start from scratch.

    As long as your guest-store (bcd store inside samplevhd) is correctly working (which you can test by using virtual PC and booting sample.vhd by attaching as the boot hd to see if it is booting correctly), then you shouldn't experience any problems.

    Scenario-2: you have a single partition on the host with a bcd store and bootmgr (host-store), and a VHD file also has a bcdstore and bootmgr (vhd-store), and you want to boot your system as follows:

    1. PC boot from host-store

    2. boots from vhd

    This is usualy the standard method explained in the MS technet web-site for native booting. Important points are:

    1. check guest-store (bcdedit -store <mount point of vhd file>\boot\bcd -enum all) in detail and note the Windows Boot Loader settings, especially the device, osdevice, pth, and systemroot settings. Hal detect, winpe, ems settings as well as hypervisor and device Options.... Copare them to your host-store.

    2. On the host-store, in the Windows Boot Loader section, the device and osdevice should point to the VHD file (VHD=[locate]\sample.vhd). Path should be the same as guest-store Windows Boot loader path statement! Same for the systemroot on host-store and the guest-store.

    After the host-store is configured as explained in 1 and 2, you can remove the bcd store and bootmgr from sample vhd. You can even set sample.vhd as a NON-Active HD.

    Playing with VHDs, and physical Disk partitions, I had successfulyl tested the following:

    1. Physcial disk partitioned into 2 primary partitions and 1 logical partition; C (1st pri, ACT, 500 MB), D (2nd pri, 10 GB), E (3rd, logical in extended partition, 20 gb)

    2. boot_wim.VHD (5gb, fixed VHD file, single partition VHD disk, pri) containing extracted contents of boot.wim file (win7), and is placed in D-drive. (Note: Initially, boot_wim.VHD is attached via disk manager, so that Boot.wim is extracted into boot_wim.VHD using "ImageX \apply".)

    3. install_wim VHD (15gb, fixed VHD file, single partition VHD disk, pri) containing extracted contents of install.wim (win7), and is placed in E-drive. (Note: Initially, install_wim.VHD is attached via disk manager, so that Install.wim is extracted into install_wim.VHD using "ImageX \apply".)

    4. C-drive contains only grub4dos and a menu.lst file. grub4dos boot record is installed on the MBR, and grldr is at the root of C-drive. Menu.lst file contains 2 entries:

    #boot Boot.wim vhd

    title 1) boot into w7 boot_wim VHD on D-drive

    root (hd1,1)

    chainloader /bootmgr

    #boot Boot.wim vhd

    title 2) boot into w7 install_wim VHD on E-drive

    root (hd1,4) **** NOTE: HD1,4 is the correct entry for the first logical drive (in our example, this is the E-drive) on an extended partition for grub4dos!!!

    chainloader /bootmgr

    5. On both D and E drive I have setup separate bcd stores. Each bcdstore is simple and only points to the VHD file located on their respective partition

    When the bcd stores are correctly configured (device, osdevice, path, systemroot entries), then the following happens when you boot the test pc:

    - pc boot, grubloader displays the menu.

    - if "boot into boot wim VHD" option is selected, then the control goes to the bootmgr (and boot-store) on the D-drive, and then boots the boot_wim.VHD (either using the scenario-1 or scenario-2 type of bcd store configuration explained at the beginning of this post). Therefore, your PC ends up booting into WINPE environment!

    - if "boot into Install wim VHD" option is selected, then control goes to the bootmgr (and boot-store) on the E-drive, and then boots the install_wim.VHD (either using the scenario-1 or scenario-2 type of bcd store configuration explained at the beginning of this post). Therefore, your PC ends up booting into windows installer, and starts installing windows 7.

    Note that if you perform windows 7 installation, it will be installed in the VHD file. You may have to reconfigure your bcd store (either in the install_wim.vhd or the host bcd store on E-drive) to be able to boot your PC into normal Windows 7 and work with your PC!

    It is interesting to note that, under normal circumstances, you cannot boot windows 7 (or 2008 server) from an extended partition (logical drive), and even need your partition or disk to be set as ACTIVE! Those requirements are bypassed when you start using native VHD boot methods.

    Another great advantage of going for Native VHD boot, is that you can have several VHD files pre-prepared as follows:

    1. A single vhd file containing extracted contents of various Driver packs (from driverpacks.net web-site), perhaps divided into separate x86 an x64 VHD files. With the help of DPInst or other driver install utility, the drivers will be at your back and call as soon as you attach the driver VHD file. Even at the initial winpe boot phase, you can use the Shift-F10 option, and in the command prompt go for diskpart and select and attach the driver.vhd file. Especially if you had taken the time to modify your boot.wim and install.wim files and injected them with at least the chipset and mass-storage drivers, before extracting the contents of the wim files to their respective VHD files (imagex \apply)... Also the drivers.VHD files will be easy to keep up to date and modify. No more need to prepare a new USB, or burn a new CD/DVD... Mount the VHD, edit the contents to replace old files with new ones (remove unneeded drivers, etc...)

    2. Another vhd file, where you have the portable applications platform and portable applications installed. At any time within a custom Win7PESE or LastOS or similar winpe environment, you can attach the VHD file, and access ready, installed portable apps, without having to modify, uninstall, re-install or even delet old and install new portabl apps within your custom winpe or even normal Windows environment! Talk about modularity!!! :-) And the only upates you have to perform are within the PPApps.VHD file itself, by mounting it and modifying its contents. Helps with organizing and keeping things up-to-date and keeping your OS VHD clutter free!

    As long as you are able to get into some kind of win 7 flavor (either a winpe, or win 7 light or a normal win 7 via bootmgr and booting into vhd), then there's a lot of flexibility in how to work with stuff.

    I used to do similar with grub4dos, but it's no flexible enough. For example to be able to boot iso file, they need to be small and contiguous on the disk (defragged). To big image file or partition is fragmented with iso file segments here and there, you have to do a lot of preparation work to get an iso mage to boot and continue work. Same with HD image files in grub4dos.

    Now, I like the ability to use the grub4dos to pass control to selective (and separate) bootmgr and bcd stores located on various partitions, and let bootmgr manage my vhd files!

    Another disadvantage I have come across is that when doing testing with VMs under hyper-V, the VM freezes when VHD is booted using grub4dos, so I had to rely on bootmgr and bcd store to be able to boot VMs under hyper-V. I also tested nested VHDs (VHD within a apartition of a VHD) under hyper-V with careful design of BCD stores on both the container VHD and the "containED" VHD!!! :-)

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

    First, mount the boot.wim-

    Dism /Mount-Wim /WimFile:

    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:

    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:

    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:

    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-


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


    Browse to the following key:


    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:


    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:

    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)

    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.

    (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
    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

    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-



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

    DISM.exe /image:
    /Add-Driver /driver:
    /recurse /

    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.

  • Create New...