Question on DDMapMemory

NTDEV
1

Hi,
I am developing a DirectDraw driver for a new dispalyHW, in Windows XP.
When debugging the DDMapMemory, i am coming across a strange behavior.
The hProcess parameter in the DD_MAPMEMORYDATA is 0xFFFFFFFF, which looks to be an invalid handle. DDK documentation says that this is the Handle to the process whose address space is affected. In that case why a value of 0xFFFFFFFF is passed by the OS? Does this value has any specific meaning in this scenario?, or can be ingored?

thanks
Praveen

Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

2

I don’t know anything about video drivers, a handle of 0xFFFFFFFF (read
-1) is used in lots of situations to mean the handle of the current
process. Whether that is what is going on here or not, I don’t know.

Good luck,

mm

prvn ns wrote:

Hi,
I am developing a DirectDraw driver for a new dispalyHW, in Windows XP.
When debugging the DDMapMemory, i am coming across a strange behavior.
The hProcess parameter in the DD_MAPMEMORYDATA is 0xFFFFFFFF, which
looks to be an invalid handle. DDK documentation says that this is the
Handle to the process whose address space is affected. In that case why
a value of 0xFFFFFFFF is passed by the OS? Does this value has any
specific meaning in this scenario?, or can be ingored?

thanks
Praveen

Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

3

>the process whose address space is affected. In that case why a value of

0xFFFFFFFF is passed by the OS?

This is NtCurrentProcess()

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

4

I’ve used this function extensively. Typically, the ~0 handle works just fine, but you can sometimes encounter situations where it doesn’t work. The one situation I found was when you store the handle of the current process into some kind of table, and then map that memory later in the context of some other process. When you use NtCurrentProcess (which is a macro, not a function), you will end up with some mess because all of your cached mapping operations will be executed in the same process space instead of the process spaces you wanted.

As far as I know, there are no APIs you can call to get the *actual* process handle (EngGetProcessHandle always returns null) and the function you just mentioned will typically have ~0 as the process handle unless the memory is being mapped out-of-process.

Unless you’re doing something crazy like this, though, then the ~0 value is safe to pass into most any function that expects a handle of that sort.

5

In UserMode a real handle is obtained through duplication. I would try this here, too:

ZwDuplicateObject(
__in HANDLE SourceProcessHandle,
__in HANDLE SourceHandle,
__in_opt HANDLE TargetProcessHandle,
__out_opt PHANDLE TargetHandle,
__in ACCESS_MASK DesiredAccess,
__in ULONG HandleAttributes,
__in ULONG Options
);

This function is declared in “ntifs.h” and has beed present since win2k (at least).
Unfortunately, Microsoft states that “this function is reserved for system use” and don’t document it.
A documented way would be to call
PEPROCESS pProcess;
ObReferenceObjectByHandle(hProcess, PROCESS_ALL_ACCESS, PsProcessType, KernelMode, &pProcess, NULL);
This must be done at PASSIVE_LEVEL.

Then, at IRQL<=APC_LEVEL you can call ObOpenObjectByPointer to get handle to the object.

This is a general method which I have NOT tested with pseudohandles, so I don’t know if it would work here.
This method has been undocumented until half a year ago, so probably ZwDuplicateObject will become documented soon, but no-one can be sure.