NTDLL Exports

The very large table on this page lists all the functions and variables—there are well over two and a half thousand—that appear in the export directory of any known i386 (x86), amd64 (x64) or wow64 build of NTDLL.DLL from Windows NT up to and including the original Windows 10.

Many have been or still are exported from NTDLL 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 (and wow64, being x86 adapted specially for x64) matter to this study.

The NTDLL.DLL from the Windows that runs on DOS is here considered to be a separate executable (not presently catalogued).

Conventions

This page is intended as a master list. For each NTDLL export, the table gives just a brief summary of the applicable NTDLL versions and a colour-coded summary of status with respect to Microsoft’s documentation (at roughly the release of the original Windows 10).

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 NTDLL’s entry for Versions to get pages for each version.

Some—presently very few—functions link directly from this master list (and from the version lists) to an attempt at independent documentation.

Colours

Documentation status is summarised by colour coding. (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.) (To decode a colour, hover for a tooltip.)

Functions that have their own non-trivial documentation are shown with no background colour, since this documentation status would be completely unremarkable, if only in an idealised world of open design.

As an obvious contrast used throughout this website, functions that look to be completely undocumented are highlighted yellow. That most rows of the table then start with yellow may benefit from advance understanding of NTDLL as the kernel’s exposure to user-mode subsystems (of which Win32 is just one of potentially many). In each subsystem, higher-level code interacts with the lower levels of the subsystem, not with NTDLL. For instance, most Win32 programs and DLLs import Win32 API functions from KERNEL32.DLL (and others), not from NTDLL. The vast majority of NTDLL exports are treated as the subsystems’ private system calls to kernel mode or as common support for all subsystems to re-present each in their own way to their higher-level components. Either way, the plain intention is that the NTDLL exports themselves are not for wide use. In the real world of closed-source design, the undocumented status of most NTDLL exports is only to be expected, even as unremarkable.

That said, one of the practicalities in the design is that each NTDLL export that is in some sense a system call typically has the same name as the kernel-mode implementation that it accesses and NTDLL exports that are fully implemented in user mode often have parallel implementations in kernel mode, again with the same names. Thus may an NTDLL export correspond closely to a kernel-mode function among the Windows Kernel Exports. If this kernel-mode export is documented in a Windows Driver Kit (WDK) for kernel-mode use, then the otherwise undocumented NTDLL export is shaded green as my suggestion that it is documented in effect. The vast majority of NTDLL exports that are documented at all are documented this way.

Functions that are explicitly documented as reserved or obsolete—no matter how or where—are shaded red or shaded grey, respectively, as quick indications that they are better avoided.

Many undocumented functions do at least have C-language declarations in one or another header file from the Software Development Kit (SDK) or, for reasons sketched above, the WDK. These exports 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 header now but had declarations disclosed by Microsoft in a “minwin” subdirectory of early editions of the WDK for Windows 10 which Microsoft seems since to have been withdrawn from distribution. These are highlighted orange to indicate that public disclosure even of the declaration was exceptional.

Processor Architectures

NTDLL exists in both 32-bit and 64-bit Windows. The latter provides both a 64-bit (x64) NTDLL in the System32 directory and a 32-bit (wow64) NTDLL in the SysWOW64 directory. The 32-bit NTDLL in 64-bit Windows differs from the 32-bit (x86) NTDLL in 32-bit Windows, but not by much, such that wow64 is here treated as an exceptional case of x86 specialised for x64 execution. Where x86 is not contrasted with wow64, it stands for both x86 and wow64.

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 x64 and wow64. When clearly limited just to x64 or wow64, version 5.2 is treated as beginning with SP1.

Substantial explanatory notes, especially about the different sources and degrees of documentation, follow the table.

Names

Function names are reproduced from the export directory of the NTDLL.DLL executable. All exports from NTDLL are by name, until Windows 7 introduces a few that are exported only by ordinal. Names for these few are inferred from symbol files that Microsoft supplies for customer support. 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 such 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 NTDLL 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 have downloaded from Microsoft’s websites (whether free or requiring what is nowadays called a Visual Studio subscription). My holdings are incomplete 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 to mean the original and a selection of service packs, 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)
• Windows 8
• Windows 8.1 and Update
• Windows 10

Documentation Status

As sketched above for the colour coding, very few NTDLL functions are documented as being exported from NTDLL. Finding these few is difficult enough since what documentation does exist is scattered. That a function is colur-coded above as undocumented does not mean for certain that Microsoft does not document it (or declare it in some header), just that I haven’t yet found where.

Worse, the documentation status of NTDLL functions cannot be left just with whether Microsoft documents them as being exported from NTDLL. Many NTDLL functions are sort-of documented, by other means in other guises, such that they cannot properly be ruled undocumented. There are several mechanisms at play.

Higher-Level Documentation

Many an NTDLL function has a higher-level function, often with a different name, that corresponds to it more or less closely. The higher-level functions, typically in KERNEL32.DLL or ADVAPI32.DLL, usually are documented—most exist as the bread and butter of Win32 programming—but identifying them all is not straightforward.

The easy ones to find are not actually coded in the higher-level module but are exported from the higher-level module merely as forwards to NTDLL. These can be enumerated completely just from a mechanical examination of the higher-level DLL’s export directory, but even they are not entirely well-defined, most notably for varying with the version.

Other functions are coded in the higher-level module but very simply, e.g., as a jump to the code in NTDLL, or in some other way such that the NTDLL function provides the whole implementation of the higher-level function. These are enumerated only by inspecting the code, and I do not imagine I will ever do this anywhere near to completely even for one version.

If a function that is not formally documented as being exported from NTDLL falls into either of these cases and is documented as being exported from the higher-level DLL, then I do not count it as an undocumented NTDLL export. If the higher-level function has a different name, then the difference is a bit much to convey meaningfully in this summary: refer to the more detailed Remarks in the function’s listing by version.

For many more NTDLL functions, the higher-level function re-dresses the NTDLL function, typically to take arguments in a different form or to return a different type, yet the correspondence remains close enough that calling the one rather than the other loses little or no functionality (though the higher-level function is generally to be preferred on architectural grounds). For these, it is not entirely satisfactory to call the NTDLL function undocumented if the higher-level one is documented, but neither is the correspondence in all such cases close enough to justify saying that the NTDLL function is documented in effect. To say one way or the other would be subjective beyond usefulness, and I leave these cases alone.

WDK Documentation

Most of the many NTDLL functions whose names begin with Nt or Zw are just calls to the NT kernel in ring 0 through a software interrupt or other mechanism such as the sysenter instruction. The ring 0 code that is reached this way may also be exported from the NT kernel (often just with the Zw prefix) so that it can be imported by other ring 0 code such as device drivers and installable file systems. Some, but by no means all, of these lower-level functions are documented in the WDK, with the Zw prefix for use from kernel mode and Nt for use from user mode.

A similar outcome through different means is presented by the many NTDLL functions whose names begin with Rtl. They are implemented more or less completely in NTDLL but many have duplicate implementations in the ring 0 kernel. Some differ slightly. Some are identical, apparently from being coded in libraries for static linking into both the kernel and NTDLL. Though the WDK documentation presents these functions only for their use in ring 0, it looks to be equally applicable when they are called as NTDLL functions.

It may be that Microsoft always intended that NTDLL is documented in the WDK (if at all) rather than the SDK, such that what little has shown in the SDK is a leakage of internal detail.

CRT Documentation

Finally, NTDLL exports more than 100 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 C or C++ programmer would want to be without. None have the compiler-version dependencies that might otherwise steer the programmer to static linking or to importing from an MSVCRT.DLL that varies with the Visual Studio version and might not be available at run time on any given computer. The programmer may anyway be working at too low a level even for importing from the Windows-supplied MSVCRT.DLL (not that Microsoft is known to have encouraged this technique). Importing these utility functions from NTDLL.DLL is the lowest-level option. The CRT documentation is good for them as exports from NTDLL even without formally saying so.