Geoff Chappell - Software Analyst
The NT Operating System Kernel (NTOSKRNL) is the defining module of the whole Windows architecture. This note is specifically about the different versions of the kernel as a file on disk. The generality of Windows version numbering is treated separately.
The kernel is distributed with each 32-bit Windows package in as many as four files:
This multiplicity is even without the complication of free and checked builds. The latter are offered by Microsoft as an aid to debugging and since they are explicitly not for real-world use they are all but ignored at this website.
PAE stands for Physical Address Extension. It applies only to 32-bit (x86) builds. The point to having separate builds for PAE is that the memory manager is specialised to use 32-bit or 64-bit page table entries. This is not a choice that will change mid-flight and so the loaded kernel is better to have code for only one or the other, not both. In many versions, users can make the choice at boot time, through the /PAE and /NOPAE switches in BOOT.INI or the pae option in the Boot Configuration Data (BCD). Later versions also allow indirectly for selection of the PAE kernel to be forced by a /NOEXECUTE switch or nx option.
An installed system has either the single-processor kernels or the multi-processor kernels but not both. If the multi-processor kernels are installed, they are renamed to NTOSKRNL.EXE and NTKRNLPA.EXE as if for a single-processor system. Starting with version 6.2, an installed system has only the multi-processor PAE kernel, already renamed to NTOSKRNL.EXE.
Put another way, the kernel’s standard name is NTOSKRNL.EXE, except that where the kernel may be installed both with and without support for PAE, the kernel has the two standard names NTOSKRNL.EXE and NTKRNLPA.EXE. In the versions that install both, the loader has the two standard names hard-coded. All versions can be directed to load an alternative as specified by a /KERNEL switch or kernel option.
The following 32-bit (x86) builds have been inspected for these notes. Most are from MSDN discs. Some, especially since Microsoft greatly reduced its shipment of operating systems on MSDN discs, are from service packs downloaded (typically as self-extracting executables) from a Microsoft website.
Special mention must be made of the very oldest builds. Even among the many discs that I retain from MSDN subscriptions in the 1990s, what was then the new Windows that is entirely its own operating system rather than a large DOS program goes no further back than Windows NT 3.51. For all practical effect, Microsoft informally disowned the early versions, even for its so-called Archive editions. For decades I had little choice but to treat Windows NT 3.51 as the dawn of time for these notes. In 2017 someone pointed me to an online collection of earlier builds. The sample is inevitably incomplete. The provenance is unknown. I have since sought more: the WinWorld online museum is notable.
Builds are arranged in increasing order of the file version as recorded in the executable’s resources. This version number is readily visible using Windows Explorer either in a so-called infotip for the file or by accessing the Version tab in the Properties dialog for the file. Programmers know this version number as coming from the so-called root block of the version-information resource, specifically from the dwFileVersionMS and dwFileVersionLS members of a VS_FIXEDFILEINFO structure.
The date stamp shown for each version is more obscure. File dates are easily modified after the executable is built and are anyway liable to be shown differently when read from different time zones. However, there is in each executable’s header a date stamp which is set when the executable is built and which is not commonly changed afterwards. It is readily accessible to anyone with programming knowledge and appropriate tools, e.g., Microsoft’s own DUMPBIN utility.
Any study worth making of Windows—and please remember that the list below exists only as a catalogue of which builds are studied—is much too intensive to cover pre-release builds, hot fixes and other updates. Access to pre-release builds anyway tends to come with constraints and compromise that other researchers may tolerate (and even be happy with) but which I do not. None of this work is done with any sort of assistance from Microsoft beyond the binaries, as published by the tens and even hundreds of millions, and the same documentation that’s available to all Windows programmers.
The kernel files for each build are listed in the order: NTOSKRNL.EXE, NTKRNLMP.EXE, NTKRNLPA.EXE, NTKRPAMP.EXE. Not all versions have all four. Versions before 5.0 have only NTOSKRNL.EXE and NTKRNLMP.EXE. Versions from 6.0 onwards are built with both single-processor and multi-processor kernels in the same pattern as for earlier versions, but the installation image on the distribution media has only the multi-processor kernels, and these are already renamed to NTOSKRNL.EXE and NTKRNLPA.EXE. Version 6.2 and higher have only the multi-processor PAE kernel, already renamed to NTOSKRNL.EXE.
|File Version||File Header Date Stamp||File Size||Package|
|3.10.511.1||2C921D20 (11th September 1993)
|Windows NT 3.1 Workstation|
|3.10.5098.1||2C51C0E8 (24th July 1993)
|Windows NT 3.1 Advanced Server|
|3.10.528.1||2E11BE21 (29th June 1994)
|Windows NT 3.1 SP3|
|3.50.800.1||2E6A07F7 (4th September 1994)
|Windows NT 3.5|
|3.50.807.1||2FE8B905 (21st June 1995)
|Windows NT 3.5 SP3|
|3.51.1025.1||2FC653BC (27th May 1995)
|Windows NT 3.51|
|3.51.1057.3||3071868B (3rd October 1995)
|Windows NT 3.51 SP2,
Windows NT 3.51 SP3
|3.51.1057.5||313B3DD8 (4th March 1996)
|Windows NT 3.51 SP4|
|3.51.1057.6||321A03D2 (21st August 1996)
|Windows NT 3.51 SP5|
|4.0.1381.1||3255A915 (5th October 1996)
|Windows NT 4.0,
Windows NT 4.0 SP1
|4.0.1381.3||32ADD131 (10th December 1996)
|Windows NT 4.0 SP2|
|4.0.1381.4||337546BF (11th May 1997)
|Windows NT 4.0 SP3|
|4.0.1381.133||36224CDA (13th October 1998)
|Windows NT 4.0 SP4|
|4.0.1381.204||371CD681 (21st April 1999)
|Windows NT 4.0 SP5|
|4.0.1381.335||37E8005B (22nd September 1999)
|Windows NT 4.0 SP6|
|5.0.2195.1||384D9B17 (8th December 1999)
|5.0.2195.1620||39760637 (20th July 2000)
|Windows 2000 SP1|
|5.0.2195.5438||3D366B8B (18th July 2002)
|Windows 2000 SP3|
|5.0.2195.6717||3EE6C002 (11th June 2003)
|Windows 2000 SP4|
|5.1.2600.0||3B7DE38F (18th August 2001)
|5.1.2600.1106||3D6DE35C (29th August 2002)
|Windows XP SP1|
|5.1.2600.2180||41108004 (4th August 2004)
|Windows XP SP2|
|5.1.2600.5512||48025EAB (14th April 2008)
|Windows XP SP3|
|5.2.3790.0||3E800A79 (25th March 2003)
|Windows Server 2003|
|5.2.3790.1830||42435E33 (25th March 2005)
|Windows Server 2003 SP1|
|5.2.3790.3959||45D6A072 (17th February 2007)
|Windows Server 2003 SP2|
|6.0.6000.16386||4549AD6C (2nd November 2006)
|6.0.6001.18000||47918B0A (19th January 2008)
|Windows Vista SP1,
Windows Server 2008
|6.0.6002.18005||49E01996 (11th April 2009)
|Windows Vista SP2|
|6.1.7600.16385||4A5BBFFC (14th July 2009)
|6.1.7601.17514||4CE78A06 (20th November 2010)
|Windows 7 SP1|
|6.2.9200.16384||5010ADF0 (25th July 2012)||5,563,120||Windows 8|
|6.3.9600.16384||52157309 (21st August 2013)||5,757,792||Windows 8.1|
|6.3.9600.17031||53085A16 (22nd February 2014)||5,786,968||Windows 8.1 With Update|
|10.0.10240.16384||559F3E62 (9th July 2015)||6,263,648||Windows 10|
|10.0.10586.0||5632D21B (29th October 2015)||5,797,728||Windows 10 Version 1511|
|10.0.14393.0||57898E79 (15th July 2016)||6,015,328||Windows 10 Version 1607|
|10.0.15063.0||58CCB6F3 (18th March 2017)||5,862,296||Windows 10 Version 1703|
|10.0.16299.15||59CDA2AC (28th September 2017)||6,404,504||Windows 10 Version 1709|
|10.0.17134.1||5ACD8A1D (11th April 2018)||6,717,856||Windows 10 Version 1803|
|10.0.17763.107||2485A890||6,919,992||Windows 10 Version 1809|
|10.0.18362.1||643D947E||7,067,152||Windows 10 Version 1903|
|10.0.18362.418||FDF958E2||7,069,200||Windows 10 Version 1909|
|10.0.19041.208||1FE3EFCB||7,239,480||Windows 10 Version 2004|
Where two or more Windows packages are listed for a set of files, as with service packs 2 and 3 of Windows NT 3.51, the files with the same name in each package are the same, byte for byte.
Service-pack holdings are complete starting with version 4.0. That Windows 200 SP2 is omitted is because a self-extracting executable has been inspected for these notes but no kernels were found.
Each kernel in Windows Server 2008 is the same as in Windows Vista SP1, byte for byte. Similar correspondence between client and server editions of later Windows versions is so much expected that the server editions are not tracked explicitly for any of this study’s other pages.
How or why Microsoft gets the date stamps in the kernels from later releases of Windows 10 to be so obviously invalid is not yet understood. No, a few scraps tossed from a Microsoft blog do not count as how or why.
The 1909 release of Windows 10 was given its own place in the succession of roughly biannual updates named for year and month, but it has nothing like the significance of other such updates which each increased the build number by several hundred or even thousands. The 1909 release is listed here only because Microsoft presented it as a significant update. All the pages of this study of the Windows kernel treat the 1909 release as a minor bug-fix update of the 1903 release.
Microsoft’s distribution of 64-bit Windows on MSDN discs in the early years was even less reliable than was my renewal of subscriptions. I seem never to have received a 64-bit edition of Windows XP, which is therefore not included in this study. (I suspect anyway that it was a build of version 5.2, i.e., of Windows Server 2003, rebadged for better marketing.) Though correspondents tell me that 64-bit Windows Vista was readily available the moment that Windows Vista was released, my experience is instead that a year-long MSDN subscription in 2007 produced no x64 build of the original Windows Vista. The copy inspected of that is instead from an OEM disc. Though all service-pack builds that have been inspected for this study have been available through MSDN subscriptions, some of the copies studied have instead been downloaded as self-extracting executables from Microsoft’s free websites since, for who knows what reason, it frequently happened that the MSDN site that I paid to access was intolerably slow—not that my tolerance was high, especially while Microsoft was at the time not just leaving me to the tedium of burning disks and labelling them, but telling me that their purpose was to be environmentally friendly.
Some Microsoft documentation, e.g., of the KeAcquireSpinLockRaiseToDpc function, talks of “64-bit versions of Windows 2000” but I certainly never received any such thing from MSDN subscriptions at the time and I don’t believe the MSDN site has ever listed such things even as being available to download. These notes are anyway just for the amd64 processor architecture, also commonly referred to as x64. Though early versions of Windows were small enough for the distribution media to have binaries for multiple processor architectures and later versions were supplied on separate media, I was never interested. I do still have them from MSDN subscriptions, but I have no intention of listing them.
The kernels for each build are listed in the order NTOSKRNL.EXE and then NTKRNLMP.EXE, but only version 5.2 has both. Versions from 6.0 onwards are built with both single-processor and multi-processor kernels, but the installation image on the distribution media has only a multi-processor kernel, which is already renamed to NTOSKRNL.EXE.
|File Version||File Header Date Stamp||File Size||Package|
|5.2.3790.1830||42436096 (25th March 2005)
|Windows Server 2003 SP1|
|5.2.3790.3959||45D69A26 (17th February 2007)
|Windows Server 2003 SP2|
|6.0.6000.16386||4549B6C6 (2nd November 2006)||4,420,712||Windows Vista|
|6.0.6001.18000||479192B7 (19th January 2008)||4,694,072||Windows Vista SP1,
Windows Server 2008
|6.0.6002.18005||49E0237F (11th April 2009)||4,699,608||Windows Vista SP2|
|6.1.7600.16385||4A5BC600 (14th July 2009)||5,511,248||Windows 7,
Windows Server 2008 R2
|6.1.7601.17514||4CE7951A (20th November 2010)||5,563,776||Windows 7 SP1,
Windows Server 2008 R2 SP1
|6.2.9200.16384||5010AC4B (25th July 2012)||6,969,584||Windows 8|
|6.3.9600.16384||5215D156 (22nd August 2013)||7,416,160||Windows 8.1|
|6.3.9600.17031||53085AF2 (22nd February 2014)||7,425,368||Windows 8.1 With Update|
|10.0.10240.16384||559F3C1A (9th July 2015)||8,020,832||Windows 10|
|10.0.10586.0||5632D2D1 (29th October 2015)||7,477,600||Windows 10 Version 1511|
|10.0.14393.0||578998F1 (15th July 2016)||7,814,496||Windows 10 Version 1607|
|10.0.15063.0||58CCBA4C (18th March 2017)||8,319,904||Windows 10 Version 1703|
|10.0.16299.15||59CDA780 (28th September 2017)||8,592,280||Windows 10 Version 1709|
|10.0.17134.1||5ACD8966 (11th April 2018)||9,159,072||Windows 10 Version 1803|
|10.0.17763.107||8BB5571E||9,696,256||Windows 10 Version 1809|
|10.0.18362.30||E2F1A52B||9,917,752||Windows 10 Version 1903|
|10.0.18362.418||FC9570F2||9,928,504||Windows 10 Version 1909|
|10.0.19041.208||6A8090CC||10,281,000||Windows 10 Version 2004|
Where two packages are shown for the same build, the executables are identical. This identity is not just observed for Windows 7 SP1 and Windows Server 2008 R2 SP1 but is formalised in the sense that Microsoft provides the one self-extracting executable for both product names.