It is clear that, if this function needs to be again called with PreviousMode == KernelMode, such a handle conversion must be performed. And... the file handle must be converted anyways to kernel m...

It is clear that, if this function needs to be again called with PreviousMode == KernelMode, such a handle conversion must be performed.
And... the file handle must be converted anyways to kernel mode handle, because it is used as a hive file handle internally by the Cm function(s).
So this code (that is currently #if'ed 0 out) will have to be enabled (later, in v2 of this patch).

See the same comment in the other function.

See the same comment in the other function.

For NtSaveKeyEx and NtSaveMergedKeys, both of these functions call CmpInitializeHive, HvWriteHive, etc... and it looks to me they possibly want to run with PreviousMode == KernelMode. I would like ...

For NtSaveKeyEx and NtSaveMergedKeys, both of these functions call CmpInitializeHive, HvWriteHive, etc... and it looks to me they possibly want to run with PreviousMode == KernelMode.
I would like to hear you about that

For NtSaveKeyEx and NtSaveMergedKeys, both of these functions call CmpInitializeHive, HvWriteHive, etc... and it looks to me they possibly want to run with PreviousMode == KernelMode. I would like ...

For NtSaveKeyEx and NtSaveMergedKeys, both of these functions call CmpInitializeHive, HvWriteHive, etc... and it looks to me they possibly want to run with PreviousMode == KernelMode.
I would like to hear you about that

These probe & capture functions were strongly inspired from the Obp* functions I mention below. If you think they can be useful elsewhere than in this module, please suggest me where-else to place ...

These probe & capture functions were strongly inspired from the Obp* functions I mention below.
If you think they can be useful elsewhere than in this module, please suggest me where-else to place them.

I hate this word: https://en.wikipedia.org/wiki/Quickie ; https://en.wiktionary.org/wiki/quickie
Was renamed to keep it "in sync" with the equivalents in NtLoadKeyEx.

Was renamed to keep it "in sync" with the equivalents in NtLoadKeyEx.

A DPRINT is better than an ASSERT(FALSE); in the kernel, especially when the unimplemented stuff is not vital for the rest of the code to run (we would just gracefully return an error status code)....

A DPRINT is better than an ASSERT(FALSE); in the kernel, especially when the unimplemented stuff is not vital for the rest of the code to run (we would just gracefully return an error status code).
I use SEH here because the object name (buffer) comes potentially from user-mode.

Let me guys now what you think about that.

Let me guys now what you think about that.

Flag added because, the RootDirectory is now a kernel handle, and CmLoadKey will call ObOpenObjectByName with accessmode == KernelMode (indeed, most, if not all Cm functions expect to be called wit...

Flag added because, the RootDirectory is now a kernel handle, and CmLoadKey will call ObOpenObjectByName with accessmode == KernelMode (indeed, most, if not all Cm functions expect to be called with kernel mode parameters).

Forget about this one https://code.reactos.org/static/olpro3/2static/images/wiki/icons/emoticons/smile.gif

Forget about this one

What do you think about the necessity of probing here? Is capturing needed too?

What do you think about the necessity of probing here? Is capturing needed too?

The post callback should be done inconditionally, similar to what is done elsewhere in this file.

The post callback should be done inconditionally, similar to what is done elsewhere in this file.

What you guys actually think about the necessity of that?

What you guys actually think about the necessity of that?

This one was missing (and for NtEnumerateKeyValues, I should add the **Align64 checks too).

This one was missing (and for NtEnumerateKeyValues, I should add the **Align64 checks too).

This is adapted from a private patch from Thomas Faber. I added the 'ObjectType' parameter, because so far I use it for both registry keys and file (IO) objects (aka as the replacement for IoConver...

This is adapted from a private patch from Thomas Faber.
I added the 'ObjectType' parameter, because so far I use it for both registry keys and file (IO) objects (aka as the replacement for IoConvertFileHandleToKernelHandle).

Improve parameters probing in Cm' NT apis
Improve parameters probing in Cm' NT apis
  • More
  • CR-117
  • finished reviewing
Double semicolon.

Double semicolon.

NTSTATUS foobar(void)

NTSTATUS foobar(void)

Comment tends to go out of screen (code formatting).

Comment tends to go out of screen (code formatting).

can even be "static const" (as well as the slashes below).

can even be "static const" (as well as the slashes below).

Isn't that a "ULONG_PTR" type that you should use instead (for the thunk structure member and for the cast) (it has the same size as a native pointer on the platform) ?? This would simplify these l...

Isn't that a "ULONG_PTR" type that you should use instead (for the thunk structure member and for the cast) (it has the same size as a native pointer on the platform) ?? This would simplify these lines of code into just a single:

FirstThunk->u1.Function = (ULONG_PTR)HoopApi->ReplacementFunction;
You may move both these variables outside the for-loop, so that the second loop can reuse them instead of redeclaring them.

You may move both these variables outside the for-loop, so that the second loop can reuse them instead of redeclaring them.

You may be able to use: static ANSI_STRING GetHookAPIs = RTL_CONSTANT_STRING("GetHookAPIs"); etc... and / or possibly make them global in the file (unless they are only used inside this function).

You may be able to use:

static ANSI_STRING GetHookAPIs = RTL_CONSTANT_STRING("GetHookAPIs");
etc...

and / or possibly make them global in the file (unless they are only used inside this function).

It then may be possible that Reason is _Inout_opt_.

It then may be possible that Reason is _Inout_opt_.

Ah, I meant: typedef BOOL (WINAPI *tWhatever)( IN TYPE Param1, IN TYPE Param2, etc... OUT PTYPE Stuff); or something like that.

Ah, I meant:

typedef BOOL (WINAPI *tWhatever)(
    IN TYPE Param1,
    IN TYPE Param2,
etc...
    OUT PTYPE Stuff);

or something like that.

Are the left-casts really needed?

Are the left-casts really needed?

I am quite surprised that the CPP can be included amongst the list of C files without any other complications in the CMakeLists file, and that will compile it OK (I remember that for other code whe...

I am quite surprised that the CPP can be included amongst the list of C files without any other complications in the CMakeLists file, and that will compile it OK (I remember that for other code where C and CPP files are mixed together, the cmakelists has to be explicitely set with C++ commands & the C & C++ files to be separately listed and compiled in a certain manner...