Does ObOpenObjectByPointer() in the case Wow64 returns HANDLE 32-bit?

NTDEV
1

I asked to move compilation of one old written driver from VS2012 to the VS2017 and run into the problem which VS2010 “eat”, but VS2017 generates
warning C4311: ‘type cast’: pointer truncation from ‘HANDLE’ to ‘ULONG’

I analyzed the code and found that
API ObOpenObjectByPointer() returns last parameter as HANDLE, which driver for case Wow64 (IoIs32bitProcess(Irp) returns TRUE) tries to save as ULONG (32 bit) which generates warning above.

MSDN [https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/nf-ntifs-obopenobjectbypointer] keeps silence about the case Wow64.
Does HANDLE for case Wow64 has real size 32-bit or this is bug?

Regards,
Michael Grabelkovsky.

2

Everything compiled in kernel mode is going to have HANDLE defined as a 64-bit type. So, the warning is correct and you need to pass a PHANDLE as the argument.

However, when you’re creating a HANDLE for a Wow64 process you’re guaranteed that the resulting HANDLE will only have the low 32-bits valid. So, after the call is successful you can cast the result to an ULONG to return it to a 32-bit process.

3

Scott,
Thanks a lot, detail answer!
I supposed something same.

As I understand you described common principle of mapping handles for 32 bit Appl inside 64-bit environment.
And it may be used for other same cases too, even if Documentation keeps silent…

Regards,
MG.

4

For completeness it also applies to user mode virtual address mappings. For example, calling MmMapLockedPagesSpecifyCache with an AccessMode of UserMode will return a 64-bit virtual address with only the low 32-bits valid.