Geoff Chappell, Software Analyst
Revision in progress. Use caution.
This page lists the functions that are newly exported from the Windows kernel in its 1607 release. Not only was the 1607 release marketed more substantially than was version 1511, it was more substantial technically, too, if only in terms of new functions that rise to the level of being exported. Indeed, the 1607 release adds more exports than has any service pack in the whole history of Windows. Would the 1607 release in bygone times have become version 10.1? Some such suggestion is built into the conditional-compilation blocks that specifiy which target versions each function is defined for. For this purpose, the original release was named Windows Threshold and the 1511 release is Windows 10 TH2, but the 1607 release begins a new sequence, as Windows 10 RS1.
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.
Very few of the additions for the 1607 release seem to be documented by Microsoft as far as shows up in a search online today (7th October 2018). By far the most that are documented are for working with silos. They either build on or supersede functionality that started in the original Windows 10 release. The original functions that survive are said to be new for 1607.
Name | Export History | Documentation History | Declaration History |
---|---|---|---|
CcGetCachedDirtyPageCountForFile | |||
CcInitializeCacheMapEx | before 1803, declared start is 10.0 |
Declaration of CcInitializeCacheMapEx starts out as conditional on building for version 10.0 or higher but is preceded by a comment TODO_NTDDI_WIN10_REDSTONE, suggesting that it was understood perfectly well that the condition was incorrect. Presumably, it remains from development before NTDDI_WIN10_RS1 had yet been settled on as connoting the 1607 release. Returning to it for correction evidently wasn’t urgent.
Name | Export History | Documentation History | Declaration History |
---|---|---|---|
ExCoreMessagingObjectType (data) | |||
ExEnumerateSystemFirmwareTables | |||
ExGetSystemFirmwareTable | |||
ExTryAcquireSpinLockExclusiveAtDpcLevel | |||
ExTryAcquireSpinLockSharedAtDpcLevel | |||
FsRtlIsDaxVolume | before 1803, declared start is 10.0 since 1803, declared start is 1511 |
||
FsRtlIsExtentDangling | before 1803, declared start is 10.0 since 1803, declared start is 1511 |
||
FsRtlIsNonEmptyDirectoryReparsePointAllowed | |||
FsRtlVolumeDeviceToCorrelationId | |||
HvlQueryProcessorTopologyEx |
The declarations of FsRtlIsExtentDangling and FsRtlIsDaxVolume in NTIFS.H from the WDK for the 1607, 1703 and 1709 releases are preceded by a comment TODO_NTDDI_WIN10_TH2. Whatever may be intended by the comment, neither the original nor the 1511 releases actually do export either of these functions. The first function, if not also the second, has so simple an implementation that it could be inlined in the 1511 release without being noticeable in the binary. The second is anyway documented as having 1607 as a minimum requirement. It’s hard to see, then, how acting on the comment to change the condition for declaration was any sort of correction.
Name | Export History | Documentation History | Declaration History |
---|---|---|---|
IoCleanupIrp | |||
IoGetIoAttributionHandle | |||
IoGetSilo | |||
IoRecordIoAttribution | |||
IoSetIoAttributionIrp | |||
KeQueryUnbiasedInterruptTimePrecise | declared start is 10.0 | ||
MmAllocatePartitionNodePagesForMdlEx | |||
MmFreePagesFromMdlEx | |||
MmGetPhysicalMemoryRangesEx | |||
MmPartitionObjectType (data) | discontinued in 1709 | ||
MmSetPermanentCacheAttribute | |||
PsAcquireSiloHardReference | |||
PsAllocSiloContextSlot | |||
PsCreateSiloContext | |||
PsDereferenceSiloContext | |||
PsFreeSiloContextSlot | |||
PsGetEffectiveServerSilo | |||
PsGetHostSilo | |||
PsGetJobSilo | |||
PsGetPermanentSiloContext | |||
PsGetProcessDxgProcess | |||
PsGetSiloContext | |||
PsGetSiloMonitorContextSlot | |||
PsInsertPermanentSiloContext | |||
PsInsertSiloContext | |||
PsIsProcessCommitRelinquished | |||
PsIsWin32KFilterAuditEnabled | |||
PsIsWin32KFilterEnabled | |||
PsMakeSiloContextPermanent | |||
PsQueryProcessCommandLine | |||
PsReferenceSiloContext | |||
PsRegisterSiloMonitor | |||
PsReleaseSiloHardReference | |||
PsRemoveSiloContext | |||
PsReplaceSiloContext | |||
PsSetProcessDxgProcess | |||
PsSiloContextNonPagedType (data) | |||
PsSiloContextPagedType (data) | |||
PsStartSiloMonitor | |||
PsTerminateServerSilo | |||
PsUnregisterSiloMonitor | |||
PsWow64GetProcessMachine | |||
RtlFindNextForwardRunClearCapped | |||
RtlGetActiveConsoleId | |||
RtlGetConsoleSessionForegroundProcessId | |||
RtlGetNtProductType | |||
RtlGetSuiteMask | before 2018, declared documented only in SDK documented start is 10.0 |
||
RtlIsMultiUsersInSessionSku | |||
RtlRaiseStatus | |||
RtlSetActiveConsoleId | |||
RtlSetConsoleSessionForegroundProcessId |
Many Run Time Library (RTL) functions are written for use in both kernel and user modes. Most that are documented at all are documented in the WDK as if for kernel-mode programming but it has long been that a few turn up only in SDK documentation for application programming. For RtlGetSuiteMask the documentation is outright ambiguous. At Microsoft’s website today, 24th September 2020, the one page for this function is placed in System Information for Win32 programming, but its HTML title seeks to have it both ways, with “Ntddk.h” in parentheses and “Win32 apps” after a hyphen. Where it presents Windows 10 among the function’s Requirements, it’s for “desktop apps only” and it plainly means that the function is imported from NTDLL.DLL in user mode. Even as an NTDLL export, the function requires at least the 1607 release. Perhaps Microsoft is still sorting out the details: after all, it still warns that “Some information relates to pre-released product”. The documentation is dated 31st May 2018 and I see no reason for disbelief.
Name | Export History | Documentation History | Declaration History |
---|---|---|---|
SeEtwWriteKMCveEvent | documented start is 10.0 | declared start is 10.0 | |
SeILSigningPolicyPtr (data) | |||
SeQuerySecureBootPlatformManifest | |||
SeQuerySecurityAttributesTokenAccessInformation | |||
TtmNotifyDeviceArrival | |||
TtmNotifyDeviceDeparture | |||
TtmNotifyDeviceInput | |||
VmPauseResumeNotify | discontinued in 1709 | ||
ZwCommitRegistryTransaction | declared start is 1511 | ||
ZwCreatePartition | |||
ZwCreateProcessEx | |||
ZwCreateProfileEx | |||
ZwCreateRegistryTransaction | declared start is 1511 | ||
ZwManagePartition | |||
ZwOpenPartition | |||
ZwOpenRegistryTransaction | declared start is 1511 | ||
ZwQueryIntervalProfile | |||
ZwQueryTimerResolution | |||
ZwRollbackRegistryTransaction | declared start is 1511 | ||
ZwSetIntervalProfile | |||
ZwSetTimerResolution | |||
ZwStartProfile | |||
ZwStopProfile |
Many of the Zw functions that are newly exported from the kernel in the 1607 release are declared in early editions of the WDK for Windows 10. In each case, the function has earlier history in user mode as an export from NTDLL.DLL.