Draft:Windows build FAQ

This is a help page to deal with the common questions that people ask when dealing with Windows builds.

What's the "Build " text at the bottom-right corner of the screen?
The Build text is what is known as a build string. The build string is a way for builds to be uniquely identified. It began being used around the turn of the millennium, shortly after the transition from the Source Library Manager (SLM) version control system, used since 1986, to the Perforce-based Source Depot, in June 1999. Until late 2016 (before the reproducible builds effort), it was also embedded in the version information of all files. It takes the form:

a.a.xxxx.y.cccccccc.dddddd-dddd (a.a not displayed on desktop)

where:

An example build string:  means that it is Windows version 6.2 (Windows 8), build 7950, delta/revision is 0, compiled in the   branch, started on 23 February 2011, at 18:20. The time is Pacific Standard Time (PST), the time zone of Microsoft's Redmond campus, where the server farm that builds Windows is located.

Before the turn of the millennium, only a build number was used; service packs usually increment the delta, and in later versions incremented the build number by one. This is also the same for later Windows 10 versions that were not full upgrades.

How are builds found?
Since 2014, Microsoft flights builds - since 2016 typically from the  branch - to Windows Insiders on a regular, usually weekly basis, unless a release is nearly completed, in which case a different branch is used. Before then, most builds came from the Ecosystem Engineering Access Program (EEAP), or a similar beta testing program such as the TAP (Technology Adoption Program) or the Microsoft Beta Evaluation Program. The EEAP is a program where builds were sent out weekly to companies that are in the Microsoft Partner Program and work on Windows drivers for their hardware, as well as Windows applications. These builds can be from a variety of branches depending on the specific needs of the partners they are being sent to. Microsoft has also historically done beta testing programs for IT professionals and the general public (Windows Me is an example of this, with weekly mailings of discs to beta testers), in some cases involving millions of people (such as in the case of Windows Vista). These builds, as a result of their wide distribution, are far more likely to be publicly leaked. Additionally, builds can sometimes be discovered in the personal archives of ex-Microsoft employees after they leave the company, typically in the form of a burnlab disc or floppy.

What's a branch / why are some builds with lower build numbers compiled later? / Why do some builds with the same build number have different features?
Microsoft has thousands of developers working across Windows, Azure, and Xbox at any given time. If they all checked in code to the same codebase, there would be endless merge conflicts as different teams tried to merge at the same time. The OS would also be very unstable as code would be checked in as soon as it was written without being tested or integration tested to ensure it works with other components of the operating system that are also changing. To solve this, branches were introduced. To put it simply, each subteam (of around 25 developers) has their own branch, where changes specifically for their features are checked in, Then, on a schedule, each branch is reverse integrated into the mainline branch and integration tested to ensure compatibility with changes from other teams. All check-ins require a code review and approval from the development lead of each team, as well as testing, before they are allowed into the build for quality control purposes.

Initially, branches were grouped by a general area of Windows, and were simply numbered, with labs 1-7, 10, and 21 known to have existed ("_N" suffix branches was used for reverse integration). This was used for Windows XP, Windows Server 2003, and Longhorn pre-reset. It was eventually decided that this system was too unwieldy and led to components not being sufficiently integrated, causing unstable builds and contributing to the failure of the original Longhorn project. It was then decided to create a branch for each individual team, with several levels of branch reverse integrating into each other. Although this did lead to some incredible crapfests, such as the shut down menu that took 24 people and two years to design, it generally worked and is still used to this day. Initially this was called the VBL (virtual build lab) system, but it was later renamed to feature branch level (FBL) for Windows 7.

How is Windows built?
Each day, for every branch in active development, a build is compiled on a daily basis on a virtual machine on one of Microsoft's build servers, using Microsoft's proprietary Razzle build environment. Any employee can track this live using an intranet link. Building takes approximately twelve hours (building of the actual binaries and then the "postbuild" process of building an image are about half and half of this time), and then the bits (SDK, DDK, VHD, ISO) for all compiled architectures and SKUs are dumped in the branch's dedicated folder on the internal  (originally called  ) network share in the  /  domain for a certain amount of time before expiring; the time before expiry depends on the status of the build (some more stable or important builds are kept indefinitely, and source code archives appear to be maintained at least back to Windows XP). For older versions of Windows, there was a physical room at Microsoft campus (called the "Build Lab", or the "Engine Room" for Windows 9x) where the build was assembled each day, and - for versions before Windows 8 - another room (in 2003 it was located in Building 27 on Microsoft campus) where physical discs would be burned for builds that passed sufficient testing to be used internally.

How is Windows tested?
Builds from non-main labs are typically tested by the teams responsible for them.

For the main branch (currently, historically   between 2000 and 2004, followed by  ,  ,  ,   and  ) or any milestone or public release branch, if no build break (Microsoft slang for a compilation failure) has occurred during the approximately twelve-hour compile process, an SDET (software design engineer in test, Microsoft's pre-2014 term for a tester) would install and boot the OS on a machine (in the current day, most likely in a Hyper-V VM) to ensure basic functionality. This would then be followed by BVT testing, where basic functionality and verification of components is done. If this passes, it is marked as TST (or, in modern parlance, pushed out to the Canary ring), where Windows developers that have opted in then install it and develop using it. At the same time, the build is tested on a very wide range of hardware (it is not clear if this is still done) is done to attempt to find issues caused by strange hardware configurations or edge cases, as well as stress testing every component of the operating system for several hours in order to ensure quality. This is the practice of "eating your own dog food", or dogfooding for short, where the operating system is developed on itself. This is intended to force the developers to fix bugs that they are experiencing, instead of ignoring them as they are not affected by them. Applications testing is then done to ensure compatibility with third-party applications - backwards compatibility is a priority for Microsoft and in most cases the operating system is designed to work around the application instead of Microsoft instructing the application vendor to fix odd behavior or update the app. Any discovered bugs, at least in 2004, were assigned to developers at a daily 9:30 AM meeting known as "War Room", infamous for its fervent atmosphere with regular shouting matches.

For older versions of Windows (before Windows 7), additionally stable builds could be declared "IDW" (internal developer workstation), implying that they were safe to be used for development, and more stable builds "IDS" (internal developer server), implying that they were stable enough to be used for hosting internal servers, or released to the aforementioned EEAP or one of its predecessors. These days, builds from the Insider branches are flighted weekly if they are stable enough for general public use and are deemed stable enough during their times in the Canary and Dev Internal channels.

Bugs were initially tracked using a text file for Windows 1.0. For Windows 2.0, a bug database called "RAID" was written by several developers in the Microsoft Apps division; the name is based on a brand of insecticide sold in the United States that "Kills bugs dead", and a can of bug spray was used for the application's icon. This was used until approximately 2002, when architectural limitations (the tool was limited to a total number of 32,767 entries, so a new database had to be created every 32,767 work items - Windows 95 went through three databases between 1992 and 1995, and comments in the Server 2003 source code dated early 2002 mention the "NTRAID9" database being used for early Longhorn development), as well as scalability issues (by Windows XP, users had to be manually disconnected for meetings due to the number of connections to the database) resulted in the scrapping of RAID and the creation of the "Product Studio" tool, which had a three-tiered architecture for scalability purposes (although suffered issues with its middle tier failing to connect), and added various features including file attachments. Product Studio was used for the development of Longhorn (after 2002), Windows Vista, and Windows 7, as well as early development of Windows 8 (with Windows 8 build 7746 having an internal bug reporting tool that requires Product Studio to function).

In approximately 2010 or 2011, the work item tracking system was moved to an on-premises Azure DevOps Server (then called Microsoft Team Foundation Server Visual Studio Team Foundation Server, Visual Studio Online, and then Visual Studio Team Services before receiving its current name), and this is currently used for work item tracking and team management.

How is a Windows version developed?
While no two Windows versions have identical development patterns owing to the unpredictable nature of software development, all NT versions up to Windows 10 generally followed a similar development methodology.

Before Windows 10
At the start of the project, usually several months or even years before the completion of the previous version, planning for the version begins. This was usually when the codename is created. As the previous version approached completion, more detailed plans, team charts, and in some cases even early development work would be started. After the previous version was completed, development would progress along a series of milestones. These were specific dates by which certain levels of completion must be reached - early versions instead called these "development releases", or had a more traditional "Alpha" stage). After the final milestone was completed, work would then commence towards a sometimes relatively feature-complete (such as Windows 7 build 7000), sometimes extremely not feature complete (such as Windows 2000 build 1671, Windows XP build 2296, Windows Vista build 5112), "beta" version, and "beta" versions would be released until the product was essentially feature complete. Then the release candidate phase would commence, which mostly focused on tweaking the user experience, fixing bugs, and making any final changes. After several release candidates, a branch would be created for RTM, and final stabilization work would commence. Eventually, some build would be declared RTM (21 days without any showstopper bugs reported was the requirement in the mid-2000s) and sent off for manufacturing. By the time it was available in stores to buy ("general availability"), further updates to fix bugs would be released.

Windows 10 and later
Windows 10 scraps the concept of a rigid 3 to 4 year development cycle to instead focus on semesters, which are worked on in parallel and are designed to deliver features quickly (originally six-months, but extended to one year in 2022 with Nickel). Semesters initially had their own codenames, but they were later changed when the Windows and Azure groups were merged. Milestones are still internally used for each semester, but there is no beta or release candidate as such. Major changes can occur to the product between RTM and GA, as was the case with the Cobalt semester. Typically a new semester is started when the previous one branches for RTM (creating the *_release branch).

What version control system does Microsoft use?
Before February 1986, Microsoft used Berkeley SCCS, the first ever version control system. After this, they moved to an internally developed clone of RCS called SLM (Source Library Manager). The source code to this version control system is available in the 782 and NT4 source, and a binary is available in the original Xbox OS source code. It did not support branching and tracked only single files, a là CVS. This made it unsuitable for large projects.

In 1999, due to the Windows 2000 project showing that over 1,500 developers checking into primarily (branches existed but required manual copy of the entire Windows source code, which was several gigabytes in size at the time) a single tree was not feasible, Microsoft forked Perforce and renamed it to Source Depot, continuing to add features such as a GUI for changes and increased ability to handle very large projects. This greatly benefited development as it supported branching and many other features SLM was not architecturally capable of handling. This solution sufficed until 2017, when the number of branches reached a point where Source Depot was struggling to handle the size of the Windows project - branch creation took several days. This prompted Microsoft to move to Git (specifically using Team Foundation Server/Azure DevOps), which was completed for most teams in late 2017 with the creation of the "OS" repo. However, even Git is not large enough to handle the size of the Windows project (over 500 GB in code and assets by 2018), and a new repo is created approximately every three years to avoid hitting Git theoretical limits and no longer allowing push. The current repo is OS.2020.

It is noteworthy that neither Microsoft Delta or Visual SourceSafe, Microsoft's publicly available version control solutions, were ever used by the Windows team, in part due to their infamous reputation caused by their questionable quality.

Do any Windows versions have their source code leaked?
Yes. Windows NT 3.5 RC2, Windows NT 4.0 SP1, Windows 2000, and most of (enough to get a working build with some workarounds) Windows XP SP1 and Windows Server 2003 (as well as parts of Bing and Cortana), as well as the original Xbox OS and ~2005 version of Xbox Live, have had their source code leaked publicly.

Why do builds expire after a period of type?
Microsoft did not want these builds being used after the testing period was up. This was first implemented in the Korean version of Windows NT 3.5, but it was not used generally until Windows 95 and Windows 2000. The OS will either fail to boot, login, and/or turn off various functionality such as personalization. This is not related to Windows Activation. Some builds can be debombed, but instructions on how to do this will not be provided (see "How do I bypass or get rid of the timebomb or activation?" section below).

On builds that have a timebomb, you must set the BIOS date back to before the timebomb expiration date. Alongside, most builds of Windows 10 before version 1703 requires having online time sync disabled (via means such as turning off the network adapter), otherwise the timebomb will still instantly activate and brick the system.

Can I have ?
No, we don't provide the builds since this wiki is only a knowledge base for these builds. You need to find the builds yourself.

What virtualization software should I use?
If you are running classic Windows (Windows 1.x to 3.x and 9x) or earlier NT builds (Windows NT 3.x and 4.0), then emulators such as 86Box are recommended, which emulates systems in lieu of virtualizing them using a hypervisor and is therefore more accurate to the quirks of these early builds, as well as having more configuration capabilities. Usually, these early builds can boot in hypervisors, but there will be bugs that would not occur in emulator and there will often have very little to no driver support compared to emulating a system manufactured at the time. For more recent builds (Windows XP and later), they will run fine and faster on a hypervisor, but you may need to use compatibility settings or older versions of the products to get specific features working. Your mileage may vary; check the BetaWiki page for the build you're trying to test before installing. Remember, this is pre-release software and can therefore be unstable or do things you would not expect.

How do I use ?
The best thing to do is to refer to the documentation that might be provided with the hypervisor or emulator you are using. If you cannot find the documentation, they are usually also available online:


 * 86Box: https://86box.readthedocs.io/en/latest/index.html
 * DOSBox: https://www.dosbox.com/DOSBoxManual.html
 * QEMU: https://www.qemu.org/docs/master/
 * Hyper-V: https://docs.microsoft.com/en-us/virtualization/
 * VirtualBox: https://www.virtualbox.org/manual/UserManual.html
 * VMware: https://www.vmware.com/support/pubs/

Please note that using Virtual PC 2007 (or any other version of Virtual PC) is not recommended and should not be done. It has compatibility issues, far less functionality than other hypervisors, is discontinued and out of date, has no network capability on Windows 10, almost certainly has unknown security vulnerabilities, and fails to run at all on 64-bit builds after 9879. Virtual PC has been replaced with Hyper-V, which regularly receives updates and works on current versions of Windows.

How do I set the BIOS date for ?
The aforementioned guide provides instructions on how to set the BIOS date for your desired hypervisor/emulator.

What configuration/settings should I use in my virtual machine?
The aforementioned guide lists various configurations that are recommended to run the build you wish to emulate/virtualize.

Can you provide me the product key for ?
No, we do not provide these for obvious legal reasons.

My ISO won't boot
Some ISOs are not bootable. Most retail installation media for Windows 9x versions are not bootable, and no version of Windows NT before Windows NT 4.0 have a bootable CD installation media. For most versions before Windows 2000, you will need a boot disk. If there is no boot disk provided, use a boot disk from Windows 95/98SE and use that to run setup. For classic Windows, find  in the   directory and run it. For NT-based Windows, find  in the   directory and run that. This is not supported for Windows Longhorn build 3683 and later, and by this point most installation media should be bootable. For these versions, check the BetaWiki page of the build you are testing for instructions. Alternatively, you can upgrade from an earlier build.

How do I run non-x86/x64 versions of Windows without having a machine that supports it?
You would need an emulator for that specific architecture of Windows that you will be running. However, more complex or rare architectures will often not have an emulator that can run Windows, in which case you must use real hardware.

MIPS
Use QEMU, which can run most MIPS versions of Windows NT builds, with exceptions such as the earliest publicly available builds of Windows NT 3.1. For those, use MAME. Windows NT 3.1 build 239.1 requires manual fixing of the boot entry in ARC to boot.

PowerPC (PPC), DEC Alpha AXP, and Itanium (IA64)
There are presently no emulators that supports running Windows on the PowerPC, Alpha AXP, or IA64 architectures, and real hardware is required to run builds compiled for these architectures.

Itanium 1 and Itanium 2 are not compatible, and builds that do not have Itanium 2-specific considerations will fail to boot on any system that is not an original Merced. This is the case for the original IA64 Windows XP release.

ARMv7/ARM32
QEMU will boot and install most ARMv7/ARM32 builds of Windows currently leaked (generally speaking, 800x ARM builds or higher will generally work in QEMU, builds below 8000 are currently thought to be impossible without the correct firmware/board/BSP combo), though it should be noted that at the moment due to support being in such an early state, Windows 8.x ARMv7/ARM32 builds in QEMU are relatively unstable as of May 23, 2022.

ARMv8/ARM64
Early ARM64 builds of Windows 10 (TH2-early RS2) were designed with the Snapdragon 810 (8994) as a testing platform, but are still able to be installed via QEMU. Later ARM64 builds of Windows are more generic out of the box and should work with QEMU as well, however do note that the greater amount of services running on later builds can imply a significant performance penalty.

How do I bypass or get rid of the timebomb or activation?
Put simply, you don't.

For the long answer, the majority of the methods used to remove the timebomb or activation are not so legal, so we will not provide any help for you on this.

How do I run Windows CE / Mobile / Phone 7.x?
For earlier versions of Windows CE you will either need a physical device or the Platform Builder. This was not free software and is therefore not provided here. You will need to find it yourself. Finding other versions of Mobile is similarly left as an exercise to the reader.

Early DOS-based Windows - "Incorrect DOS version" on DOS 5 or later
These versions have a faulty version check that rejects any version that is not DOS 2.x or 3.x. This also applies to DOSBox. You will have to use the SETVER utility on WIN100/200.BIN in order to report a version of 3.31 to this application, so it satisfies the check.

Early DOS-based Windows - partition size limited to 32 MB
This is a FAT12 limitation and a DOS issue. You will need to upgrade to a version of DOS that supports FAT16, which is DOS 4.0 or later, as well as Compaq DOS 3.31 (developed with Microsoft's assistance), in order to install a larger drive.

Windows 1.0 - does pre-DR5 exist?
Yes, there are at least two versions confirmed to exist, but good luck getting it.

Windows 2.x - why are there no beta builds?
Because none of them have been found yet!

Windows 3.00.14 - MS-DOS Executive fails to load
If you get Windows started, but the MS-DOS Executive fails to load or hangs, the  option, determining the maximum number of allowed file handles, is not set to a sufficiently high value. A value of at least 40 is needed for Windows to successfully boot. Additionally, if Windows fails to start, attempt booting it on Compaq DOS 3.31. This is the version that was used internally at Microsoft in early 1989 when this build was compiled and seems to be the most stable.

Windows 9x - setup prompts to insert the installation CD even if it is already inserted
This is caused by the issue that the required drivers to access those drives have not been installed yet. You will have to install the drivers manually, or boot into a DOS/Windows 9x boot disk and copy the  folder to the hard disk. In some cases, the CD-ROM driver might be installed but pointed at the incorrect drive; also try changing the drive letter setup requests for to.

Windows 9x - General protection error on boot
This is caused by having a CPU faster than 2.1 GHz. Windows 95 and early Memphis builds have faulty CPU speed checks that were not designed for fast processors, often leading to driver crashes due to division by zero errors. It can be fixed by using an emulator, underclocking the CPU with a frequency below 2.1 GHz, or using the FIX95CPU patch (this doesn't apply to the initial release of Windows 98).

Windows 9x - Insufficient memory to initialize Windows
This is caused due to having more than 1 GB of RAM (480 MB on Windows 95). A bug in the memory manager results in an allocation failure during the real memory scan, causing the system to not allocate enough memory for Windows and crash. To fix this, reduce the amount of RAM to below 1 GB/480 MB or add the line  to the   in the   section of the file, which forces Windows to access up to 944 MB of RAM.

Windows NT 3.1 build 196 - failure to boot after installation
The installation process for this build has an essentially random chance to succeed. As it is a batch file (the installer having not been written yet), the bootloader may not be written sequentially to the hard drive due to filesystem fragmentation. This will be indicated by the installer. If this occurs, you must reinstall the OS (do not reboot or you have a chance of boot failure) - if several reinstallations do not work the hard drive must be reformatted in order to install successfully.

Windows NT 3.1 (x86) - only detecting 64 MB of RAM
This is due to a bug in memory detection code that was separately created but has the same effect - memory will not be detected unless the memory between 1 MB and 15 MB returned by the BIOS functions INT 15h/E801h and INT 15h/88h is equal. Most BIOSes return different values to allow software to use memory between 16 and 64 MB, however the buggy algorithm for memory detection in x86 NTDETECT (as well as OS/2 2.x and 3.x) causes only 64 MB of RAM to be detected. This was fixed in NT 3.5, and can be rectified in NT 3.1 by using a BIOS that allows it to detect more than 64 MB, setting the  (or similar) option in the BIOS to "OS/2" (which will also fix NT 3.1), or simply upgrading to NT 3.5.

Windows NT 3.1, 3.5, and early 3.51 builds - paranoid processor detection
Windows NT 3.1 and 3.5, as well as early builds of 3.51, have a paranoid processor detection function that refuses to install the OS on any non-386, 486, or Pentium 1 system. This can be worked around by modifying  and   to always report a Pentium processor, or running an unmodified copy (there are some badly modified copies, notably the one on WinWorld (these copies are usually Advanced Server SKU and have a SETUP.INF modification date in 2003), that will never install due to having a bad workaround) under a 386, 486, or Pentium configuration in 86Box.

The line must be changed to  in both files in order to install correctly on newer hardware.

Windows NT - Invalid device request writing device BANANA / Setup failed to copy file
This is due to a conflict with the CD-ROM driver. In most unofficial Windows boot disks available, the CD-ROM driver might be named, which is the same name of a cursor file present in Windows NT. Either use an official Windows boot disk made from the Windows 95/98 SE setup, which has the correct  named driver, or edit the   and/or   files on the boot disk to not use this particular name.

Earlier versions of Windows - partition size limited to 504 MB
This is a BIOS limitation due to the system board lacking geometry translation. Use a different machine type.

Earlier versions of Windows - partition size limited to 2 GB
This is a limitation of the FAT16 filesystem. To rectify this problem, convert the drive to FAT32, NTFS, or some other filesystem. FAT32 requires Windows 95 OSR2 or Windows 98. Windows NT 4.0 (with a custom Winternals driver) and Windows 2000 also support FAT32, but for NT-based OSes, NTFS is recommended anyways (the main circumstance you would need to use FAT when dealing with an NT-based Windows installation is for testing the Neptune Fastboot functionality).

Windows 98 includes a GUI tool to convert a drive to FAT32, and Windows Me includes a DOS-based conversion tool. For Windows 2000 and later, the command, followed by a reboot, will convert a drive to NTFS.

Earlier versions of Windows - partition size limited to 137.4 GB
This is a driver limitation - the hard disk driver installed on the OS does not implement 48-bit LBA, which means that the hard drive capacity is limited to the 28-bit LBA limit of 137.4 GB. This usually cannot be resolved without a hard disk driver update.

Windows 98 & 2000 (early builds) - regular BSODs, especially at shutdown
This is due to having ACPI enabled on builds that do not have a stable ACPI implementation, which is most builds of Windows 98 (which only has partial ACPI support) and early builds of Windows 2000. This notably applies to hypervisors such as VMware and VirtualBox. This can often also lead to setup crashing. To run these builds without BSOD shutdown, turn off ACPI in the .vmx/.vbox file, use 86Box or a similar emulator, or change the operating system in the VM config to Windows 95 (for 9x builds) or Windows NT 4.0 (for Windows 2000 builds), which will turn off ACPI and allow these builds to cleanly shutdown.

Windows 2000 - reboot during last stage of setup
This is a timing bug in the hard disk driver on later builds of Windows 2000, including the final build. This prominently applies to VirtualBox, but can also happen on faster hardware if there isn't a delay to complete setup operations without corruption. To fix it, you can:
 * Use 86Box or a similar emulator to workaround the timing bug.
 * Click and mash keyboard keys really fast. This increases the amount of instructions the system has to handle, possibly being enough to get past the timing bug.
 * VirtualBox has a workaround command to add an artificial delay. Run the following command in a command prompt before the GUI installation in the VirtualBox installation directory:  After installation finishes, this key should be removed or set to 0, otherwise IDE instructions will run slower.

Windows XP and Longhorn - Setup did not find any hard disk drive installed in your computer / bugcheck during setup
This is possibly a result of using a SATA drive, which is not supported on Windows XP, all pre-reset Longhorn builds, and early post-reset Longhorn builds. Either switch the hard drive controller to IDE, set the SATA controller in the BIOS to IDE Legacy mode, or provide a SATA driver for Windows to use via the F6 key when setup prompts to do so while booting (only works on I386 installation method such as Windows XP and Milestone 3 Longhorn builds).

Windows 7 - I can't find some features
Microsoft wanted to hide features from the general userbase throughout the development of Windows 7, but Windows 7's lockdown system was substantially weaker than Windows 8's substantially improved system, and the system was bypassed in 2008 by the original BlueBadge tool, before being improved in 2020 with the Bluepill tool - it can be found here.

Windows 8 - there are missing features in the screenshots / where is Metro?
If you are running a build before 7814, it's not there. If you are running a later build, it's because Microsoft didn't want you to see it. Thankfully, some clever folks have managed to get around their attempts. The protection system is called Redpill, and you can read more about it there if you wish. The primary tool to unlock features is Redlock, which can be downloaded at its page and run.

Windows 8 and later - early-boot bugcheck (0x5D)
This is because the processor's CPUID instruction is indicating that it does not support the SSE2 (build 7850+), PAE (8148+), and/or NX (8305+) instructions. This is required for Windows 8 and later; a newer CPU must be procured or the OS version field in the virtual machine configuration must be incremented to at least Windows 8.1.

Windows 8.1 and later - early-boot bugcheck (0x5D) /   (0xC4)
This is because the processor's CPUID instruction is indicating that it does not support the CMPXCHG16B, LAHF/SAHF, and/or PrefetchW instructions. This is required for Windows 8.1 and later; a newer CPU must be procured or the OS version field in the virtual machine configuration must be incremented to at least Windows 8.1. It may also be caused by the same issue that affects Windows 8.

Windows 10 RS1+ - There are some missing features / why can only some Insiders access a feature?
Insider builds of Windows 10 (after Redstone 1) and Windows 11 contain features that are locked down by a decentralised feature control system called Velocity; some of these features are cut at compile time, and others can be remotely turned on or off at Microsoft's discretion. Features do not need to respect their enablement state. In some cases, A/B testing is used and only a subset of insiders receive a feature; Microsoft does this for features that are in an unfinished state and these features will only unlock for all remaining Windows Insiders in a later build when they reach a state where they are nearly finished. If you want to observe the hidden features in these builds that utilize them, you need to download a tool such as ViveTool and manually twiddle the feature IDs; they will reset every so often as the feature configuration is manually reset from the Internet.

In some cases, features are unintentionally made available for enablement due to branch exclusion lists (an example of this is tabbed file explorer in Nickel builds), and some are switched from AlwaysDisabled several Insider builds before they start rolling out (such as Nickel's Task Manager redesign).