Correct CM IRQL documentation

[jxy-s]

It looks like the ability to report problems has been removed from the this repository. So I'm creating a pull request to highlight either a problem in the documentation or an error in programming the Windows Kernel. I'm not sure which one is correct. I would like someone from Microsoft to confirm if the documentation (and WDK SAL) needs to be updated.

Please reference this issue: winsiderss/systeminformer#2498 (comment)

It appears that there are paths implemented in the Windows Kernel which can cause registry APIs to be invoked at APC_LEVEL. If this is now blessed by Microsoft then the documentation should be updated for:

1. The callback registered by CmRegisterCallback/CmRegisterCallbackEx.
2. The associated registry APIs (e.g ZwOpenKeyEx) should have their documentation updated.
3. The SAL in the WDK for the related registry APIs should be updated, they currently decorate with _IRQL_requires_max_(PASSIVE_LEVEL):

#if (NTDDI_VERSION >= NTDDI_WIN2K)
//@[comment("MVI_tracked")]
_IRQL_requires_max_(PASSIVE_LEVEL)
NTSYSAPI
NTSTATUS
NTAPI
ZwOpenKey(
    _Out_ PHANDLE KeyHandle,
    _In_ ACCESS_MASK DesiredAccess,
    _In_ POBJECT_ATTRIBUTES ObjectAttributes
    );
#endif

#if (NTDDI_VERSION >= NTDDI_WIN7)
_IRQL_requires_max_(PASSIVE_LEVEL)
NTSYSAPI
NTSTATUS
NTAPI
ZwOpenKeyEx(
    _Out_ PHANDLE KeyHandle,
    _In_ ACCESS_MASK DesiredAccess,
    _In_ POBJECT_ATTRIBUTES ObjectAttributes,
    _In_ ULONG OpenOptions
    );
#endif

Note that this commit does not go through and update all the documentation that might be necessary. I'm happy to continue this work to update all the documentation to be <= APC_LEVEL (where relevant). But before doing all that work I would like confirmation from Microsoft where (and if) this should be updated in the documentation.

[jxy-s]

I'm discovering other inconsistencies with the documentation. Specifically around thread creation. It is documented that the thread notify routine can be invoked at APC_LEVEL. In my case when a volume is mounted:

 # Call Site
00 SystemInformer!KphpCreateThreadNotifyRoutine
01 nt!PspCallThreadNotifyRoutines
02 nt!PspInsertThread
03 nt!PspCreateThread
04 nt!PsCreateSystemThreadEx
05 nt!PsCreateSystemThread
06 nt!CcInitializePrivateVolumeCacheMap
07 nt!CcCreatePrivateVolumeCacheMap
08 nt!CcInitializeCacheMapInternal
09 nt!CcInitializeCacheMap
0a cdfs!CdCreateInternalStream
0b cdfs!CdUpdateVcbFromVolDescriptor
0c cdfs!CdMountVolume
0d cdfs!CdCommonFsControl
0e cdfs!CdFsdDispatch
0f nt!IofCallDriver
10 FLTMGR!FltpFsControlMountVolume
11 FLTMGR!FltpFsControl
12 nt!IofCallDriver
13 nt!IopMountVolume
14 nt!IopCheckVpbMounted
15 nt!IopParseDevice
16 nt!ObpLookupObjectName
17 nt!ObOpenObjectByNameEx
18 nt!IopCreateFile
19 nt!NtCreateFile
1a nt!KiSystemServiceCopyEnd

This is fine. However, there are additional downstream documentation updates that should be done.

1. PsCreateSystemThread should probably be updated to reflect that is is fine to call at APC_LEVEL?
2. Since the operating system will then create handles, any registered object callbacks will be invoked so POB_PRE_OPERATION_CALLBACK and POB_POST_OPERATION_CALLBACK should probably also be updated to reflect that it could be invoked at APC_LEVEL?