Named Kernel Exports Added for Windows 10 Version 2004

This page lists the functions and variables that are newly exported by name from the Windows kernel in the 2004 release of Windows 10.

In terms of its formally exported interface, this 2004 release of the Windows kernel is very notable on two counts. First, it greatly expands the functionality that is exported only by ordinal. Before Windows 8, all the kernel’s exports were exported by name. These have ordinals, of course, but only incidentally. They are renumbered as exports are added and removed, and are therefore unreliable for importing. Windows 8 introduced two functions that are exported only by ordinal. With no name to specify when importing, these ordinals must be stable. Microsoft has long used ordinal-only exports in user-mode for functions that are in some sense even more than unusually undocumented. Successive releases of the kernel since Windows 8 have each added one or two or none. The 2004 release adds 15 to the Ordinal-Only Kernel Exports Added for Version 10.0. None are documented.

Second, the x64 kernel in Version 2004 supersedes the x64 HAL. The latter is reduced to a stub. It continues to export functions but with no implementations in code. The HAL’s only continuing involvement with them is to name them in the Export Directory as forwards to the same-named functions in the kernel. These new kernel exports are distinguished below by “see HAL” as a direction for where to look up their history. Many, of course, were never documented as HAL exports.

For the table below, documentation status is summarised by colour coding so that more detail can be given as Remarks with less text. (If you read this website with scripts enabled, then hovering the mouse over any coloured text will produce a tooltip that shows why the text is coloured.) Functions that have their own non-trivial documentation are shown with no background colour. If the function is documented as reserved or obsolete, it is shaded red or shaded grey, respectively. 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, except for one special case. Some declarations are known only from “minwin” headers that Microsoft published in early editions of the WDK for Windows 10 which seem since to have been withdrawn. These are highlighted orange to indicate that public knowledge even of the declaration is exceptional.

Of the very many new exports whose names start with Hal only one, HalWheaUpdateCmciPolicy, is truly new to Windows. All the others have earlier history as exports from the HAL. All, including the new one, continue to be exported from the x64 HAL but only as forwards to the kernel. Indeed, the x64 HAL in Version 2004 is nothing but a stub to support drivers that expect to import these functions from the HAL.

Of the five new exports that support external work with persistent memory for the Kernel Soft Reboot (KSR) feature, only IoAcquireKsrPersistentMemory is formally documented as reserved but the others can’t sensibly be counted as anything else. The only way their pages in the documentation are any less insubstantial is that they don’t spell out “Reserved for system use” at the top.

Though IoCreateDeviceSecure is new to the kernel as an exported function, it long had its own page of documentation among the I/O Manager Routines. In this earlier history, it is a routine for drivers to call from a statically linked library, named WDMSEC.LIB, which Microsoft introduced with the DDK for Windows XP SP1.

A pattern seems to have set in with Microsoft’s presentation of Windows security features. The details aren’t formally documented, sometimes not even for years, but help is offered informally through blogs written by Microsoft staff. Desperate programmers and system administrators applaud the helpfulness, yet plainly it’s no substitute for properly documenting the feature. Here is an example in the kernel-mode API. The MmProtectDriverSection helps drivers with a new feature named Kernel Data Protection, but Microsoft leaves driver writers to learn of the function from a blog. Search for it through Google: I’m not playing.

Documentation of NtQueryInformationByName, certainly as I see it at Microsoft’s website today, 14th October 2020, is very plainly intended for kernel-mode use, what with its talk of IRQL and of kernel APCs. Even so, the function is not exported from the kernel until version 2004.

The WheaAddErrorSourceDeviceDriverV1 function is odd for being documented both as obsolete (at the top) and as newly available (near the end). It is in fact the original WheaAddErrorSourceDeviceDriver with four arguments, as first exported from Version 1903. In effect, WheaAddErrorSourceDeviceDriver in Version 2004 and higher, with just three arguments, is a new function. In retaining the name, Microsoft created the first case of a documented kernel export changing its prototype incompatibly.

As with many Zw functions, ZwGetWriteWatch and ZwResetWriteWatch have earlier history as user-mode exports from NTDLL.DLL. These date from Windows 2000 but stayed undocumented except for declarations in the ZWAPI.H header that Microsoft published only in early editions of the WDK for Windows 10.