Geoff Chappell - Software Analyst
This page lists the 247 exports that were newly exported from the Windows kernel for the original Windows XP.
Also listed are six additions for Windows XP SP1, 19 for Windows XP SP2 and four for Windows XP SP3. A handful of other exports perhaps were designed for version 5.1, and are mostly dated to Windows XP by Microsoft, but were back-fitted to Windows 2000 such that they appear first, in order of version number, as additions for Windows 2000 SP3.
To convey more detail with less text, the page relies heavily on several types of shortcut.
The first is that although a few of the kernel’s exports are of variables rather than functions, I tend to talk of all as functions, hoping that no confusion will be caused by the loose terminology. The variables are indicated by a parenthetical “data” after their first appearance in the Functions column.
Documentation status is summarised by colour coding. (Had the website’s scripts run as expected, then hovering over any colour-coded text would produce a tooltip that shows why the text is coloured.) (To decode a colour, hover for a tooltip.)
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. If a function is documented as reserved or obsolete, it is shaded red or shaded grey, respectively. Otherwise, functions that have their own non-trivial documentation are left with no background colour.
Many undocumented functions and some variables have C-language declarations in one or another header file. To show them as being not completely undocumented they 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 disclosure even of the declaration was exceptional.
The default understanding is that exporting continues for all later versions, and in both the x86 and x64 builds. Exceptions are sketched in a column headed Export History.
The description “x86 only” means that the function is not exported from any known x64 build but is exported from the x86 build of at least some version that has an x64 build. If it had already ceased as an export before Windows Server 2003 SP1, the “x86 only” is left unstated.
That a function is “discontinued in” some version means that the function is exported up to but not including the stated version and not in any later version unless “restored”.
It’s nothing but fair to note that the majority of these functions were not documented immediately. Even more were then or later said to require later versions. These misrepresentations of actual availability show also in C-language declarations for the functions’ use in programming. Conveying these differences between what the kernel exported and what Microsoft presented for drivers to import is the concern of columns headed Documentation History and Declaration History.
Conventions still in development!
As much as I might like to condense into one table as much as might be imagined is possible to summarise about all these functions’ history of availability both in the binary and according to the documentation and headers, many functions both individually and in groups demand additional explanation in text. I therefore break the tabulation according to Microsoft’s scheme of prefixes for separate areas of functionality within the otherwise monolithic kernel. Each function has its own row in one table, but please be sure to check for explanatory text before and (more usually) after the table.
Just more than 40% of these new exports for version 5.1 are nowadays documented. For most, the documentation states (correctly) that the function is “available on Microsoft Windows XP and later”. Six functions are documented only as being reserved, without even saying which versions have them. Another four are documented as obsolete, again without saying which versions have them. A small proportion of the new functions 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 XP and higher. For well more than a decade nearly a half of the new functions had neither documentation nor declaration—and then Microsoft published declarations for nearly all of them, only in the first two releases of the WDK for Windows 10, all too plausibly only by oversight.
| Function | Export History |
|---|---|
| CcMdlWriteAbort |
| Function | Documentation History |
|---|---|
| CmRegisterCallback | before 5.2 SP1, declared |
| CmUnRegisterCallback | before 5.2 SP1, declared |
| Function | Export History |
|---|---|
| DbgPrintEx | |
| DbgQueryDebugFilterState | |
| DbgSetDebugFilterState |
| Function | Export History | Documentation History |
|---|---|---|
| ExAcquireRundownProtection | before 5.2 SP1, undocumented; before 6.2, declared |
|
| ExAcquireRundownProtectionEx | starts in SP2 | before 5.2 SP1, undocumented; before 6.2, declared; documented start is 5.2 |
| ExGetCurrentProcessorCounts | ||
| ExGetCurrentProcessorCpuUsage | ||
| ExInitializeRundownProtection | before 5.2 SP1, undocumented; before 6.2, declared |
|
| ExReInitializeRundownProtection | before 5.2 SP1, undocumented; before 6.2, declared |
|
| ExReleaseRundownProtection | before 5.2 SP1, undocumented; before 6.2, declared |
|
| ExReleaseRundownProtectionEx | starts in SP2 | before 5.2 SP1, undocumented; before 6.2, declared; documented start is 5.2 |
| ExRundownCompleted | before 5.2 SP1, undocumented; before 6.2, declared |
|
| ExVerifySuite | before 6.0, declared | |
| ExWaitForRundownProtectionRelease | before 5.2 SP1, undocumented; before 6.2, declared |
|
| ExfAcquirePushLockExclusive | starts in SP2 | |
| ExfAcquirePushLockShared | starts in SP2 | |
| ExfInterlockedCompareExchange64 | x86 only | |
| ExfReleasePushLock | starts in SP2 |
| Function | Export History | Documentation History | Declaration History |
|---|---|---|---|
| FsRtlCreateSectionForDataScan | starts in SP3; discontinued in 5.2; restored in 5.2 SP1 |
in 6.0, documented start is 5.2 SP1; since 6.1, documented start is 5.0 SP4 rollup |
since 6.0, declared start is 5.0 |
| FsRtlIncrementCcFastReadNoWait | |||
| FsRtlIncrementCcFastReadNotPossible | |||
| FsRtlIncrementCcFastReadResourceMiss | |||
| FsRtlIncrementCcFastReadWait | |||
| FsRtlInsertPerFileObjectContext | before 6.1, declared; documented start is 6.0 |
||
| FsRtlInsertPerStreamContext | documented start is 5.0 SP4 rollup | ||
| FsRtlIsPagingFile | documented start is 5.0 SP4 rollup | ||
| FsRtlLookupPerFileObjectContext | before 6.1, declared; documented start is 6.0 |
||
| FsRtlLookupPerStreamContextInternal | |||
| FsRtlNotifyFilterChangeDirectory | documented start is 5.0 SP4 rollup | ||
| FsRtlNotifyFilterReportChange | documented start is 5.0 SP4 rollup | since 6.0, declared start is 5.0 | |
| FsRtlRegisterFileSystemFilterCallbacks | before 6.2, documented start is 5.0 SP4 rollup | ||
| FsRtlRemovePerFileObjectContext | before 6.1, declared; documented start is 6.0 |
||
| FsRtlRemovePerStreamContext | documented start is 5.0 SP4 rollup | ||
| FsRtlTeardownPerStreamContexts | documented start is 5.0 SP4 rollup | since 6.0, declared start is 5.0 |
Some of the File System Run Time Library functions have complicated histories. Chronologically, they are exported first in version 5.1, and are so listed above. According to documentation, they were then back-fitted to an Update Rollup for Windows 2000 SP4. This is not formally a service pack, and would ordinarily fall outside the scope of this study, yet it plainly was intended as more than a hotfix.
The FsRtlCreateSectionForDataScan function is even more complicated. It might better be regarded as first exported for version 5.2 SP1 and then back-fitted to late builds of both version 5.0 and version 5.1. For version 5.0, this again means the Update Rollup for Windows 2000 SP4. For version 5.1, documentation cites a Filter Manager Rollup for Windows XP SP2. The first actual service pack of version 5.1 that has the function is then SP3, as noted above. Note anyway that Microsoft took its time over having its documentation tell of this function’s support in any of these updates.
Though FsRtlLookupPerStreamContextInternal is documented as reserved as early as the WDK for Windows Vista, it is the essence of the FsRtlLookupPerStreamContext macro which is documented as starting with the Update Rollup for Windows 2000 SP4.
The FsRtlRegisterFileSystemFilterCallbacks function is unusual in that its documented support in the Update Rollup for Windows 2000 SP4 is withdrawn.
| Function | Export History |
|---|---|
| HalExamineMBR |
The HalExamineMBR function has earlier history, back to version 3.51, as a macro that calls through the HalDispatchTable to an externally provided handler or to a default in the kernel. The earliest known documentation is in the DDK for Windows NT 4.0. Whether the documentation is of the macro or the exported function, it is notable for a long-standing error: not until version 6.2 does it give the correct type for the Buffer argument.
| Function | Export History |
|---|---|
| HeadlessDispatch |
| Function | Export History | Documentation History |
|---|---|---|
| InterlockedPopEntrySList | x86 only | SDK |
| InterlockedPushEntrySList | x86 only | SDK |
The “sequenced interlocked list” had been introduced to kernel-mode programming in version 4.0. It was as first a creature of the Executive, supported by macros and functions whose names each have the Ex prefix. This early support required that a spin lock be supplied even if the implementation could make do without it. With version 5.1 requiring the cmpxchg8b instruction, the implementation certainly could make do without a spin lock and the programming of drivers that would run only on Windows XP and higher was therefore simplified: these new functions that don’t have the Ex prefix don’t require a spin lock. What matters here for a survey of documentation status is that they were documented not in the DDK but in the Platform Software Development Kit (SDK) for user-mode programming—and there they have stayed. Though they plainly always have been intended as documented, they seem never to have been documented explicitly for use in kernel mode. Even after Microsoft reorganised its programming documentation in terms of header files in 2018, these functions are skipped from the many pages for WDM.H and NTDDK.H.
| Function | Export History | Documentation History | Declaration History |
|---|---|---|---|
| IoAssignDriveLetters | discontinued in 6.1; (also from HAL before 6.1) |
||
| IoAttachDeviceToDeviceStackSafe | documented start is 5.0 SP4 rollup | ||
| IoCreateDisk | |||
| IoCreateFileSpecifyDeviceObjectHint | |||
| IoCreateStreamFileObjectEx | |||
| IoCsqInitialize | |||
| IoCsqInsertIrp | |||
| IoCsqRemoveIrp | |||
| IoCsqRemoveNextIrp | |||
| IoEnumerateDeviceObjectList | documented start is 5.0 SP4 rollup | ||
| IoEnumerateRegisteredFiltersList | starts in SP3; discontinued in 5.2; restored in 5.2 SP1 |
documented start is 5.0 SP4 rollup and 5.2 SP1 | since 6.0, declared start is 5.2 SP1 |
| IoForwardAndCatchIrp | |||
| IoForwardIrpSynchronously | |||
| IoFreeErrorLogEntry | |||
| IoGetDeviceAttachmentBaseRef | documented start is 5.0 SP4 rollup | ||
| IoGetDiskDeviceObject | documented start is 5.0 SP4 rollup | ||
| IoGetLowerDeviceObject | documented start is 5.0 SP4 rollup | ||
| IoInitializeCrashDump | starts in SP3; discontinued in 5.2 |
||
| IoQueryFileDosDeviceName | |||
| IoReadDiskSignature | |||
| IoReadPartitionTable | also from HAL since 3.10 | before 5.1, documented (HAL) | deprecated |
| IoReadPartitionTableEx | |||
| IoSetCompletionRoutineEx | |||
| IoSetPartitionInformation | also from HAL since 3.10 | before 5.1, documented (HAL) | deprecated |
| IoSetPartitionInformationEx | |||
| IoSetStartIoAttributes | |||
| IoSetSystemPartition | |||
| IoValidateDeviceIoControlAccess | starts in SP1 | documented start is 5.2 | |
| IoVerifyPartitionTable | |||
| IoVolumeDeviceToDosName | |||
| IoWMIDeviceObjectToInstanceName | |||
| IoWMIExecuteMethod | |||
| IoWMIHandleToInstanceName | |||
| IoWMIOpenBlock | |||
| IoWMIQueryAllData | |||
| IoWMIQueryAllDataMultiple | |||
| IoWMIQuerySingleInstance | |||
| IoWMIQuerySingleInstanceMultiple | since 6.0, declared start is 5.0 | ||
| IoWMISetNotificationCallback | |||
| IoWMISetSingleInstance | |||
| IoWMISetSingleItem | |||
| IoWritePartitionTable | also from HAL since 3.10 | before 5.1, documented (HAL) | deprecated |
| IoWritePartitionTableEx |
The IoAssignDriveLetters , IoReadPartitionTable, IoSetPartitionInformation and IoWritePartitionTable functions are original exports from the HAL. They are both the oldest and the first HAL exports to have got moved in some sense to the kernel. Redistribution of their functionality had been under way for some years. Version 3.51 had the HAL’s implementations call through the kernel’s HalDispatchTable, typically (though not necessarily) reaching default handlers in the kernel. Version 5.1 simply elevated those default handlers from internal routines to exported functions.
The several functions such as IoCsqInitialize for cancel-safe IRP queues are among those that are new for Windows XP and which the DDK for Windows XP unremarkably documents as being new for Windows XP. Microsoft’s formula is worth noting, however: “only available as part of the operating system on Windows XP and later.” Use of these cancel-safe queues is sufficiently important that Microsoft made it available to new drivers that find themselves running on Windows 2000. Instead of calling the exported functions, drivers that anticipate this execution can instead call routines from a statically linked library, csq.lib, which Microsoft continued to distribute up to and including the WDK for Windows 7. Note the implication that these cancel-safe queues were functionality that Microsoft realised programmers far and wide could have been coding for themselves all along, and should have been as standard practice, but hadn’t been.
The IoEnumerateRegisteredFiltersList function is another that may better be regarded as an export added for version 5.2 SP1 but then back-fitted to late builds of versions 5.0 and 5.1. Documentation starts the back-fit to version 5.0 with the Update Rollup for Windows 2000 SP4. Very plausibly, its back-fit to version 5.1 starts with the Filter Manager Rollup for Windows XP SP2, but no known documentation even catches that the function is exported from Windows XP SP3.
The IoValidateDeviceIoControlAccess function seems similarly to have been introduced to nudge programmers towards some discipline. It is available to new drivers on old Windows versions if they call the function as a routine in a statically linked library, wdmsec.lib, instead of importing it from the kernel. There is practical merit to using the library in a driver that wants to tolerate being loaded on a Windows XP that predates the function’s availability as an export from the kernel, but the documentation is incorrect about when this availablity starts. To the DDK for Windows XP, the function is “only available as part of the operating system on Windows .NET Server and later operating systems.” Later kits continue the (slight and no-doubt well-intended) misrepresentation except that they know what name was settled on for marketing.
| Function | Export History |
|---|---|
| KdPowerTransition |
| Function | Export History |
|---|---|
| KeAcquireInStackQueuedSpinLockAtDpcLevel | |
| KeAcquireInterruptSpinLock | |
| KeAreApcsDisabled | |
| KeCapturePersistentThreadState | starts in SP1 |
| KeDeregisterBugCheckReasonCallback | starts in SP1 |
| KeFlushQueuedDpcs | starts in SP2 |
| KeGetRecommendedSharedDataAlignment | |
| KeIsAttachedProcess | |
| KeQueryRuntimeThread | |
| KeRegisterBugCheckReasonCallback | starts in SP1 |
| KeReleaseInStackQueuedSpinLockFromDpcLevel | |
| KeReleaseInterruptSpinLock | |
| KeRemoveByKeyDeviceQueueIfBusy | |
| KeRemoveSystemServiceTable |
The KeFlushQueuedDpcs function was documented in the DDK for Windows XP (and declared in both NTDDK.H and WDM.H) even while the kernel had it only as an internal routine. It does not become an export until SP2.
| Function | Export History | Documentation History |
|---|---|---|
| MmAddVerifierThunks | before 6.0, declared | |
| MmAdvanceMdl | ||
| MmAllocateMappingAddress | ||
| MmCommitSessionMappedView | starts in SP2 | |
| MmFreeMappingAddress | ||
| MmIsVerifierEnabled | before 6.0, declared; before 6.2, reserved |
|
| MmMapLockedPagesWithReservedMapping | ||
| MmMarkPhysicalMemoryAsBad | ||
| MmMarkPhysicalMemoryAsGood | ||
| MmPrefetchPages | ||
| MmProtectMdlSystemAddress | ||
| MmUnmapReservedMapping |
In the WDK for Windows Vista and again for Windows 7, MmIsVerifierEnabled is on a list of Memory Manager Routines that are “reserved for system use.” The WDK for Windows 8 drops the function from this list. The reason is not known: unlike the slightly older MmIsDriverVerifying, it is not dropped from the list for being newly documented. It just returns to being a function that’s declared but undocumented.
The MmMarkPhysicalMemoryAsBad and MmMarkPhysicalMemoryAsGood functions have never been anything but reserved, but they are slightly notable in that their declarations in the DDK for Windows XP were removed for subsequent versions.
The functions whose names begin with Nt correspond closely to functions whose names have the Zw prefix instead (see below). Put aside some general points about how the two differ—see The Native API— and documentation of an Nt function is to a large extent implied by documentation of the corresponding Zw function.
Though this correspondence will have been understood well enough by all competent kernel-mode programmers, Microsoft didn’t make it explicit until some time after releasing the WDK for Windows Vista. This is here taken as an intention to leave the Nt functions undocumented (if not declared) before version 6.1.
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 Zw documentation might then be treated as counting for both, except that the Nt documentation warns expressly “Do not call this routine from kernel-mode code.” This is here taken as documenting the Nt functions as reserved in version 6.1 (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” and to refer to a page of guidance. These changes, though slight, are taken here as formally permitting the Nt functions’ kernel-mode use, such that they must now be counted as documented (though delayed).
While each Nt function is documented only by reference to the Zw function, whatever documented availability Microsoft gives for the latter is here taken as intended also for the former. In the headers, however, the two functions necessarily each have their own declaration (if they have any), and so any “declared start” shown below is specifically for the Nt function.
| Function | Documentation History | Declaration History |
|---|---|---|
| NtMakePermanentObject | ||
| NtOpenProcessTokenEx | before 6.1, declared; in 6.1, reserved |
|
| NtOpenThread | ||
| NtOpenThreadToken | since 6.0, declared start is 5.0 | |
| NtOpenThreadTokenEx | before 6.1, declared; in 6.1, reserved |
|
| NtQueryInformationThread | ||
| NtShutdownSystem | ||
| NtTraceEvent |
The NtQueryInformationThread function is mentioned in a comment in NTDDK.H from at least as far back as the Windows NT 3.51 DDK, presumably for its export from NTDLL.DLL in user mode, but has never yet been declared for use in programming.
| Function | Export History | Documentation History | Declaration History |
|---|---|---|---|
| ObCloseHandle | before 6.2, undocumented; before 6.3, declared; documented start is 5.0 |
since 6.2, declared start is 6.1 | |
| ObCreateObjectType | |||
| ObDereferenceSecurityDescriptor | |||
| ObIsDosDeviceLocallyMapped | starts in SP3; discontinued in 5.2; restored in 6.0 |
declared start is 6.0 | |
| ObLogSecurityDescriptor | |||
| ObReferenceSecurityDescriptor | |||
| ObSetHandleAttributes | |||
| ObSetSecurityObjectByPointer |
The ObCloseHandle function has got caught in some sort of tug-of-war between the documentation and the headers. Perhaps its documentation was squeezed into the WDK for Windows 8 too late to get it declared in a header. Someone took some care to save programmers some small inconvenience by documenting that the function “is not declared in a header file” and even to present a declaration to copy-and-paste. This declaration, like the documentation, would have it that the function starts in version 5.0. When a declaration did get into a header in the very next WDK, i.e., for Windows 8.1, it was made conditional on building for at least Windows 7. Whoever revised the documentation seems to have anticipated use by drivers running on older Windows and amended the declaration in the documentation to support all target operating systems older than Windows 7.
| Function | Documentation History | Declaration History |
|---|---|---|
| PoQueueShutdownWorkItem | ||
| PoRequestShutdownEvent | before 6.0, declared |
The DDK for Windows XP and again for Windows Server 2003 declares PoRequestShutdownEvent in both NTDDK.H and WDM.H. Then the declaration disappears. Put this aside as not quite ancient history and the function would now count as undocumented except for the presumably accidental disclosure of NTOSP.H.
| Function | Export History | Documentation History | Declaration History |
|---|---|---|---|
| PsChargeProcessNonPagedPoolQuota | |||
| PsChargeProcessPagedPoolQuota | |||
| PsChargeProcessPoolQuota | |||
| PsDereferenceImpersonationToken | |||
| PsDereferencePrimaryToken | |||
| PsGetContextThread | starts in SP1 | ||
| PsGetCurrentProcess | since 6.1 revision, documented start is 5.0 | ||
| PsGetCurrentProcessSessionId | |||
| PsGetCurrentThread | since 6.1 revision, documented start is 5.0 | ||
| PsGetCurrentThreadPreviousMode | |||
| PsGetCurrentThreadStackBase | |||
| PsGetCurrentThreadStackLimit | |||
| PsGetJobLock | |||
| PsGetJobSessionId | |||
| PsGetJobUIRestrictionsClass | |||
| PsGetProcessCreateTimeQuadPart | before 6.1, undocumented | ||
| PsGetProcessDebugPort | |||
| PsGetProcessExitProcessCalled | |||
| PsGetProcessExitStatus | before 6.2, undocumented | ||
| PsGetProcessId | before 6.0, undocumented | ||
| PsGetProcessImageFileName | |||
| PsGetProcessInheritedFromUniqueProcessId | |||
| PsGetProcessJob | |||
| PsGetProcessPeb | |||
| PsGetProcessPriorityClass | |||
| PsGetProcessSectionBaseAddress | |||
| PsGetProcessSecurityPort | |||
| PsGetProcessSessionId | |||
| PsGetProcessWin32Process | |||
| PsGetProcessWin32WindowStation | |||
| PsGetThreadFreezeCount | |||
| PsGetThreadHardErrorsAreDisabled | |||
| PsGetThreadId | before 6.1, undocumented | ||
| PsGetThreadProcess | before 6.2, undocumented | ||
| PsGetThreadProcessId | before 6.1, undocumented; before 2015-2018, declared; documented start is 6.0 |
declared start is 5.2 | |
| PsGetThreadSessionId | |||
| PsGetThreadTeb | |||
| PsGetThreadWin32Thread | |||
| PsIsProcessBeingDebugged | |||
| PsIsSystemThread | before 6.1, declared | ||
| PsIsThreadImpersonating | |||
| PsRemoveCreateThreadNotifyRoutine | before 5.2 SP1, declared | ||
| PsRemoveLoadImageNotifyRoutine | before 5.2 SP1, declared | ||
| PsReturnProcessNonPagedPoolQuota | |||
| PsReturnProcessPagedPoolQuota | |||
| PsRevertThreadToSelf | |||
| PsSetContextThread | starts in SP1 | ||
| PsSetJobUIRestrictionsClass | discontinued in 6.2 | ||
| PsSetProcessPriorityClass | |||
| PsSetProcessSecurityPort | |||
| PsSetProcessWin32Process | |||
| PsSetProcessWindowStation | |||
| PsSetThreadHardErrorsAreDisabled | |||
| PsSetThreadWin32Thread |
The PsDereferenceImpersonationToken and PsDereferencePrimaryToken function have earlier history, at least back to the NTIFS.H from the Windows 2000 IFS Kit, as macros.
The PsGetCurrentProcess function has always been documented, i.e., right from the DDK for Windows NT 3.1, but not until version 5.1 does the kernel actually export it. In all versions, it is defined by macro as an alias of the exported IoGetCurrentProcess. The latter was at first just an implementation detail: it is not documented until the DDK for Windows NT 4.0. As exported functions in version 5.1 and higher, the two have the same address.
The story is similar for PsGetCurrentThread, but slightly different. It has always been documented. It’s just not an exported function before version 5.1. It is instead defined by macro as KetGetCurrentThread but with a change of type for the return value. The macro was dropped by the WDK for Windows 7.
| Function | Export History | Documentation History | Declaration History |
|---|---|---|---|
| RtlAddAccessAllowedAceEx | starts in SP2 | before 6.1, undocumented; documented start is 5.0 |
declared start is 5.0 |
| RtlClearBit | before 6.0, declared | ||
| RtlCreateSystemVolumeInformationFolder | |||
| RtlDeleteElementGenericTableAvl | before 6.2, declared | ||
| RtlEnumerateGenericTableAvl | before 6.2, declared | ||
| RtlEnumerateGenericTableLikeADirectory | |||
| RtlEnumerateGenericTableWithoutSplayingAvl | before 6.2, declared | ||
| RtlGetElementGenericTableAvl | before 6.1, declared | ||
| RtlGetSetBootStatusData | |||
| RtlGetVersion | since 6.1 revision, documented start is 5.0 | since 6.0, declared start is 5.0 | |
| RtlHashUnicodeString | before 6.0, declared | ||
| RtlInitializeGenericTableAvl | before 6.2, declared | ||
| RtlInsertElementGenericTableAvl | before 6.2, declared | ||
| RtlInsertElementGenericTableFullAvl | |||
| RtlInt64ToUnicodeString | since 6.1 revision, documented start is 5.0 | since 6.0, declared start is 5.0 | |
| RtlIntegerToUnicode | |||
| RtlIpv4AddressToStringA | before 6.0, undocumented; documented only in SDK; documented start is 6.0; in 6.0, not declared |
||
| RtlIpv4AddressToStringExA | starts in SP2 | before 6.0, undocumented; documented only in SDK; documented start is 6.0; in 6.0, not declared |
|
| RtlIpv4AddressToStringExW | starts in SP2 | before 6.0, undocumented; documented only in SDK; documented start is 6.0; in 6.0, not declared |
|
| RtlIpv4AddressToStringW | before 6.0, undocumented; documented only in SDK; documented start is 6.0; in 6.0, not declared |
||
| RtlIpv4StringToAddressA | before 6.0, undocumented; documented only in SDK; documented start is 6.0; in 6.0, not declared |
||
| RtlIpv4StringToAddressExA | starts in SP2 | before 6.0, undocumented; documented only in SDK; documented start is 6.0; in 6.0, not declared |
|
| RtlIpv4StringToAddressExW | starts in SP2 | before 6.0, undocumented; documented only in SDK; documented start is 6.0; in 6.0, not declared |
|
| RtlIpv4StringToAddressW | before 6.0, undocumented; documented only in SDK; documented start is 6.0; in 6.0, not declared |
||
| RtlIpv6AddressToStringA | before 6.0, undocumented; documented only in SDK; documented start is 6.0; in 6.0, not declared |
||
| RtlIpv6AddressToStringExA | starts in SP2 | before 6.0, undocumented; documented only in SDK; documented start is 6.0; in 6.0, not declared |
|
| RtlIpv6AddressToStringExW | starts in SP2 | before 6.0, undocumented; documented only in SDK; documented start is 6.0; in 6.0, not declared |
|
| RtlIpv6AddressToStringW | before 6.0, undocumented; documented only in SDK; documented start is 6.0; in 6.0, not declared |
||
| RtlIpv6StringToAddressA | before 6.0, undocumented; documented only in SDK; documented start is 6.0; in 6.0, not declared |
||
| RtlIpv6StringToAddressExA | starts in SP2 | before 6.0, undocumented; documented only in SDK; documented start is 6.0; in 6.0, not declared |
|
| RtlIpv6StringToAddressExW | starts in SP2 | before 6.0, undocumented; documented only in SDK; documented start is 6.0; in 6.0, not declared |
|
| RtlIpv6StringToAddressW | before 6.0, undocumented; documented only in SDK; documented start is 6.0; in 6.0, not declared |
||
| RtlIsGenericTableEmptyAvl | before 6.2, declared | ||
| RtlLockBootStatusData | |||
| RtlLookupElementGenericTableAvl | before 6.2, declared | ||
| RtlLookupElementGenericTableFullAvl | |||
| RtlMapSecurityErrorToNtStatus | |||
| RtlNumberGenericTableElementsAvl | before 6.2, declared | ||
| RtlRandomEx | |||
| RtlSetBit | before 6.0, declared | ||
| RtlTestBit | before 6.0, declared | ||
| RtlTimeToElapsedTimeFields | |||
| RtlUnlockBootStatusData | |||
| RtlVerifyVersionInfo | since 6.1 revision, documented start is 5.0 | since 6.0, declared start is 5.0 |
That the RtlAddAccessAllowedAceEx function, once it is documented at all in the WDK, is said to start with Windows 2000 has two obvious candidates for explanation. Its presence in the kernel as an internal routine from as long ago as version 5.0 found its way into the documentation. It is exported from NTDLL.DLL starting with version 5.0, and the WDK documentation, if only of the RTL functions, is doing double duty for kernel mode and user mode.
The RtlGetVersion function is documented in the DDK for Windows 2000 as “the kernel-mode equivalent of the user-mode GetVersionEx function.” The RtlVerifyVersionInfo function is simlarly “the kernel-mode equivalent of the user-mode VerifyVersionInfo”. Kernel-mode programmers who thought to use either as the new and approved way of learning any sort of Windows version number or of testing for “operating system attributes” will have been unhappy. Both functions are exported from NTDLL in user mode in version 5.0 and both are declared in NTDDK.H as if for kernel-mode programming but neither actually is exported from the kernel. Frustrated programmers may have complained in the right places or Microsoft may simply have noticed the need for correction: for both functions, documentation in the DDK for Windows XP is very clear that “This routine is supported on Windows XP and later”. Years later, this rare but good work came undone as the functions got caught up in Microsoft’s over-zealous exercise in historical revision: a second edition of the WDK for Windows 7 goes back to telling kernel-mode programmers that the functions are “Available in Windows 2000 and later”.
Also documented in the DDK for Windows 2000 despite being unavailable in kernel mode is RtlInt64ToUnicodeString. Again, version 5.0 is the first that has the function as a user-mode export.
The 16 functions for converting IP addresses to and from text are not formally documented for use in kernel mode, only as user-mode exports from NTDLL. They are declared in IP2STRING.H, which is supplied with every WDK starting with Windows 7. A comment at the top is explicit that this header’s declared routines are “callable by both kernel mode code in the executive and user mode code in various NT subsystems.” A reorganisation for Windows 8 places the header in the “shared” subdirectory. Since the functions’ user-mode documentation requires Windows Vista and the first known user-mode documentation is in the SDK for Windows Vista, they must be ruled as having been undocumented before Windows Vista even for user-mode programming.
| Function | Export History | Documentation History |
|---|---|---|
| SeAuditingFileEventsWithContext | starts in SP2 | |
| SeAuditingHardLinkEventsWithContext | starts in SP2 | |
| SeFilterToken | ||
| SeTokenIsWriteRestricted | starts in SP2; discontinued in 5.2; restored in 6.0 |
|
| SeTokenObjectType (data) | before 6.1, undocumented; indirectly documented |
Three Se functions are first exported from Windows XP SP2, if reckoning by version number. Chronologically, the two that tell of auditing start in version 5.2 and may then have been thought useful enough to back-fit into the next service pack of version 5.1. The story is more complicated for SeTokenIsWriteRestricted. Even chronologically, it is first exported from Windows XP SP2 without being taken up for version 5.2.
As with most exported variables, SeTokenObjectType is not itself documented. Starting with the WDK for Windows 7, however, it gets mentioned in the documentation of exported functions such as ObReferenceObjectByHandle from its being intended as an argument.
| Function | Documentation History | Declaration History |
|---|---|---|
| VerSetConditionMask | documented only in SDK | since 6.0, declared start is 5.0 |
Unlike RtlGetVersion and RtlVerifyVersionInfo (see above), VerSetConditionMask never has been documented explicitly for use in kernel mode.
| Function | Export History |
|---|---|
| VfFailDeviceNode | |
| VfFailDriver | |
| VfFailSystemBIOS | |
| VfIsVerificationEnabled |
| Function | Export History |
|---|---|
| WmiFlushTrace | discontinued in 6.0 |
| WmiGetClock | |
| WmiQueryTrace | discontinued in 6.0 |
| WmiQueryTraceInformation | |
| WmiStartTrace | discontinued in 6.0 |
| WmiStopTrace | discontinued in 6.0 |
| WmiTraceMessage | |
| WmiTraceMessageVa | |
| WmiUpdateTrace | discontinued in 6.0 |
| Function | Export History |
|---|---|
| XIPDispatch |
| Function | Documentation History | Declaration History |
|---|---|---|
| ZwAddBootEntry | ||
| ZwAssignProcessToJobObject | ||
| ZwCreateJobObject | ||
| ZwDeleteBootEntry | ||
| ZwEnumerateBootEntries | ||
| ZwIsProcessInJob | ||
| ZwOpenJobObject | ||
| ZwOpenProcessTokenEx | ||
| ZwOpenThreadTokenEx | ||
| ZwQueryBootEntryOrder | ||
| ZwQueryBootOptions | ||
| ZwQueryFullAttributesFile | before 6.1, undocumented; before 6.1 revision, documented start is 5.0 |
declared start is 5.0 |
| ZwQueryInformationJobObject | ||
| ZwQueryInformationThread | ||
| ZwSaveKeyEx | before 6.2, undocumented | declared start is 6.1 |
| ZwSetBootEntryOrder | ||
| ZwSetBootOptions | ||
| ZwSetInformationJobObject | ||
| ZwTerminateJobObject | ||
| ZwTranslateFilePath |
| Function | Export History | Documentation History |
|---|---|---|
| _CIcos | x86 only | before 2012, undocumented |
| _CIsin | x86 only | before 2012, undocumented |
| _CIsqrt | x86 only | before 2012, undocumented |
| _alldvrm | x86 only | |
| _alloca_probe | x86 only | |
| _aulldvrm | x86 only | |
| _vsnwprintf |
Calls to the _CIcos, _CIsin and _CIsqrt functions are generated by sufficiently early versions of Microsoft’s compiler when fed code that would call the CRT library’s cos, sin and sqrt functions, respectively. The first formal documentation I know of them is that each has its own page in the Alphabetical Function Reference of the C Run-Time Library Reference for Visual Studio 2012. Documentation for Visual Studio 2015 moved them to the Internal CRT Globals and Functions.
The _alldvrm and _aulldvrm functions are generated by Microsoft’s 32-bit compiler when fed code that seeks (in sufficient proximity) both the quotient and remainder from dividing signed or unsigned 64-bit integers. Microsoft has long published assembly-language source files for these functions along with other CRT library source code in the Visual Studio package. If you believe that source code is everything, then these functions are as fully documented as can be. Yet formal documentation is surprisingly scarce. For instance, within the C Run-Time Library Reference for Visual Studio 2015 (roughly contemporaneous with the original Windows 10) they don’t rate a mention in either the Alphabetical Function Reference or the list of Internal CRT Globals and Functions.
Microsoft’s CRT library has long implemented the _alloca_probe function as an alias for the _chkstk function. Microsoft’s compilers generate a call to the latter from the prologue code of any function that seeks too much space for local variables. Again, the assembly-language source code is published and so the function can hardly be regarded as undocumented. And again, formal documentation is surprisingly scarce.
| Function | Documentation History |
|---|---|
| vDbgPrintEx | before 6.0, declared |
| vDbgPrintExWithPrefix | before 6.1, declared |
Version 5.1 stops exporting a few functions. For each, the version in parentheses tells when the function was first exported:
Unusually, several had been documented, albeit as obsolete.
Version 5.1 discontinues the ObDeleteCapturedInsertInfo function only to have version 5.2 restore it as an export. This may be an illusion due to this survey’s reckoning by increasing version number. Chronologically, the function was introduced for version 5.2. Its listing for a lower version is then explained as back-fitting into the last service pack of Windows 2000, but this still leaves as some mystery why the function was not back-fitted to any service pack of Windows XP.