Draft:Windows build FAQ

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

General questions

What's the "Build <number>" text at the bottom-right corner of the screen?

Main article: Build tag

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:

Component	Meaning
a.a	NT version number (major.minor)
xxxx	Build number
y	Build delta / revision, which indicates applied update/Quick Fix Engineering (QFE) version, or is being used to differ builds intended for wide audiences such as public and OEMs from the ones intended for internal/development purpose which, usually, start from revision number 1000.
cccccccc	Build lab
dddddd-dddd	Date and time of start of compile in the format yymmdd-hhmm

An example build string: 6.2.7950.0.winmain_win8m2.110223-1820 means that it is Windows version 6.2 (Windows 8), build 7950, delta/revision is 0, compiled in the winmain_win8m2 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.

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

From Windows Vista RC1 to Windows 10 (original release), the build delta needed to be multiple of 16, being in a range of 16384-24575 before being released to the public. This limitation resulted in Windows Server 2008 (and unofficially also Windows Vista) incrementing the build number from 6002 to 6003 with a security update released in December 2019, but otherwise it is not that notable.

What's the difference between the free and checked/debug builds?

Prior to Windows 10 April 2018 Update, builds of Windows are generally compiled in two kinds: The free (fre, or retail) compile, which has all compiler optimizations enabled and is used in production environments (i.e. regular usage), and the checked (chk, or debug) compile, which has many compiler optimizations disabled and enables a large number of debugging checks in the operating system code and system-provided drivers to help identifying and diagnosing problems in driver development. Such compiles are larger in size and perform slower than the free compiles, and therefore it is advised to use the free compile whenever possible, unless it is necessary to use the checked compile to identify serious problems in driver development, or a build is only available in the checked compile.

Builds of Windows 10 April 2018 Update and later versions are only available in the free compile, and Microsoft suggests using tools such as Driver Verifier and GFlags to check driver code in those versions.

How are builds found?

Since 2014, Microsoft flights builds - since 2016 typically from the rs_prerelease 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 do some builds with lower or identical build numbers have different compile times and/or features?

Main article: Build lab

Microsoft has thousands of developers working across the Windows, Azure, and Xbox divisions 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 simply numbered, with labs 1-7, 10, and 21 known to have existed ("_N" suffix branches were 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 lengthened conflicts, such as Windows Vista's shutdown 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, symbols) for all compiled architectures and SKUs are dumped in the branch's dedicated folder on the internal \\winbuilds\release network share (originally called \\ntbld\) in the NTDEV/ntdev.corp.microsoft.com 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 3.0, and probably earlier). 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 main, historically main between 2000 and 2004, followed by winmain, th2, rs1, rsmain and rsmaster) 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 attempt to install and boot the OS on a physical 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) 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 2000, were assigned to developers at a daily 9:30 AM meeting known as the War Room, infamous for its fervent atmosphere with regular shouting matches.

Prior to Windows 7, stable builds could be additionally be declared as IDW (internal developer workstation), implying that they were safe to be used for development purposes, and more stable builds marked as IDS (internal developer server), implying that they were stable enough to be used for hosting internal/non-production servers or released to external partners via the Ecosystem Engineering Access Program (EEAP) or its predecessors. Since 2016, builds from the Insider branches are flighted to users participating in the Windows Insider Program on a weekly basis if they are considered stable enough for general public use and within the internal Canary and Dev flight channels.

Bugs were initially tracked using a text document 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 limited the bug tracking tool to a maximum number of 32,767 entries, which resulted in new databases being created every time it overflowed. 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. Scalability issues also impacted the usability and efficiency of RAID (during Windows XP development, users had to be manually disconnected for meetings due to the number of connections made towards the database) and ultimately resulted in the database system being scrapped entirely, with it being replaced by the Product Studio tool, which had a three-tiered architecture for scalability purposes and added various features including file attachments (although it was impacted by issues such as its middle tier failing to connect properly). Product Studio was throughout the development of Longhorn (from 2002 onwards), Windows Vista, and Windows 7, as well as early development of Windows 8 (with build 7746 featuring an internal bug reporting tool that depends on Product Studio for full functionality).

In approximately 2010 or 2011, the work item tracking system was moved to an on-premises Azure DevOps Server (which went through several name iterations from Microsoft Team Foundation Server to Visual Studio Team Services before receiving its current name). It is the current system 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

Main article: Windows as a service

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 source code files of Windows NT 3.5 build 782 and NT 4.0, 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" repository. However, even Git is not scalable 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 large portions of Windows XP Service Pack 1 and Windows Server 2003 (which are enough to get a functioning build with some additional tweaks), as well as the original Xbox operating system and ~2005 version of Xbox Live, have had their source code leaked onto the public internet.

Portions of the Bing and Cortana source code were also publicly leaked in March 2022 as part of a series of leaks that targeted large corporations such as Nvidia and Microsoft.

Why do builds expire after a period of time?

Main article: Timebomb

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, restarts itself after hours of use (often with END_OF_NT_EVALUATION_PERIOD bugcheck), and/or turn off various functionality such as personalization. This is not related to Windows Activation. On some builds, this restriction can be removed (a process known as "debombing"), 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 (with means such as turning off the network adapter or disabling the Windows Time service), otherwise the timebomb will still instantly activate and brick the system.

What's the difference between a "staged" and "unstaged" build? How is the Windows image assembled?

Every Windows edition starting from those included in Windows Vista/Windows Server 2008 onwards are assembled from a raw set of components that eventually form the final resulting operating system image, otherwise known as "staging".

An unstaged build is an operating system image that is yet to be assembled and only features the base foundation packages, schemas and registry hives required for assembling the actual operating system image, of which namely contains the image-based servicing stack acting as the main component for the Windows Setup application. Each individual component features a manifest containing a list of associated files, registry entries and permissions to apply onto the image (if applicable), of which are accompanied by a respective update package manifest containing metadata used by the servicing stack to facilitate the installation of such components. These components are located within a central directory otherwise known as the "side-by-side component store", or WinSxS in short.

Windows editions are essentially assembled through the use of an XML file that contains a complete list of operating system components (otherwise referred to as "updates") to install within the image; the hashes of such are verified against an applicable Base64-encoded SHA-1/SHA-256 hash (located within the component manifest) and matched with one located within an update package manifest's appropriate signed catalog file. This same mechanism is also used by the Windows Update feature to apply operating system patches to an existing image, replacing older versions of system components with newer variants.

Likewise, a staged build is a fully-assembled operating system image built by the Windows servicing stack.

Emulator/hypervisor questions

Can I have (specific Windows build)?

No, we do not provide the builds as this wiki is simply a knowledge base for Windows versions. You will have to find the builds yourself; the Internet Archive and WinWorld are typically good starting points for locating these builds, although be wary of any fakes that you might come across on the Internet.

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, 4.0 and 2000), 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 an 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.

We generally advise that you try to run certain builds on period-correct hardware instead of virtualizing them, if possible. Some features such as the Desktop Window Manager included as part of early post-reset Windows Vista builds do not function at all in a virtualized environment and will only work under specific real hardware configurations commonly used at the time of compilation. When dealing with ARMv7 Windows NT builds from Windows 8 onward, it is overall better to utilize physical hardware such as the Microsoft Surface RT or the Dell XPS 10 to obtain optimal performance, as opposed to emulating them due to poor overall compatibility (as of writing).

How do I use (hypervisor/emulator)?

The best method to utilize a specific hypervisor or emulator is to consult official documentation that may be provided with the hypervisor or emulator you are using. If you cannot find documentation for your hypervisor/emulator, they are also usually 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://learn.microsoft.com/en-us/virtualization/
• VirtualBox: https://www.virtualbox.org/manual/UserManual.html
• VMware: https://docs.vmware.com/en/VMware-Workstation-Player/index.html, https://docs.vmware.com/en/VMware-Workstation-Pro/index.html

Please note that all versions of Virtual PC are not recommended for use as it has been discontinued since the release of Windows 7 Service Pack 1, offers less functionality than other hypervisors, is highly susceptible to unknown security vulnerabilities, and lacks proper support for newer versions of Windows (both as host operating system — Windows 8 and later versions do not allow installation of Virtual PC by default, along with no networking support on Windows 10, and fails to run at all on 64-bit builds after 9879 — and as a virtualized operating system, with no official support beyond Windows 7). Virtual PC has been succeeded by Hyper-V, which regularly receives updates, offers a wider subset of functionality compared to its predecessor, and works on current versions of Windows.

How do I install a specific version of Windows?

Main article: Draft:Windows installation guide

The aforementioned guide provides instructions on installing the most common versions of Windows onto an x86/x64 system.

How do I set the BIOS date for (hypervisor/emulator)?

Main article: Draft:Setting BIOS date

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?

Main article: Draft:Recommended VM configurations/Windows

The aforementioned guide lists various configurations that are recommended to run the build you wish to emulate/virtualize.

Can you give me the product key for (RTM build/build that uses retail keys)?

No, we do not and cannot provide these product keys for obvious legal reasons. For modern releases of Windows NT (from Windows 7 onwards), generic product keys for your build (which cannot be activated against Microsoft servers) may be found in the product.ini text document within the sources directory of your installation media. Generic volume licensing product keys (GVLK/KMS keys) for your version of Windows (which are published by Microsoft themselves) may be found within official Windows Server documentation.

The only exemption to this rule is for versions of Microsoft products that use the Modulo-7 algorithm (such as Windows NT 4.0 and Windows 95), which are typically activated with a key such as 111-1111111.

Why won't my ISO image boot?

Some ISO images are not bootable by default. Most retail installation media for Windows 9x versions are not bootable, and no version of Windows NT before Windows NT 4.0 have bootable CD installation media. For most versions before Windows 2000, a boot disk is required to install Windows. If there is no boot disk provided, use a boot disk from Windows 95/98 SE and use it to partition your disk drives and run setup. For Windows 9x, find setup.exe in the WIN9X (or a similar) directory and run it. For NT-based Windows releases, find and run the winnt.exe executable in the i386 directory (preferably with the /b switch if available).

The ability to install Windows via MS-DOS was removed in Windows Longhorn build 3683 and later, and by this point most installation media should be bootable. For these versions, it is advised to look through your build's respective page for any additional installation instructions. You can alternatively upgrade from an earlier build, but this option does not always work on most builds as a result of artificial or technical limitations.

How do I run non-x86/x64 versions of Windows without having a machine that supports it?

You will require an emulator targeted towards the architecture of the specific build you will be running, although more complex or rare architectures will often not have an emulator that can run Windows or other operating system, in which case you will need to use real hardware.

MIPS

Main article: Draft:Installing Windows NT on MIPS

QEMU is able to run most MIPS architecture compiles of Windows NT builds. Some builds, such as the earliest publicly available builds of Windows NT 3.1, fail to run within the aforementioned emulator and instead depend on MAME for full operation.

You must manually fix up the ARC boot entries for Windows NT 3.1 build 239.1 in order to boot into the build properly.

PowerPC (PPC)

Main article: Draft:Installing Windows NT on PowerPC

As of 2024, the only emulator that supports running Windows on the PowerPC is a fork of dingusppc that supports the required processor and hardware modes, alongside a third-party bootloader, HAL and drivers for the Macintosh system being emulated. Builds before Windows NT 3.51 build 1057.1 fail to run due to the emulated processor being incompatible.

DEC Alpha AXP, and Itanium (IA-64)

As of 2024, there are no emulators that support running Windows on the Alpha AXP, or both generations of the Itanium architectures, and real hardware is required to run builds compiled for these architectures.

Binaries compiled against the Merced and McKinley (+ later McKinley derivatives) microarchitectures are not interchangeably 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 IA-64 Windows XP release.

ARMv7

Main article: Document:Installing ARM32-based Windows 8 releases on QEMU

QEMU will boot and install most ARMv7 Windows builds that are currently available. Due to emulation support being in such a preliminary state, ARMv7 Windows builds are relatively unstable, with builds relatively close to the Windows 8 RTM escrow development phase failing to boot at all as a result of unsatisfied processor feature checks.

Builds 8042 through build 8422 (fbl_woa) and builds 9600.17031+ will generally work in QEMU, albeit with performance/stability issues and a lack of appropriate in-emulator hardware support. Builds 8437 (fbl_dev_dp8) through 9600.16384 (winblue_rtm) will fail to boot due to missing hardware abstraction layer extensions for ARM timers and the emulator lacking support for the Cortex-A9 processor, used by the NVIDIA Tegra 3 SoC.

Generic ARM timers were implemented into the operating system very shortly after the compilation of the Windows 8.1 RTM build.

ARMv8/ARM64

Main article: Document:Installing Windows Server on QEMU (ARM64)

Early ARM64 builds of Windows 10/Windows Server 2016 (from Threshold 2 through early RS2) were designed for the Qualcomm Snapdragon 810 (MSM8994) processor as a testing platform, but are still able to be installed through use of the QEMU emulator. Later ARM64 builds of Windows (from Windows 10 Fall Creators Update onwards) 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 exhibit 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 and/or cause unintended breakage, and we are therefore unable to provide any assistance on this subject.

How do I run Windows CE / Mobile / Phone?

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.

Versions 3.0 and above of Windows CE are available as a hard disk drive image, which you can use with VirtualBox or 86Box, though as Windows CE was not intended to run on classic computers, you may experience some difficulties with it (like missing sound or small screen resolutions).

Some versions of Pocket PC, Windows Mobile, Windows Phone, and Windows 10 Mobile are included in Microsoft Visual Studio to aid development and testing of applications on those operating systems without the need of physical devices, but for the same reason above, they're not provided here as well.

Questions pertaining to specific versions

Build existence questions

Windows 1.0 - do pre-DR5 builds exist?

Yes, there are at least two versions confirmed to exist, but they aren't publicly available.

Windows 2.x - why are there no beta builds?

No pre-release versions of Windows 2.x have been made available as of 2024.

Hardware/software compatibility questions

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.

Earlier versions of Windows - partition size limited to 504 MB

This is a BIOS limitation due to the system board lacking geometry translation, and only occurs when using IDE drives. Geometry translation was not added to most BIOS until around 1993, and can be enabled by enabling large block access for the affected IDE group. If the BIOS does not have such option while the partition size being limited, try using a SCSI disk instead, as SCSI adapters are not affected by this limitation, or try using a different machine.

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 or when dual-booting Windows NT with DOS or Windows 9x).

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 convert c: /fs:ntfs, 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.

x86-based client releases of Windows - I have Physical Address Extension (PAE) enabled but can't use more than 4GB of RAM

This is due to arbitrary system licensing limitations for driver compatibility reasons. During the development of Windows XP Service Pack 2 (when the demand for 4GB or more RAM among regular consumers began appearing), Microsoft's own testing revealed that many drivers at the time were not written to properly work with physical addresses larger than 4GB, causing the drivers to truncate them, and consequently resulted in memory corruption and system instability.

As a result, Microsoft does not license you to use x86 client Windows with more than 4 GB of RAM, though note that each individual process is still limited to 4GB of RAM on x86, but the entire system as a whole can use more than 4GB. Server versions of Windows are licensed to allow for more memory use.

Windows XP and Longhorn - Setup did not find any hard disk drive installed in your computer / 0x0000007B 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).

Feature questions

Windows 7 - I can't find some features

Microsoft wanted to hide features from the general userbase throughout the development of Windows 7 to prevent them from being leaked, but Windows 7's lockdown system was substantially weaker than Windows 8's, 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?

Metro was not introduced until build 7779, although most major Windows 8 shell features were deliberately hidden by Microsoft behind an internal locking mechanism dubbed Redpill, the restrictions of which have since been worked around. The primary tool to unlock features is Redlock, which can be downloaded within its respective page.

Windows 8+ - How to install "edition upgrade only" SKUs?

"Edition upgrade only" means that the SKU can only be upgraded from a minor SKU. For example, the "Prerelease" SKU of some Windows 8 Milestone 3 builds can only be installed by upgrading from a minor SKU like "Starter" or "Home Basic". This can be done by two ways:

1. Upgrading the SKU from the installation media

1. Install Windows as normal. You should select a SKU that is minor to the one you want to upgrade to later.
2. At the first restart, restart into the installation media again.
3. Open the command prompt with Shift+F10 and enter dism.exe /image:[drive containing the installation] /set-edition:[SKU name] /productkey:[product key]
4. The upgrade takes around 30 minutes (depending on the SKU being upgraded) and completes when dism outputs a progress bar of 100% and the message The operation completed succesfully.
5. Restart into the new installation.

2. Upgrading the SKU from an existing installation

1. Launch sysprep from %systemroot%\System32\Sysprep, change the system cleanup action to "Enter System Audit Mode", tick the "Generalize" option and leave the other settings unchanged.
2. The system restarts again into the desktop of the Administrator account. In sysprep, tick "Generalize" again and set the action to "Quit".
3. Open the command prompt and enter dism.exe /online /set-edition:[SKU name] /productkey:[product key] /AcceptEula.
4. The upgrade takes around 30 minutes (depending on the SKU being upgraded) and completes when dism outputs a progress bar of 100% and the message The operation completed succesfully. You are prompted to restart the computer. Restart and go through the out-of-box experience.

Windows Server 2012 build 7788 (Redpilled) - the Start Screen is a blank white screen

This build's Start Screen has no items pinned by default (you will have to pin them yourself using the Pin to Start Menu ribbon item) and will not work without WDDM drivers. You will also need to create a new user account, as the default Administrator account has non-standard hives that are not compatible with Metro.

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 decentralized 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).

Notable bugs and quirks in specific versions

Note that some bugs might be exclusive to a specific version of Windows; please refer to the page of the version of Windows you are installing for any compatibility issues. It is also recommended to use hardware/VM configuration that is close to what was available at the time to reduce additional problems due to newer hardware.

Windows NT 3.1 and early 3.5 builds - Setup was unable to locate the hard drive partition prepared by the MS-DOS portion of setup

This occurs when setup is started by booting from a boot disk and the boot disk is unable to find the hard drive with the setup files, primarily due to a problem in the hard drive controller or attempting to run the boot disk without running winnt.exe, a setup preparation program for DOS included on the installation media. This can happen on any version of Windows NT with an I386 installation method, but is most notable on Windows NT 3.1 and early builds of Windows NT 3.5. On Windows NT 3.5 and above, you should run a floppy-less installation via winnt /b. On Windows NT 3.1, you can either switch the hard drive controller to SCSI or edit the TXTSETUP.INF on the first setup boot disk to remove the [MsDosInitiated] section at the end. For Windows NT 3.5 and above, edit the WINNT.SIF file on the second setup boot disk instead and change the value of MsDosInitiated to 0.

Windows NT - Invalid device request writing device BANANA / Setup failed to copy BANANA.ANI file

This is due to a conflict with the CD-ROM driver. In most unofficial Windows boot disks available (especially the ones available at AllBootDisks.com), the CD-ROM driver might be named BANANA, 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 driver name of MSCD001, or edit the CONFIG.SYS and AUTOEXEC.BAT files on the boot disk to not use this particular name. You can also boot into a Windows 98 CD and select "Start Windows with CD-ROM support".

Windows NT 3.5, 3.51, and 4.0 - Setup cannot format the partition because it is too large

Despite the NTFS file system having far greater partition size limit, the setup in these versions of Windows NT does not actually format partitions directly into that file system. Instead, setup formats them first to FAT16, then preforms a conversion to NTFS just before entering the GUI setup phase (in the case of Windows NT 4.0) or after that (in the case of Windows NT 3.5x). As such, a partition size limit of 4096 MB is imposed and you need to create a partition that is smaller than the said limit, then use a third-party partition manager software to increase the size of it.

Windows 98, 2000, and XP (early builds) - regular BSODs or freezing during setup or shutting down

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), early builds of Windows 2000, and early builds of Windows XP. This notably applies to hypervisors such as VMware and VirtualBox, and can often also lead to setup crashing (or for the case of Whistler, hang on "Setup is starting Windows 2000/Whistler"). Either edit the .vmx/.vbox file to turn ACPI off, use 86Box or a similar emulator, or change the operating system in the VM configuration 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 shut down properly. On physical hardware or 86Box, boot into the BIOS setup and disable ACPI from there. If there is no option for this, the machine likely does not have support for ACPI.

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, which can emulate older hardware more accurately.
• 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:

  VBoxManage setextradata <name of VM> "VBoxInternal/Devices/piix3ide/0/Config/IRQDelay" 1

  After installation finishes, this key should be removed or set to 0, otherwise IDE instructions will run slower.

• In VMware, this could happen on SCSI drives. Use an IDE drive if it does this.

Windows Longhorn (pre-reset and early post-reset) - partitioning/formatting

Some builds of Longhorn with a WIM-based setup may have problems properly partitioning and formatting a drive in the setup installer due to either early WIM implementation or a missing/corrupt VSSAPI.DLL file. This primarily applies to build 4001 and componentized builds (build 4081 up to the development reset).

For most builds with a Plex-themed setup, you should select the disk that Windows will be installed on (usually Disk 0) and select the "I want to format the drive (using NTFS)" checkbox; unallocated space cannot be selected. Builds with a Slate-themed setup has the option to create and format a new partition with the New and Format options. If the build is unable to partition or format properly, it may be possible to use the diskpart utility to create a new partition:

1. When setup loads to the "Welcome to Windows Setup" screen, press Shift+F10, which will open a command prompt.
2. Run the following commands in order:

   diskpart
   select disk 0
   clean
   create partition primary
   select partition 1
   active
   assign
   exit

3. Format the drive via the format command.

In the event that partitioning and/or formatting does not work (generally happens on componentized builds), you will need to use a different build's WinPE to format the drive. Additionally, you may have to restart the machine so setup can see the new partition properly. Upgrading to another build may also work, but be aware that upgrade setup is not available on most builds of Longhorn, and if it does, often fails.

Windows 8 / Windows Server 2012 builds - cannot boot in VirtualBox

Some builds of Windows 8 and Windows Server 2012, such as 7788, cannot boot in VirtualBox when paravirtualization is enabled. They will either loop with random BSOD error codes or triple-fault the CPU on startup. To fix this, use VMware (ideally with 9.x or 10.x compatibility) or turn off paravirtualization.

Windows 10 TH1 to RS2 - Recovery screen with error "A component of the operating system has expired" after setup

The timebomb instantly activated due to online time sync, which is present in every Windows build from Windows 8 build 8331 onwards. These builds (particularly 9833 to 14964) are flight-signed, meaning most of the system (including the boot loader) will no longer function when the timebomb goes off due to signature invalidation. You need to disable the network adapter (or unplug the cable if a physical machine is used) before setup until you are able to turn off the internet time sync in the Date and Time settings, otherwise the system will attempt to synchronize with an existing time server.