Kernel Version 6.2 Exports By Name

The large table on this page lists the functions and variables that are newly exported by name from the Windows kernel in its first release for version 6.2, i.e., for the original Windows 8. Several do not survive to the next version. Few were documented immediately (or even by the time of an online search for them all on 29th February 2016).

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.

Surely much of the point to documenting a function is that programmers can use it and even that its use by programmers is intended. It’s therefore unusual that a documented function has no declaration among the headers that Microsoft publishes for inclusion in source code. The six cases that are known from the IFS Kit for Windows 2000 look like oversights: declarations were supplied with the WDK for Windows Vista, if not earlier. That Windows 8 documents five new Cache Manager functions without declaring them in NTIFS.H may be another such oversight, but it has been a long time waiting for correction.

For the ExQueryTimerResolution function, the WDK documentation for Windows 8, Windows 8.1 and Windows 10 that Microsoft presents as “integrated” with successive editions of Visual Studio has a page titled High-Resolution Timers that lists the function, and states explicitly that a driver may call the function, but the link to what might have been the documentation of the function itself is broken. Whether, or for how long, the supposedly same documentation online had this deficiency is not known, but the page was seen to be available online on 27th February 2016.

When exactly the declaration of ExTryQueueWorkItem was formally deprecated is not known. The first known declaration in public, from the NTOSP.H in the WDK for Windows 10, is already marked as deprecated. A comment suggests IoTryQueueWorkItem as preferred. Since it also is newly exported for version 6.2, deprecation of the one in favour of the other presumably came later. It is here thought to have come when the favoured function got documented.

Somehow I must have missed Microsoft’s documentation of FsRtlQueryKernelEaFile and FsRtlSetKernelEaFile in an online inspection on 13th October 2018. As I find it today, 17th September 2020, it’s not only there but is dated 16th April 2018. This is roughly concurrent with Microsoft’s reorganisation of documentation according to which headers have the functions’ declarations. Whether these two were documented before then, I don’t know. They are not in the WDK documentation for Windows 10 as supplied for Visual Studio 2015.

The IoDecrementKeepAliveCount and IoIncrementKeepAliveCount functions are not formally reserved in version 6.2 but may as well be. Their documentation in the WDK for Windows 8 has the functions as “for internal use only” and although it presents declarations, each of the parameters and the return value are marked simply as “Do not use.” The declarations are anyway not reproduced in any header file from the WDK for Windows 8 (which would be remarkable for a function that’s documented for use but not for one that’s documented as reserved).

Windows 8 tidied the redistribution of functionality between the HAL and the kernel that started with the introduction of the amd64 processor architecture in Windows Server 2003 SP1. Functions that work with the Interrupt Request Level (IRQL) and with the various types of spin lock are exported from the HAL in x86 Windows but have never been anything other than kernel exports in x64 Windows. The tidying for version 6.2 is that the functions that work solely with the IRQL continue to be implemented wholly in the x86 HAL but the ones that work with spin locks are forwarded to the kernel. Some functions that had been exported only from x64 builds of the kernel become exported from x86 builds too. Three are exported only from the x86 kernel. To support old x86 binaries, all these functions continue as exports from the x86 HAL.

Though KeQueryTotalCycleTimeThread is not exported until Windows 8, it is declared in WDM.H from the WDK for Windows 7. So too is a KeQueryTotalCycleTimeProcess that the version 6.1 kernel has as an internal routine and which no version exports.

The ObReferenceObjectSafe function is not in the documentation for the Windows 10 WDK as integrated into Visual Studio 2015 and did not show in surveys of online documentation on 27th February 2016 or 13th October 2018, but it is present today, 17th September 2020. It is dated 19th October 2018 and I see no reason not to take this as Microsoft’s first date of publication.

That PoFxRegisterCoreDevice, PoFxRegisterPlugin and PoFxRegisterPluginEx are not documented until version 10.0 looks deliberate. In the WDK for Windows 10 as integrated into Visual Studio 2015, they are documented under a new heading. Their declarations are in a new header, named PEPFX.H, which plainly was prepared for Windows 8. That the WDK for Windows 8 and again for Windows 8.1 omit a new heading and header might be disregarded as an oversight, except that the documentation would have it that the functions are new for Windows 10.

Starting with the WDK for Windows 8, WDM.H mentions RtlCheckTokenMembership in a comment for defining “flags” for use with the function. Yet neither this function nor RtlCheckTokenMembershipEx are declared. The flags look to be intended not for the former but the latter (specifically for its third argument). More research may be required.

I have no record of finding RtlQueryPackageIdentity in Microsoft’s online documentation in October 2018. What’s there now, in September 2020, is dated 30th October 2019 and I see no reason not to accept this as the date of first publication.

For background to the Transaction Manager functions, remember that the functionality was introduced for Windows Vista but none of the functions were documented until Windows 7 (when, of course, they were said to be “Available in Windows Vista and later”).

As suggested by the documentation, the TmInitializeTransactionManager function’s first presence in the kernel is version 6.0. It is even declared in both WDM.H and NTIFS.H from the WDK for Windows Vista. Very plausibly, it was meant to be among the many other Transaction Manager functions that were newly exported for Windows Vista, but it is not actually exported before version 6.2, no matter how long the documentation continues to say differently.

Something similar applies to TmRenameTransactionManager. Its first presence in the kernel is for version 6.1 and it is declared in the WDM.H from the WDK for Windows 7. It plausibly was devised as new for Windows 7, adding to the original interface, but it is not exported until version 6.2 and no sense at all is known for the documented availability in version 6.0.

For more evidence that all three of the documented Transaction Manager functions are newly exported from version 6.2 only because they were overlooked in one or two earlier verions, consider TmSinglePhraseReject. Not only is it present as an internal routine in versions 6.0 and 6.1 and declared in contemporaneous WDK headers but it even gets documented in the WDK for Windows 7.

Though ZwSetInformationVirtualMemory is not documented in the WDK for Windows 10 as integrated into Visual Studio 2015, it did show in a survey of Microsoft’s online documentation on 27th February 2016. It was then, and still is, very specific that the function is “Available starting with Windows 10, version 1511” and since the same version’s WDK is the first to declare the function in any of the usual headers, I surmise that 1511 is the release for which the function was first documented.

Old Friends

Several more functions that are exported from all earlier versions of x64 builds are now exported from x86 builds too. One, however, is discontinued as an export from both builds in the very next version.

• ExAcquireFastMutex (5.2 SP1)
• ExReleaseFastMutex (5.2 SP1)
• ExTryToAcquireFastMutex (5.2 SP1)
• KeAcquireInStackQueuedSpinLock (5.2 SP1)

Discontinued

Version 6.2 also stops exporting a few functions. For each, the version in parentheses tells when the function was first exported:

• ExUpdateLicenseData (6.0), but see note
• IoSetOplockKeyContext
• Ke386CallBios (3.10)
• KeI386AbiosCall (3.10)
• KeI386AllocateGdtSelectors (3.10)
• KeI386Call16BitCStyleFunction (4.0)
• KeI386Call16BitFunction (3.51)
• KeI386FlatToGdtSelector (3.10)
• KeI386GetLid (3.10)
• KeI386ReleaseGdtSelectors (3.51)
• KeI386ReleaseLid (3.10)
• KeI386SetGdtSelector (3.51)
• KeProfileInterrupt (3.10)
• KeUpdateSystemTime (3.10)
• PsChargeProcessCpuCycles
• PsSetJobUIRestrictionsClass (5.1)
• TmpIsKTMCommitCoordinator

The one Executive function that version 6.2 discontinues as an export is restored as an export for version 10.0.