Revision in progress. Use caution.

Kernel Exports Added for Version 10.0

This page lists the 209 functions and 5 variables that are newly exported from the Windows kernel in its first release for version 10.0, i.e., for the original Windows 10. In the scheme that Microsoft seems since to have adopted for its bi-annual updates of Windows 10, this original release would be Version 1507. Two of the new functions are exported only in 32-bit Windows (x86) and twenty only in 64-bit Windows (x64).

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. 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.

Hardly any of the new functions for version 10.0 appear in the “Windows Driver Kit (WDK) 10” documentation that Microsoft “integrated with Visual Studio 2015”. An online search on 27th February 2016 turned up several additions that perhaps had been omitted only by oversight. These are identified in the table by the phrase “2015-2016”.

For all its lengthy and public promotion, Windows 10 seems sometimes at kernel level to have been rushed or neglected, if not in the coding then at least for presentation to kernel-mode programmers. It is already noted above that so few of the exported functions that were added to the kerrnel for Windows 10 were documented immediately. Indeed, few are documented even five years later. For signs that some of this is simple inattention, consider comments that accompany the declarations of ExCleanupRundownProtectionCacheAware and ExInitializeRundownProtectionCacheAwareEx. Apparently, these functions were declared early enough during development that no label was yet settled on for a constant to represent Windows 10 in comparisons with NTDDI_VERSION. Thus may it have happened that the functions are declared even if building for Windows 8.1, but what’s remarkable is that the declarations have stayed this way despite comments labelled TODO about updating to the correct “constant once available.”

Something similar applies to the many more Ex functions for which declarations are known only in NTOSP.H (disclosed perhaps by oversight before the 1607 release), but comments tell less of how the NTDDI_VERSION blocks came to be incorrect.

Especially notable among the undocumented functions are those whose names begin with Hvi. These are the run-time understanding in kernel mode of what Microsoft documents as the Hypervisor Top-Level Functional Specification, in turn published as part of a Microsoft Open Specification Promise. Even a year after the formal release of Windows 10, details that were encoded into these undocumented kernel functions were not yet in Microsoft’s published specification of its hypervisor. This might well be borne in mind by anyone who thinks that some sort of new Microsoft is commendably open regarding documentation.

Documentation of IoAllocateIrpEx was not found onlline when looking in 2016 and 2018, but is there today, 17th September 2020. I see no reason to doubt Microsoft’s date, which is 11th October 2019. The summary at its top may be Microsoft’s first formal reference in public to an IRP Extension. That nothing is then said about it in the documentation’s Remarks, which are mostly copied from those for the plain old IoAllocateIrp, should not surprise.

Though KeFlushIoBuffers is new for Windows 10 as a function that is exported from the x86 or x64 kernel, it is in fact ancient. For other processors, it is from the start, i.e., version 3.10, both declared and documented. For the x86 processor and later for the x64, it is defined away by macro until version 10.0—and still is if the target operating system is older.

I may have missed Microsoft’s documentation of KeShouldYieldProcessor when looking onlline in 2016 and 2018. It is there today, 17th September 2020. I take Microsoft at its word that this documentation dates from 8th November 2019.

Online documentation of PoCreateThermalRequest, PoGetThermalRequestSupport, PoSetThermalActiveCooling and PoSetThermalPassiveCooling as I see it today, 17th September 2020, is well separated from other documentation and I can’t say certainly that my surveys in 2016 and 2018 would have found it. Microsoft’s date for all pages is 2nd October 2019. Because this is much later than the 2018 date that Microsoft now shows for most of its online WDK documentation, even of functions that have been documented since 1993, I accept it as the date of first publication. The set is surely meant to include PoDeleteThermalRequest too: the page for PoCreateThermalRequest mentions it for a link, but what the link reaches is PoDeletePowerRequest. Note the recurring theme about Windows 10 in terms of kernel-mode documentation: very little, and done with very little care.

The many Ps functions for working with silos mostly started as undocumented but declared. That they were not initially documented may have been because the interface was in flux. More than a few were soon discontinued or superseded, with significant additions for the 1511 and 1607 releases. Most of the survivors then became documented as if new for 1607.

The interface’s instability shows especially for PsDeleteMonitorContextServerSilo: it picks up an extra argument in 1511, only for the whole function to be removed from the interface in 1607.

What documentation of PsGetServerSiloServiceSessionId survives at Microsoft’s website (today, 17th September 2020) is separate from that of other silo functions, still warns that it “relates to pre-released product” and now comes with the disclaimer that Microsoft is “no longer updating this content regularly.” The documentation is dated to 10th June 2016, which seems plausible as a date of first publication.

It is in some sense difficult to regard PsLoadedModuleList as undocumented. Its existence as an internal variable is among the mostly widely known of all implementation details in kernel-mode Windows programming. Has it ever been possible to do any kernel-mode debugging without seeing some mention of it? Still, its easy accessibility as an exported variable is new for Windows 10. Safe access pretty much requires that a corresponding synchronisation object is exported too, as with PsLoadedModuleResource (not that synchronisation of access has in years past been much concern to the sorts of kernel-mode programmers who might better be described pejoratively as hackers). The wonder is that Microsoft exposes the module list now, after all these years, but doesn’t document having done so.

Additionally, ExUpdateLicenseData, which is exported from versions 6.0 and 6.1 but then not from 6.2 or 6.3, is restored as an export for version 10.0. Another function, RtlPcToFileHeader, which earlier versions export only from x64 builds, becomes exported for x86 builds too.