Windows Kernel Exports

This page lists all the functions and variables—there are more than three thousand—that appear in the export directory of any known i386 (x86) or amd64 (x64) build of the Windows kernel.

Many have been or still are exported from the kernel for other processor architectures, but x86 and x64 account for very nearly all Windows computers whose users actually do think of and use their computers as computers, in contrast to phones, devices and things. So, only x86 and x64 matter to this study.

Another limit to the study is that it never can feasibly cover lesser updates or hotfixes nor even be up to date. The “known” builds presently extend no further than the 2004 release of Windows 10, i.e., from April 2020. The present count of exports, both current and discontinued, is 3,354.

Conventions

This page is intended as a master list. Each export is shown here with just a brief summary of the applicable kernel versions and a colour-coded summary of status with respect to Microsoft’s documentation.

For details of an export’s availability and documentation history, look for the export in other lists according to its first version as shown here. In the Table of Contents, expand the kernel’s entry for Versions to get pages for each version. Those pages are where this study means you to find, for example, that although a function of interest to you has been exported since 1993, it is said by Microsoft’s documentation to be available only starting from Windows Server 2003 SP1, and that even this wasn’t revealed until 2007.

A few exports—presently very few—link directly to an attempt at alternative documentation. Some such attempts are substantial, even exhaustive. Others aren’t much more than placeholders.

Colours

Documentation status is summarised by colour coding. (To decode a colour, hover for a tooltip.) (Had the website’s scripts run as expected, then hovering over any colour-coded text would produce a tooltip that shows why the text is coloured.)

Functions that have their own non-trivial documentation are shown with no background colour, this documentation status being completely unremarkable.

Functions that are documented as reserved or obsolete are shaded red or shaded grey, respectively, as quick indications that they are better avoided.

To make an obvious contrast, which is used throughout this website, functions that appear to be completely undocumented are highlighted yellow. If a function is documented now but was not documented in the first contemporaneous Device Driver Kit (DDK), Windows Driver Kit (WDK) or Installable File System (IFS) Kit, then it is shaded yellow to retain some of its previous status.

Many undocumented functions do at least have C-language declarations in one or another header file from the WDK. These are shaded orange. They are not formally documented, nor formally reserved, but neither are they completely undocumented: indeed, history shows they’re often on the way to getting documented. Some undocumented functions aren’t declared in any WDK header now but had declarations disclosed by Microsoft in a “minwin” subdirectory of early editions of the WDK for Windows 10 which seem since to have been withdrawn. These are highlighted orange to indicate that public disclosure even of the declaration was exceptional.

Abbreviations

That a function or variable is exported in all versions of the applicable architecture is often some sign of its being fundamental, which seems deserving of an easy indication. The shorthand “all” means “3.10 and higher” for the x86 and “5.2 SP1 and higher” for the x64. When clearly limited just to the x64, version 5.2 is treated as beginning with SP1.

There has been a slow migration of functionality to the kernel from the HAL. That a kernel export started as a HAL export is indicated below by an “also from HAL” annotation. In all cases, the kernel now has the substantial implementation. For whether the HAL retains a stub implementation or merely forwards its export to the kernel, look for the function’s history as an export from the HAL: in the Table of Contents, expand the HAL Versions.

Some of this migration from the HAL to the kernel has been x64-specific. Since the x86 implementations are not kernel exports, they might be omitted from the table, but to help with cross-referencing they are indicated below by an x86-specific direction to “see HAL”.

Names

Names are reproduced from the export directory of the NTOSKRNL.EXE executable. All exports from the kernel are by name until version 6.2 introduces two that are exported only by ordinal. Names for ordinal-only exports are inferred from public symbol files that Microsoft, well, publishes for customer support (nowadays as a free download). The ordinal is given in parentheses immediately after the function’s name.

A few exports are of variables rather than functions. They are marked above by the word “data” in parentheses. These notes talk of all as functions, hoping no confusion will be caused by the loose terminology.

Since experience shows that this table is not always read with the knowledge of an advanced programmer, it must be stressed that a function’s presence in the export directory does not mean that the function is implemented non-trivially, let alone that it will work satisfactorily if called. It means just that the function can be imported by other modules, and be called by them, for better or worse. That a function is first exported in some version does not mean that Microsoft supports its use in that version, even if such support is documented for later versions.

Versions

The kernel versions shown for each function are inferred from a study of public releases such as I have managed to find on old MSDN discs or downloaded from Microsoft’s websites, whether free or requiring what is nowadays called a Visual Studio subscription. My holdings are incomplete, especially for service packs of the earliest versions, and I anyway have no time for (or interest in) examining pre-release builds or hotfixes.

Of necessity then, the table makes what I hope are reasonable assumptions about likely continuity, especially to suppose that a function will exist in future versions or that a function exists in all builds of a version if no counter-example is yet known. If you want more accurate or comprehensive information, try getting it from Microsoft.

A quick list of the studied versions, each understood as the original and a selection of its service packs (or similarly significant updates of Windows 10) is:

• Windows NT 3.10 and SP3
• Windows NT 3.50 and SP3
• Windows NT 3.51 and SP2 to SP5;
• Windows NT 4.0 and SP2 to SP6;
• Windows 2000 and SP1, SP3 and SP4
• Windows XP and SP1 to SP3
• Windows Server 2003 and SP1 and SP2
• Windows Vista and SP1 (doubling as Windows Server 2008) and SP2;
• Windows 7 and SP1 (doubling as Windows Server 2008 R2);
• Winodws 8;
• Windows 8.1 and Update;
• Windows 10 and 1511 to 2004.

Documentation Status

The foundation for all comment on Microsoft’s documentation of exported kernel functions is what looks to be Microsoft’s last packaging of WDK documentation to download for offline reference through Visual Studio under the heading “Windows Driver Kit (WDK)”. As this documentation says: “Windows Driver Kit (WDK) 10 is integrated with Microsoft Visual Studio 2015”. The large files, with names like v2Windows_Development_Windows_Driver_Development_B974_VS_85_en-us_*.mshc, from which this content is drawn appear to be as close as Microsoft now comes to publishing WDK documentation as a self-standing, explicitly dated collection. The modification date for most of these files is 6th August 2015, which to my mind means they can reasonably be taken as Microsoft’s definitive offering of documentation for Windows 10 as first released on 29th July 2015.

What I know of any later WDK documentation is whatever I happen to have found at Microsoft’s website in occasional visits for which I can’t summon much commitment. Perhaps there is a better way, perhaps there are still packages to download for integration into Visual Studio, but I never have welcomed downloading the WDK and then having to go hunting for the related documentation.

I may easily be wrong, but I don’t think it’s mere neglect that Microsoft’s documentation of Windows has for many years now—roughly coincidental with the expiry of constraints from its settlement of an anti-trust suit—become ever more problematic as a historical record both for accuracy and accessibility. To be clear, I can’t escape the thought that Microsoft wants it this way. An unstated lesson for Microsoft from its anti-trust experience is that an openly available historical record can be inconvenient: though history cannot be controlled, it would better at least be handled. A few paragraphs on this survey’s own history may help with this perspective (or prejudice).

When this page was first prepared in early 2009 it was developed from similar surveys of exports from user-mode modules, starting in 2004 with a survey of the Windows Shell. A large part of that survey’s motivation was to assess Microsoft’s compliance with the settlement’s provisions for documenting Windows API functions that were used by what the anti-trust suit termed Microsoft middleware (most notably including Internet Explorer). A natural reference for documentation at the time was the CD edition of the MSDN Library dated January 2004. By the time I started revising for Windows Vista, dated collections of the MSDN Library had ceased but the Windows Vista SDK was conveniently dated January 2007 and seemed natural as a new reference for user-mode documentation.

When my attention shifted to this website’s lack of kernel-mode material in 2009, the release of Windows 7 was imminent. I soon settled on its WDK as the chosen reference for all comment on Microsoft’s kernel-mode documentation and programming support. In this first public release of the WDK for Windows 7, numbered 7600.16385.0, most documentation is dated to 18th June 2009 and header files to 13th July 2009. Before the year was out, a revision named 7600.16385.1 added functions that had been new for Windows 7 but had somehow been overlooked for the first documentation. That much is welcome, of course. What troubles the historical record is that this revision cemented what had been a growing and apparently systematic misrepresentation by Microsoft of the early history: many ancient functions, including many that are fundamental to kernel-mode programming, have forever since been labelled by Microsoft as requiring “Windows 2000 and later”.

The 7600.16385.1 revision then turned out to be the last WDK that includes documentation. Up to then, the DDK or WDK had come with documentation. Starting with the WDK for Windows 8, documentation is not built in. Whatever may be the relative value to programmers of possibly stale documentation read in private versus possibly new documentation viewed online, and whatever may be the value to Microsoft of learning what documentation programmers actually do look at, the trouble for history is that Microsoft’s documentation of the Windows kernel is no longer published definitively and dated definitively.

That a function is marked above as documented does not mean that it has always been documented, only that it is documented in the reference edition, i.e., the downloadable collection of WDK documentation for Windows 10, or that I have noticed later documentation of it online.

Currency

Choosing a reference edition is not ideal for all purposes. Windows versions that get released afterwards will inevitably add functions, which then will typically not be listed above as documented until a new reference edition is adopted.

I may adjust for observations that I happen to come across, but please understand that I do not intend to poll Microsoft’s websites to keep the documentation status up to date. I may not even be able to sustain a programme of regularly updating this list to match new choices of reference edition even years apart. If you want more frequent updating, then please remember that this bookkeeping is done at my own expense in the public interest: look instead for an alternative that is done commercially or by academics who draw a salary—or even by interns or research students—and perhaps wonder how it is that such alternatives are so scarce that you find yourself looking here.

History

There is also potentially a loss of history because any chosen reference edition can be too recent.

Of interest perhaps only to historians is that even documented functions are sometimes discontinued, meaning specifically that later versions do not export them.

Delayed Documentation

Of potentially much wider interest is that new functions are often not documented immediately by Microsoft and sometimes not for several years. For instance, many functions that were added to the kernel for Windows Vista were not documented until the WDK for Windows 8. That they were then said to be “available starting with Windows Vista” is welcome for being correct but hides six or so years in which they were not formally available (to everyone).

I tend to think that delayed documentation imposes significant costs on and barriers to third-party software development. Perhaps even worse, it risks tying third-party developers (and supposedly independent analysts and commentators) to Microsoft for the favour of getting documentation that is not yet available to all.

None of this can sensibly be appraised by anyone without a careful account of the documentation history. For as much precision as I happen yet to know about the history of a function’s documentation, look for the function in the Exports History under Versions in the Table of Contents. Please be aware that this is a work in progress. For thousands of functions, each to be looked for in dozens of documentation samples, there are bound to be some mistakes in my descriptions, and my account of the history is anyway deficient for not having found an Installable File System (IFS) Kit for any release of Windows XP or Windows Server 2003.

The IFS Kit is especially notable in this context of delayed documentation. Of the kernel functions that Microsoft does document, a significant proportion (not quite a third) are documented in the WDK only by the relatively recent inclusion of the IFS Kit which was for many years not nearly as readily available as was the ordinary Device Driver Kit (DDK). According to stories that can still be found on the Internet, Microsoft’s practice if only in the early years of Windows was that the IFS Kit was not just very expensive, relative for instance to an MSDN subscription, but also was sold only under some sort of Non-Disclosure Agreement. If the latter is true, then functions that were documented first in the IFS Kit for Windows 2000 were undocumented as far as affected most programmers (even though I count such functions above as documented). In any case, even the IFS Kit didn’t have formal documentation before Windows 2000.

Classifications

For some functions, the whole of Microsoft’s documentation is that the function is reserved for use by the system. Undocumented functions are occasionally promoted to reserved. Only very rarely is a reserved function later documented with any substance. That a function is marked above as reserved means that the only known mention of it in the current reference edition of Microsoft’s documentation is to say some such thing as that the function is reserved for the system or is not to be used in drivers. The function may have its own page, and even be given with a prototype and other details, or it may just appear in a list of names.

Other functions are said to be obsolete. These often are given with prototypes and sometimes with substantial documentation, presumably from before the function became obsolete. A few were already obsolete as early as the Windows NT 3.51 DDK and a few others seem to have gone directly from undocumented to obsolete. That a function is marked above as obsolete means that its page of documentation in the current reference edition is anything from slight to substantial but includes a remark that the function is obsolete, superseded, deprecated or some such.

Even for the functions that Microsoft does document non-trivially, Microsoft provides no master list. Documentation is scattered through the WDK. I see no easy way to automate a search and I have not typed the name of every function into the (surprisingly primitive) search pane of the Document Explorer or Microsoft Help Viewer or whatever. I have marked a function as documented—well, left it unmarked—if I have seen in the Contents pane that the function has its own page anywhere under numerous applicable headings. That a function is instead marked as undocumented does not mean for certain that Microsoft does not document it, just that I haven’t yet found where (including because I haven’t cared enough to look harder).

Some exports, especially of variables, are documented indirectly in the sense that a WDK header file defines a macro for access to the variable and the macro has formal documentation. However much I might like to count this above as documenting the export, I have ended up concluding that doing so is impractical to do reliably and anyway could not be fitted into this summary. As ever, the export’s listing among the version-specific pages may record an attempt at this greater detail.

A handful of functions have user-mode equivalents, with the same prototypes, which are documented in the Software Development Kit (SDK). The user-mode documentation of such functions appears to be good for kernel-mode. This counts above as documenting the export unless some inference is detected that the user-mode documentation is intended as not applying to kernel mode. Again, the details and my reasoning will be in the version-specific history, if anywhere.

While on the matter of equivalent user-mode documentation, special mention must be made of NTDLL. Many kernel-mode functions whose names start with Nt, Rtl or Zw also exist as user-mode functions exported from NTDLL. The WDK seems intended not just for kernel-mode programming but also for user-mode programming of the low-level sort that deals directly with NTDLL rather than with the base modules of the Win32 subsystem, e.g., with KERNEL32. Unfortunately, the WDK documentation and header files rarely state explicitly whether what is said of a function is meant just for the kernel or also for NTDLL or just for NTDLL. I have not yet worked out how to record this in the lists.

Finally, the kernel implements a selection of functions from the C Run-Time (CRT) Library. Some are not documented even for the CRT because in practice all calls to them are generated by the compiler, but most are the sort of utility functions that no low-level C or C++ programmer would want to be without. They could be supported through a kernel-mode DLL, but since the kernel uses them anyway, the implementations in the kernel are as well to be exported. The CRT documentation is good for these, even though they are not formally documented as being exported from the kernel.

As a quick summary, just over half of all kernel exports are documented, including just to say that the function is obsolete or reserved. The flip side is that roughly 30% of exports from the Windows kernel are completely undocumented, without even a declaration in a WDK header file.