Kernel Exports Added for Version 6.0

The large table on this page lists the 375 exports that were added to the Windows kernel for version 6.0., i.e., for the original Windows Vista. These represent by far the biggest change in the kernel’s exported functionality over the whole history of Windows.

Also listed are 35 additions for Windows Vista SP1 and Windows Server 2008. This is among the largest of changes for a service pack. Curiously, twenty functions from the original do not survive. Windows Vista SP2 was much more typical as a service pack: it contributes one more to the list.

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.

Barely a sixth of these new exports for version 6.0 were documented for the contemporaneous WDK, though many more have got documented since. Most are then said (correctly) to be available starting with Windows Vista, but without even hinting that this availability was not generally disclosed until a later WDK. One function is documented only as being reserved. Not quite half of the new functions, and five exports of data, are undocumented but with declarations in one or another of the WDK header files. Declarations, both of these and the documented functions, are mostly for Windows Vista and higher, but some have no version constraint and a few are declared for much older versions. The other third of the new functions had neither documentation nor declaration for nearly a decade. Then, though possibly only as an oversight, Microsoft published declarations for very many of them!

To be clear, for the situation is unusual, the small family of Em functions started as declared but undocumented, and then those declarations disappear (from WDM.H). Their only known public disclosure by Microsoft since Windows 8 is the NTOSP.H from early editions of the WDK for Windows 10.

Somehow I must have missed Microsoft’s documentation of ExInitializePushLock in an online inspection on 13th October 2018. As I find it today, 17th September 2020, it’s not only there but is dated 30th September 2018. Presumably, it was documented concurrently with the 1809 release of Windows 10. Either that or some reason should be found for why Microsoft says that a (simple) function from 2006 needs a kernel from 2018.

The FindEntrySList function is declared in both WDM.H and NTDDK.H before it is ever exported from the kernel or documented.

See in general that merging the IFS Kit into the WDK for Windows Vista did little, if anything, for getting newly added FsRtl functions documented. Almost all are declared in the NTIFS.H which the merger brought into much wider circulation, but almost all had to wait for the next WDK—and many for the one after—before they become documented.

Version 6.0 adds two functions that work with the BASE_MCB structure, which version 5.2 extracted from the older LARGE_MCB. As with the original BASE_MCB fuctions, these additions were declared in NTIFS.H but left out of the documentation. They looked to be still undocumented when checking online on 13th October 2018. Now in 2020, Microsoft’s website has documentation of them, both dated 19th October 2018.

The IoConnectInterruptEx and IoDisconnectInterruptEx functions are also implemented in a statically linked library—in this case, iointex.lib—for use by new drivers that run on older versions.

Though KeRemoveQueueEx is not exported from the version 6.0 kernel before SP1, it plausibly was meant to be. It is declared in NTIFS.H from the WDK for Windows Vista and the original version 6.0 kernel not only has it as an internal routine but as the effective implementation of the old, documented KeRemoveQueue.

The undocumented KeStartDynamicProcessor is declared in the WDM.H from the WDK for Windows Vista, and then its declaration disappears except in the presumably accidental disclosure of NTOSP.H by Microsoft in early editions of the WDK for Windows 10.

Starting with the WDK for Windows 8.1, Microsoft formally deprecates the MmBadPointer variable’s declaration in favour of an MM_BAD_POINTER macro. A historical survey might be content with this, perhaps adding for completeness that the macro is not documented in and of itself. Indeed, in the downloadable package of WDK documentation for Windows 8.1 to integrate into Visual Studio, and again for Windows 10, the page for the variable has a link for the macro but the link is broken. More is going on here than mere untidiness. For background, remember that exported variables are imported as pointers. This can cause programmers something between an inconvenience and a complication. To help, Microsoft sometimes hides the declared variable behind a documented macro, as with KD_DEBUGGER_ENABLED for KdDebuggerEnabled. But the superseding of MmBadPointer by MM_BAD_POINTER is not for convenience. It is instead a correction: MmBadPointer was documented for use as a variable but its declaration is only what works for the kernel. For an importing module, the declaration is faulty. The variable is meant to hold an address that is guaranteed to be bad but using it as documented, and as done by Microsoft’s own RDBSS.SYS driver in versions 6.0 to 6.2 inclusive, instead produces an address that is certain to be good (being an address in the kernel’s data).

Functions whose names begin with Nt correspond closely with functions whose names have the Zw prefix instead (see below). Put aside some general points about how the two differ, and documentation of the Nt function is to a large extent implied by documentation of the Zw. Microsoft started making this explicit some time after releasing the WDK for Windows Vista. Perhaps not coincidentally, Windows Vista had just brought by far the largest addition yet of Nt functions, but since the documentation for Windows Vista leaves them alone they are here taken to have been initially undocumented or declared. Documentation in the WDK for Windows 7 gives each Nt function its own page and directs attention to the page for the corresponding Zw function. The latter might be thought to count for both, except that the former warns expressly “Do not call this routine from kernel-mode code.” This is here taken as documenting the Nt functions as reserved (certainly for kernel-mode use, which is this survey’s focus). Microsoft loosened the text significantly for Windows 8 to note that the Nt and Zw versions “can behave differently”, which is here taken as formally permitting their use, such that they are no longer documented as reserved.

Whatever the reason that several Nt functions for the new Transaction Manager feature do not survive to the first service pack, they weren’t born in some experimental backwater: though none were documented, all but one was declared.

When first introduced, the RtlIsNtDdiVersionAvailable and RtlIsServicePackVersionInstalled functions were all but useless except if supported through a statically linked library. To the caller who imports these functions from the kernel, the documentation’s suggestions of testing for availability back to Windows 2000 is at best redundant because the caller necessarily is running on version 6.0 or higher. To a driver written for Windows Vista but capable of downgrading its expectations to whatever Windows it finds itself running on, these functions are useful only if the driver gets them from a statically linked library. The WDK supplies the library, named RTLVER.LIB, and has the headers arrange that building for a target operating system older than Windows Vista will need the library. The documentation, however, gives only the smallest hint of any of this—for no explained reason, these functions “Link to Rtlver.lib and Wdmsec.lib”—until an explanatory paragraph was added to the WDK for Windows 8. Do not miss the irony that by this time the WDK had stopped supporting the building of drivers for versions older than Windows Vista.

As with most exported variables, TmEnlistmentObjectType , TmResourceMangerObjectType, TmTransactionManagerObjectType and TmTransactionObjectType are not themselves documented. Starting with the WDK for Windows 7, however, they get mentioned in the documentation of exported functions such as ObReferenceObjectByHandle from being intended as an argument.

Microsoft’s online documentation of WheaAddErrorSource is dated 19th August 2019 and I see no reason to disbelieve it. Curiously, the function is declared in the WDK for Windows Vista, but among WDK for versions that actually do export the function, the declaration appears only in NTOSP.H from early editions for Windows 10.

That documentation of WheaReportHwError was delayed until 2019 is more certain. Microsoft dates the documentation to 6th March 2019 and the function’s availability to the 1903 release. While undocumented, it was declared in NTDDK.H from the WDK for Windows Vista, specifically, and then the declaration disappeared except for the accidentally disclosed NTOSP.H.

In WDK documentation for Windows 10 as integrated into Visual Studio 2015, documentation of NtQueryVirtualMemory (which is not a kernel export in any version) would link to a page for its Zw partner but the link is broken. The ZwQueryVirtualMemory function is documented today, 27th September 2020, at Microsoft’s website and has been at least since 30th April 2018, and there’s no reason to doubt Microsoft on this even though this documentation would have it that the function’s minimum availability is Windows 10.

Old Friend

The ancient KeIsExecutingDpc function was not at first taken up for export from the x64 kernel. It starts being exported from x64 builds in version 6.0.

Discontinued

Version 6.0 stops exporting a few functions (and variables). For each, the version in parentheses tells when exporting started.

• CcFastReadNotPossible (4.0)
• CcFastReadWait (4.0)
• KeDisconnectInterrupt (3.10)
• KiEnableTimerWatchdog (5.0)
• PsCreateSystemProcess (3.10)
• WmiFlushTrace (5.1)
• WmiQueryTrace (5.1)
• WmiStartTrace (5.1)
• WmiStopTrace (5.1)
• WmiTraceFastEvent
• WmiUpdateTrace (5.1)

As usual, none had yet been documented.

Discontinued (x64)

Two functions that continued at first as exports from the x64 kernel are not kept as exports from the x64 builds:

• ExAllocateFromPagedLookasideList (4.0)
• ExFreeToPagedLookasideList (4.0)

Both continue as x86 exports.