Windows 8 build 8061

6.2.8061.0.fbl_core1_soc.110803-1830
Build of Windows 8
Screenshot
OS familyWindows NT
Version number6.2
Build number8061
Build revision0
Architecturex86, ARM32
Build labfbl_core1_soc
Compiled on2011-08-03
Expiration date
Timebomb2012-03-11 (+221 days)
SKUs
Prerelease (N)
Ultimate
About dialog
Windows8-6.2.8061.0-Winver.png

Windows 8 build 8061 is a Milestone 3 build of Windows 8. Four screenshots of this build's x86 checked/debug compile in the Prerelease SKU were first shared to the BetaWiki Discord on 29 May 2020; the WIM image dump containing the ARM32 compile of this build's Ultimate SKU was later shared on 19 May 2023,[1] followed by a WIM image of this build's Prerelease N SKU on 28 January 2024.[1]

It is currently the earliest available build of Windows compiled for the ARMv7 architecture. The available copy of this build's ARMv7 Ultimate SKU image was assembled from scratch via unstaged installation media, utilizing the Preinstallation Environment for build 8175.5 to facilitate the install.

New features and changes[edit | edit source]

Interface[edit | edit source]

The start screen's default layout has been updated to feature a new set of pinned applications.

A new splash screen icon and major revisions to the descriptions of certain options (and their sections) in the Immersive Control Panel have been introduced, and slight design changes have been made towards the Windows Store application, primarily the addition of a back button in the main user interface as well as an updated application tile design. The touch-optimized Remote Desktop Connection client has been rebranded to simply Remote Desktop and its overall color palette and splash screen updated, although functionality largely remains identical.

Immersive modal dialogs now carry the background color of the user's chosen accent color by default.

Miscellaneous[edit | edit source]

The background color seen when bugchecks are invoked has been changed to cerulean, making the overall design now largely reminiscent of the one found within the RTM build.

Compatibility[edit | edit source]

This build contains ARM Cortex-A9 timer hardware abstraction layer extensions for the NVIDIA Tegra 2/3 systems-on-a-chip and the Texas Instruments OMAP4 SoC line. A HAL extension for the ARM SP804 dual timer is also included.

USB 2.0 kernel debugger extensions for the Tegra and OMAP4 SoCs are also available out-of-box, but are untested as of writing.

Patched/modified files[edit | edit source]

The following modified files are present in the ARM32 image dump:

  • winload.efi is from 6.2.8129.0 (fbl_core1_soc.111006-1700) and additionally has had signature checks patched out. This is because the EFI firmware parameters substructure of the boot library (passed to the entry point of a boot application) was later changed in build 8112 (fbl_core1_soc); attempting to load older boot applications in a boot manager from builds 8112 onward (or vice versa) will result in a crash due to differing element offsets. The patched binary allows the build to be booted using a production-signed boot manager (using donothingpolicy.pol and NOINTEGRITYCHECKS enabled in the machine's boot configuration data).
    • The original binary from build 8061 is located in Windows\WinSxS\Backup\arm_microsoft-windows-b..vironment-os-loader_31bf3856ad364e35_6.2.8061.0_none_e22fc5a8e03359c9_winload.efi_75834aa0
  • acpi.sys is from 6.2.8129.0 (fbl_core1_soc.111006-1700) (unmodified, valid signature). The ACPI implementations in builds 8061 through 8112 (fbl_core1_soc) are not compatible with Surface RT hardware, and therefore require a binary replacement to function properly on such hardware.
    • The original binary from build 8061 is located in Windows\WinSxS\arm_acpi.inf_31bf3856ad364e35_6.2.8061.0_none_a991cf7a419448c9\acpi.sys
  • partmgr.sys has two jumps patched to prevent functions from returning STATUS_MEDIA_WRITE_PROTECTED. The original version is still in the Drivers directory, named partmgr.old.
  • testplugin.dll is signed by a certificate chain named DesktopApp. This file can be restored to its original state by removing the signature.

None of the above modifications are required to boot this build under QEMU, however hal.dll will have to be patched in order to recognize the emulated timers.

Emulation[edit | edit source]

Guide for running the ARM32 compile of this build under emulation:

This guide is also relevant for other early ARM32 Windows NT builds, which additionally includes those pertaining to early Windows Phone 8 builds. All builds up to 8141 must have the Hardware Abstraction Layer patched in order to boot under an emulator. NT build 8141 (fbl_core1_mobile_dev) will boot without registry modifications, but 8124 and lower will not.
The patches on this guide are documented at a high level, and many structures and variable/argument names originate from leaked private symbols that were sourced from later Windows NT builds. As build 8061 lacks the appropriate debugging symbols (let alone private symbols), the exact same code may not be presented if the binaries were simply loaded into a decompiler.

Boot issues[edit | edit source]

Hardware Abstraction Layer (HAL)[edit | edit source]

This build is not compatible with the current version of QEMU WoA, mainly due to the lack of support for the final ARM Generic Timer ACPI descriptor table. Later builds (after 8141) acquire information about timers through the GTDT descriptor table, however this build uses its predecessor - the EGIT table.

Attempting to boot this build in QEMU WoA results in the following bugcheck:

KeBugCheckEx(HAL_INITIALIZATION_FAILED, 0x110, 0x5250631, TimerProblemNoScalingSource, STATUS_UNSUCCESSFUL);

The EGIT table used by this build is defined as follows:

typedef struct _EGIT_TABLE
{
	DESCRIPTION_HEADER Header;
	ULONGLONG MemoryMappedPhysicalAddress;
	ULONG SecurePhysicalTimerGsiv;
	ULONG NonSecurePhysicalTimerGsiv;
	ULONG VirtualTimerEventGsiv;
	ULONG HypervisorTimerEventGsiv;
	BYTE SecurePhysicalTimerFlags;
	BYTE NonSecurePhysicalTimerFlags;
	BYTE VirtualTimerEventFlags;
	BYTE HypervisorTimerEventFlags;
	ULONG GlobalFlags;
} EGIT_TABLE;
typedef EGIT_TABLE *PEGIT_TABLE;

While the earliest version of GTDT supported by WoA builds is defined as:

typedef struct _GTDT_TABLE
{
	DESCRIPTION_HEADER Header;
	ULONGLONG MemoryMappedPhysicalAddress;
	ULONG GlobalFlags;
	ULONG SecurePhysicalTimerGsiv;
	ULONG SecurePhysicalTimerFlags;
	ULONG NonSecurePhysicalTimerGsiv;
	ULONG NonSecurePhysicalTimerFlags;
	ULONG VirtualTimerEventGsiv;
	ULONG VirtualTimerEventFlags;
	ULONG NonSecurePhysicalTimer2Gsiv;
	ULONG NonSecurePhysicalTimer2Flags;
} GTDT_TABLE;
typedef GTDT_TABLE *PGTDT_TABLE;

The HAL in build 8061 queries for the EGIT. As the existing QEMU WoA fork only includes support for the GTDT, it will not find the table and hence bugcheck during HAL initialization.

HAL queries for the EGIT table through the following function call in HalpGitDiscover:

HalpAcpiGetTable(HalpTimerLoaderBlock, 'TIGE', NULL, NULL);

In order to make it query for the GTDT supported by QEMU WoA, it must be patched to become:

HalpAcpiGetTable(HalpTimerLoaderBlock, 'TDTG', NULL, NULL);

This however does not solve all issues. It is apparent that the two tables are largely identical, except for EGIT's inclusion of the Hypervisor Timer Event interrupt and GTDT's inclusion of the Non-Secure Physical Timer 2 interrupt. The biggest difference between the two tables are the ordering of the fields, EGIT places all the global system interrupt vectors (GSIVs), and all of the flags next to each other, while GTDT groups the GSIV and flags of each interrupt together. The build expects the EL1 Virtual Timer GSIV at offset 52 of the structure and flags at offset 62, while they are actually located at offsets 64 and 68 respectively in the GTDT. Moreover, the flags in the EGIT and the GTDT have different widths and meaning. To allow the GSIV and flags to be retrieved correctly, the following code in HalpGitDiscover:

NewTimer.Interrupt.Gsi = *((ULONG *)(Table + 52));
NewTimer.Interrupt.Polarity = InterruptActiveLow;
BYTE Flags = *((BYTE *)(Table + 62));
if (Flags & 2)
{
    NewTimer.Interrupt.Polarity = InterruptActiveHigh;
}
NewTimer.Interrupt.Mode = (Flags & 1);

must be patched to become:

NewTimer.Interrupt.Gsi = *((ULONG *)(Table + 64));
NewTimer.Interrupt.Polarity = InterruptActiveHigh;
ULONG Flags = *((ULONG *)(Table + 68));
if (Flags & 2)
{
    NewTimer.Interrupt.Polarity = InterruptActiveLow;
}
NewTimer.Interrupt.Mode = (Flags & 1);

Note the changes to the width of the flags and the interrupt polarity. The patches may be carried out on this build's HAL by changing:

  • 02 bytes at offset 0x138 from 8E D3 to DC E3 (PE checksum correction).
  • 19 bytes at offset 0x15B96 from 63 6B 17 93 02 23 18 93 94 F8 3E 30 13 F0 02 0F 01 D0 01 to 23 6C 17 93 01 23 18 93 63 6C 00 BF 13 F0 02 0F 01 D0 02 (table offset fixes).
  • 04 bytes at offset 0x15C10 from 45 47 49 54 to 47 54 44 54 (EGIT → GTDT).

After these patches, the HAL will be able to detect the ARM generic timers that are emulated by QEMU.

Registry fixes[edit | edit source]

Attempting to boot this build in the QEMU WoA fork with the patched HAL results in the following bugcheck:

KeBugCheckEx(INACCESSIBLE_BOOT_DEVICE, L"\\ArcName\\multi(0)disk(0)rdisk(2)partition(3)", STATUS_OBJECT_NAME_NOT_FOUND, 0, 0);

This is caused by the lack of SD host controller drivers. The below values must be merged into the registry in order for Windows to load the built-in SD host controller driver:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\ACPI]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\ACPI\PNP0D40]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\ACPI\PNP0D40\0]
"Capabilities"=dword:00000030
"ContainerID"="{00000000-0000-0000-ffff-ffffffffffff}"
"HardwareID"=hex(7):41,00,43,00,50,00,49,00,5c,00,50,00,4e,00,50,00,30,00,44,\
  00,34,00,30,00,00,00,2a,00,50,00,4e,00,50,00,30,00,44,00,34,00,30,00,00,00,\
  00,00
"ClassGUID"="{a0a588a4-c46f-4b37-b7ea-c82fe89870c6}"
"Service"="sdbus"
"DeviceDesc"="@sdbus.inf,%acpi\\pnp0d40.devicedesc%;SDA Standard Compliant SD Host Controller (compatible)"
"Driver"="{a0a588a4-c46f-4b37-b7ea-c82fe89870c6}\\0000"
"Mfg"="@sdbus.inf,%generic%;SDA Standard Compliant SD Host Controller Vendor"
"UINumberDescFormat"="@sdbus.inf,%SDBUSSlot%;SD Host Slot %1!u!"
"ConfigFlags"=dword:00000000

DWM[edit | edit source]

The Desktop Window Manager does not work as its implementation at this stage in port development is not complete and will assume all existing GPU drivers (including the generic Microsoft display driver) to be incompatible with this build, preventing software-based composition from working properly unless a Terminal Services client is used on real hardware.

Software-based rendering can be forcefully enabled by patching the main dwm.exe binary, and involves altering the method CDwmAppHost::VerifyGraphicsCapabilities to respectively set the fields fValidCompositionMode and dwDisabledEvent of the GraphicsCapabilities structure pointer pCaps to 1 and 0 and return 1 afterwards.

The patched function should look like the following:

DWORD CDwmAppHost::VerifyGraphicsCapabilities(MIL_CHANNEL hChannel, BOOL fIsBitmapRemoting, GraphicsCapabilities *pCaps)
{
	pCaps->fValidCompositionMode = 1;
	pCaps->dwDisabledEvent = 0;
	return 1;
}

The patches may be carried out on 8061's dwm.exe by changing:

  • 02 bytes at 0x00148 from 80 78 to 69 62 (PE checksum correction).
  • 06 bytes at 0x0233A from 04 DB 02 9B 13 B9 to 00 BF 02 9B 00 BF (ignore incompatible hardware).

Tips[edit | edit source]

  • The original binaries for the ACPI, SD bus and partition management drivers, as well as binaries for the boot manager and boot loader can be used under emulation.
  • Reapply the registry values outlined above after setup completes the second phase of setup to prevent an INACCESSIBLE_BOOT_DEVICE bugcheck loop, as the respective driver enumerator is removed from the Windows registry during hardware detection. This issue only occurs once and will not recur in subsequent boots after reapplication.

Bugs and quirks[edit | edit source]

SD bus driver write protection (Surface RT)[edit | edit source]

MultiMediaCard-based storage mediums (such as Secure Digital (SD) cards and eMMCs) are mounted by the operating system as read-only/write-protected file systems on the Surface RT; the build must therefore be booted under a non-MMC medium such as an external USB mass storage device or a Hyper-V virtual hard disk (VHD) image. To mount the eMMC as a read-write filesystem, the sdbus.sys function SdhcIsWriteProtected must be patched to return 0 (and the PE checksum fixed); patch file offsets 0x138 and 0x6c24 to db e2 01 and 00 20 70 47, respectively. This issue does not happen under emulation.

Windows Setup[edit | edit source]

Rendering artifacts may appear on the product key page during the out-of-box experience.

Applications[edit | edit source]

  • Chess Titans and Mahjong Titans will fail to launch as the respective English language pack resources for the built-in Windows 7 premium games are not present in the image.
  • Newly loaded web pages rendered by Internet Explorer may often use the wrong background colors, presenting shades of random colors in place of the standard white.
  • Windows Runtime applications' titles are not printed correctly and instead spew the full application user model ID (AumId).
  • Turning on administrative tools in the start screen preferences sub-menu within the Settings charm causes the Explorer shell to crash.

Desktop Window Manager[edit | edit source]

  • Desktop Window Manager software-based compositing does not work by default as the underlying implementation always assumes all built-in GPU drivers to be incompatible, unless a Terminal Services client such as Remote Desktop is used. This bug appears to only exist on the ARM32 compile of this build. The main DWM executable dwm.exe can be patched to force render even with incompatible hardware. A workaround is discussed in the above patching guide.
  • The DWM software renderer implementation in this build is subject to major performance issues and may end up becoming out-of-sync with the actual desktop session. Disabling window animations may help improve performance at the cost of visual quality.
  • Animations in the Start screen may not complete properly.
  • Disabling and re-enabling composition and then invoking the left-hand Charms menu may cause the Desktop Window Manager to crash unless the right-hand Charms bar is invoked.

Miscellaneous[edit | edit source]

  • This build cannot be powered off normally as it hangs during the shutdown process. Manually hold down the power button to power off the device instead. Shutting down can also sometimes result in a BAD_POOL_CALLER bugcheck.
  • Attempting to shut down the system may cause the system shell to crash with an invalid memory read exception if the user never exits out of the start screen first presented to the user under a redpilled environment.

Gallery[edit | edit source]

Setup and OOBE[edit | edit source]

Redpilled state[edit | edit source]

Metro OOBE[edit | edit source]

References[edit | edit source]