Monday, July 7, 2014

Since Windows 8.1 Microsoft compiles system utilities against NT 6.0 kernel.

Until Windows 8.1 Microsoft has compiled system utilities against NT 5.1 kernel so this is a major move. 

Windows 8.1 utilities can no longer run on Windows XP !

I suspect this move is a consequence of ending support for Windows XP on April 8, 2014
(Windows 8.1 official release date was October 17, 2013).

All Windows system utilities from Vista, Windows 7 and Windows 8 could run also on Windows XP which has NT 5.1 kernel.

Developers used this fact to implement functionality and support for Windows Vista and later under Windows XP. An example is implementing support for Windows BCD in Windows XP in a dual-boot system with Windows Vista/7/8 (bcdboot.exe and bcdedit.exe utilities until version 6.2.x.x could run without problems in Windows XP).

Windows kernel versions:

Windows XP - 5.1.x.x
Windows Vista - 6.0.x.x
Windows 7 - 6.1.x.x
Windows 8 - 6.2.x.x
Windows 8.1 - 6.3.x.x

Friday, May 30, 2014

Exploring Windows UEFI - Part 1.

Newer versions of Windows 8/8.1 are installed on computers with UEFI firmware.

The combination UEFI/GPT is not so well known as BIOS/MBR. In a series of posts I will try to explain practical aspects of Windows on UEFI/GPT. The first post in the series is about exploring some UEFI variables and the functionality it offers to users.

From Windows 8/7 you can access UEFI firmware variables in two ways:
  a) using Get/SetFirmwareEnvironmentVariable functions or
  b) using BCD (Boot Configuration Data) interface (either with bcdedit or WMI BCD Provider)

On UEFI boot entry variables are named "BootNNNN" where NNNN are hexadecimal numbers:
     for example - Boot0000, Boot0002, Boot0003, Boot2001, ....
     boot entry numbers must not be consecutive.

There is a "main" NVRAM variable which holds a list of boot entry numbers - "BootOrder" and defines the boot priority of boot entries, the first number in the list is the first boot entry candidate (if BootNext is not defined).
Let us mention also "BootCurrent" NVRAM variable which (if defined) holds the number of current boot entry used for booting the OS - Windows, Linux etc.

Linux distributions include the utility "efibootmgr" which gives access to UEFI(NVRAM) variables and keep a copy of NVRAM in "/sys/firmware/efi/vars" directory.
Windows 8/7 delivers bcdedit command line utility which allow some access to UEFI NVRAM variables, mainly read access, but you can also change the value of some variables.

Let us mention also the "Timeout" variable to end the list of all "basic" NVRAM UEFI variables. "Timeout" defines the timeout in seconds. Windows installations set Timeout to 2 by default.

So we have mentioned so far:
 - BootOrder - list of NNNN
 - BootNNNN - boot entries
 - BootCurrent - NNNN of current boot entry
 - BootNext - NNNN of boot entry to be used on next boot
 - Timeout

In Windows BCD there are equivalents for the above notions:
  BootOrder => DisplayOrder element of {fwbootmgr}
  BootNNNN => objects with special type of "0x101FFFFF"
  BootCurrent => not mapped, but we have {current} object for Windows loaders
  BootNext => BootSequence of {fwbootmgr}
  Timeout => Timeout of {fwbootmgr}

Experimenting with BootOrder (DisplayOrder element of {fwbootmgr}) from Windows I did not succeed to change NVRAM variable permanently. You can change the order temporarily but on reboot edits are lost. So only direct changing of BootOrder using SetFirmwareEnvironmentVariable function should give a permanent change.

It should be mentioned that Windows keeps a copy of System-BCD in registry:
where it stores a mix of Windows and NVRAM boot related variables.

Experimenting to change some of the elements of BootNNNN - firmware objects in BCD - had also either temporary or no effect.
A boot entry from NVRAM is mapped in Windows BCD as an object with a special type of 0x101FFFFF (firmware application) with three elements: "ApplicationDevice", "ApplicationPath" and "Description".

Creation of new UEFI NVRAM boot entries has also failed for Windows (Microsoft) related paths (for "bootgmr.efi" and "bootmgfw.efi") but you can create a boot entry for a "foreign" operating system like Ubuntu or Fedora using real paths (existing UEFI applications on EFI System Partition) - for example "Z:\EFI\ubuntu\grubx64.efi", where Z: is mapped to ESP (EFI System Partition on GPT disk) using "mountvol.exe".

Timeout can be changed permanently using bcdedit or WMI interface.

BootNext can be changed permanently (its live is until next reboot) and I have used this functionality in the tool "BootNext - v1.0" to allow Windows 8/7 users to boot directly to any installed device or OS (Windows 7/8, Ubuntu, Fedora).
The utility also offers simple one click creation of safe mode loaders (and direct boot to safe mode) as new Windows 8 modern boot menu has some obscure way of accessing the safe mode boot option.

Here is the main form of "BootNext" utility:

BootNext tool

In Part 2 I will examine an easy way of exploring ESP - EFI System Partition from Windows 7/8.

Tuesday, March 27, 2012

Boot menu policy - set text or metro style boot menu in Windows 8

BootMenuPolicy - set text or metro style boot menu in Windows 8

In Windows 8 Consumer Preview we see a new BCD element - BootMenuPolicy - in the list of BCD elements for Windows 8 loader object.

BootMenuPolicy (displayed as custom:250000c2 in older versions of bcdedit)

BootMenuPolicy is an enumeration with values:
  • MenuPolicyLegacy(0)
  • MenuPolicyStandard(1)

When BootMenuPolicy is set to MenuPolicyStandard(1) Windows 8 bootmgr displays the new graphical style boot menu.
Setting BootMenuPolicy to MenuPolicyLegacy(0) or removing that element from loader object causes bootmgr to display old text style boot menu.
If you set any other loader to be the default bootmgr object/loader old text style boot menu is displayed as element BootMenuPolicy is usually not defined for older loader objects.

As a side effect(?) setting element DisplayBootMenu element of {bootmgr} object to true(1) causes bootmgr to display old text style boot menu even if BootMenuPolicy is set to MenuPolicyStandard for Windows 8 loader set as default loader.

You can edit all elements which influence boot menu style easily using Visual BCD Editor.

Tuesday, November 16, 2010

Windows 7 VHD boot

Windows 7 Boot Manager can boot VHD's.

A VHD (virtual hard disk) is a normal file stored in the file system of the computer.
The VHD file when mounted is treated as a disk by the operating system (OS).
To create and mount (attach) a VHD you can use 'Disk Management'.
If a VHD is large enough you can install 32/64-bit Windows 7 (investigate for other OS's)  on it.

A VHD is very handy if you want to experiment with 32/64-bit OS's, test software in different environments e.t.c.

A good reference about installing Windows 7 on VHD is:
How to install Windows 7 on a virtual hard disk (VHD) in 10 steps - Guides & Tutorials:

On my computer I have three OS's: XP, Windows 7 and Kubuntu plus a "Windows 7-VHD".
(Windows 7 VHD file is on XP partition.)

Here are some images from the Windows BCD (boot configuration data) store regarding the VHD.

1. Windows 7 VHD Loader

2. Windows 7 VHD Recovery Loader

3. Windows 7 VHD Resume Loader

4. Windows 7 VHD Ramdisk options - object

5. Windows 7 VHD Ramdisk options - elements

Some comments on the images:

- the utility used is "Visual BCD Editor" and can be downloaded here:
Visual BCD Editor - Windows 7 and Vista

- all relevant BCD objects (entries) were created by "Windows 7 install on VHD".

- the images are for reference - to know what 'good' Windows 7 VHD entries look like.

A Windows 7 install creates usually three loader entries in the BCD: an 'OS Loader', a 'Recovery Loader' and a 'Resume from Hibernation Loader'. The 'Ramdisk Options' object (entry) is needed for the 'Recovery Loader'.

image 1:
The Windows 7 VHD Loader is a normal Windows 7 Loader object with special values for the 'ApplicationDevice' and 'OSDevice' elements.

image 2, 4 and 5:
The Recovery loader entry specifies parameters for loading Windows Recovery Environment. The loaded file is WinRE.wim.  Special mention for element 'RecoveryOs'=true - this element specifies that this entry(object) is a "recovery loader" - in the rest a recovery loader is a normal OS loader.
- 'ApplicationDevice' and 'OSDevice' refer to the ramdisk options through 'AddionalOptions' - compare {GUID} in image 2(form OSDevice) and image 4. (this could be a separate topic - Windows recovery loader - seems really complex).

image 3:
Resume from hibernation - loaded application is winresume.exe --> loads hiberfil.sys. (both files on VHD)