Windows 8 build 8061 (fbl_core1_soc)
Build of Windows 8 | |
OS family | Windows NT |
---|---|
Version number | 6.2 |
Build number | 8061 |
Build revision | 0 |
Architecture | x86, ARM32 |
Build lab | fbl_core1_soc |
Compiled on | 2011-08-03 |
Expiration date | |
Timebomb | 2012-03-11 (+221 days) |
About dialog | |
Windows 8 build 8061 (fbl_core1_soc) is a late Milestone 3 build of Windows 8, released to partners in the Ecosystem Engineering Access Program on 9 August 2011. 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; a WIM image dump of a Surface RT containing the ARMv7 compile of this build's Ultimate SKU was later shared on 19 May 2023,[1] followed by a staged WIM image of this build's Prerelease N SKU on 28 January 2024.[1] The original partner drop for both the retail and debug client releases of this build's unstaged ARMv7 installation media and Preinstallation Environment, including software development kits and raw symbol sets, were eventually uploaded on 13 July 2024, while this build's x86 counterpart original partner drop was uploaded on 19 October 2024. This is the last known build to use the Windows 7 branding on the system properties.
It is notable for being one of few Windows builds to be made available in the form of unstaged installation media; all client editions available in the Windows 8 source tree at the time of compilation (albeit labeled as Longhorn, a holdover that was never corrected internally) are available for the user to pick from and install during setup, in turn building a complete Windows image from scratch from a set of components through the use of the Windows Component-Based Servicing (CBS) stack.
The initial 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.
Editions and keys[edit | edit source]
The following SKUs are installable in this build:
Edition / SKU Name | Key |
---|---|
Starter[a][b] | 7Q28W-FT9PC-CMMYT-WHMY2-89M6G |
Starter N[a][c] | D4C3G-38HGY-HGQCV-QCWR8-97FFR |
Home Basic[b] | YGFVB-QTFXQ-3H233-PTWTJ-YRYRV |
Home Basic N[c] | MD83G-H98CG-DXPYQ-Q8GCR-HM8X2 |
Home Premium[b] | RHPQ2-RMFJH-74XYM-BH4JX-XM76F |
Home Premium N[c] | D3PVQ-V7M4J-9Q9K3-GG4K3-F99JM |
Professional[b] | HYF8J-CVRMY-CM74G-RPHKF-PW487 |
Professional N[c] | BKFRB-RTCT3-9HW44-FX3X8-M48M6 |
Enterprise[b] | H7X92-3VPBB-Q799D-Y6JJ3-86WC6 |
Enterprise Evaluation[b] | BNMMY-9D8F2-TKGQ6-BT8DJ-JFCMG |
Enterprise N[c] | BQ4TH-BWRRY-424Y9-7PQX2-B4WBD |
Enterprise N Evaluation[c] | KJC88-XWNCH-C4F7V-8X4DM-XBPMH |
Ultimate[b] | D4F6K-QK3RD-TMVMJ-BBMRX-3MBMV |
Ultimate N[c] | HTJK6-DXX8T-TVCR6-KDG67-97J8Q |
Developer Preview (Prerelease )
|
H9VCT-63NFW-FWHDR-F4J43-972K8 |
Developer Preview N (PrereleaseN )[c]
|
T87VG-N82DX-9Q7G4-67CHR-KBPMB |
Developer Preview ARM (PrereleaseARM )[b]
|
D9HNY-JTJDK-BQM84-K3VTB-JK4D3 |
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.
- An issue with the Microsoft Basic Render in ARM32 builds 7996-8038 (where the text has some black stuff around it) has been fixed in this 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 initial ARM32 image dump:
winload.efi
is from6.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 (usingdonothingpolicy.pol
andNOINTEGRITYCHECKS
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
- The original binary from build 8061 is located in
acpi.sys
is from6.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
- The original binary from build 8061 is located in
partmgr.sys
has two jumps patched to prevent functions from returningSTATUS_MEDIA_WRITE_PROTECTED
. The original version is still in theDrivers
directory, namedpartmgr.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:
fbl_core1_mobile_dev
) onwards, 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.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
from8E D3
toDC E3
(PE checksum correction). - 19 bytes at offset
0x15B96
from63 6B 17 93 02 23 18 93 94 F8 3E 30 13 F0 02 0F 01 D0 01
to23 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
from45 47 49 54
to47 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
to69 62
(PE checksum correction). - 06 bytes at 0x0233A from
04 DB 02 9B 13 B9
to00 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]
- Windows Runtime applications' titles are not printed correctly and instead spew the full application user model ID (
AumId
).
Desktop Window Manager[edit | edit source]
- Disabling and re-enabling composition and then invoking the left-hand Charms menu may cause the Desktop Window Manager to crash and generally destabilize unless the right-hand Charms bar is invoked.
Miscellaneous[edit | edit source]
- 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.
- Logging off might result in a
DRIVER_OVERRAN_STACK_BUFFER
bugcheck.
ARM32-compile specific[edit | edit source]
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.
- 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. 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.
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.
Gallery[edit | edit source]
ARM32 compile[edit | edit source]
Control Panel system properties section
Setup and OOBE[edit | edit source]
Windows Update settings
Redpilled state[edit | edit source]
Task Manager in compact mode
Immersive Internet Explorer 10
Metro OOBE[edit | edit source]
x86 compile[edit | edit source]
Free variant[edit | edit source]
OOBE[edit | edit source]
Desktop[edit | edit source]
Checked variant[edit | edit source]
Redpilled Windows Explorer
winver
(Developer Preview N)Redpilled
winver
(Developer Preview N)
Screenshots uploaded prior to publication[edit | edit source]
Control Panel and keyboard layout picker
Notes[edit | edit source]
- ↑ 1.0 1.1 The Starter edition (and its N counterpart), last included in Windows 7, had since been internally repurposed during Windows 8 development to act as a base for new and existing Windows client SKUs. The Web Server edition would also be identically repurposed during development of its server counterpart for both Desktop Experience and Core editions, although Standard Server would later take its place as the base for Server Core editions during the late development phases of Windows Server 2016, specifically during Redstone 1 development.
- ↑ 2.0 2.1 2.2 2.3 2.4 2.5 2.6 2.7 Only available in the unstaged ARM32 or x86 debug compiles or via manually staging it on the x86 retail image.
- ↑ 3.0 3.1 3.2 3.3 3.4 3.5 3.6 3.7 Only available on the unstaged ARM32 or x86 debug compiles.