Inconsistence in API between kernel mode and user mode for 64-bit Windows.

NTDEV
1

Hi all,

For 64-bit Windows kernel mode driver HANDLE data type became 64 bit and the
data type used to store Process ID values, while user mode APIs like
OpenProcess still have formal definition like:
HANDLE WINAPI OpenProcess(
DWORD dwDesiredAccess,
BOOL bInheritHandle,
DWORD dwProcessId
);

With Process ID represented by DWORD value. The situation also raise
questions - if my driver have HANDLE Process ID to pass for further
processing
to user mode component that uses OpenProcess - how I can avoid potential
data loss case here? What are best practice recommendations for such case
right now?

Thanks,
Alex.

2

Alex,

Depends on your compile environment. For 64-bit user mode code the
HANDLE becomes a native 64-bit value, so there’s no problem.

As for 32-bit user mode code interacting with 64-bit drivers, you
should read this,
http://www.microsoft.com/whdc/driver/kernel/64bit_chklist.mspx.

I did the relevant work in a driver a couple of weeks ago and it was
surprisingly painless, even in quite a complex case where the driver
returns an array of structures with several handles and void pointers
used as identifiers. Though I must admit, that the documentation
only describes passing pointers in from user mode to kernel mode. I
need to pass some void pointers back up to user mode so that they can
be used as identifiers in subsequent calls. This requires a bit of
an ugly hack, but it works fine.

In less than a day my driver worked seamlessly with being called by
either 32-bit or 64-bit user mode code.

Follow the above guidelines and you should have few problems.

Mark.

At 06:41 AM 3/22/2007, Alex Korthny wrote:

Hi all,

For 64-bit Windows kernel mode driver HANDLE data type became 64 bit and the
data type used to store Process ID values, while user mode APIs like
OpenProcess still have formal definition like:
HANDLE WINAPI OpenProcess(
DWORD dwDesiredAccess,
BOOL bInheritHandle,
DWORD dwProcessId
);

With Process ID represented by DWORD value. The situation also raise
questions - if my driver have HANDLE Process ID to pass for further
processing
to user mode component that uses OpenProcess - how I can avoid potential
data loss case here? What are best practice recommendations for such case
right now?

Thanks,
Alex.

3

Hello Mark,

Thank you for the response.
I don’t have problem with porting to 64 bit, the task already done.
The problem related to inconsistency - PID discovered by driver will be
stored in 64 bit variable. If I’ll want to use the PID in user mode
application, I’ll need to “shrink” it to 32 bit variable for OpenProcess,
potentially losing data.
Can someone give me warranty that on 64 bit server that running without
reboot for months PID will never reach value that exceed 32 bit value limit?

Thanks,
Alex.

“Mark S. Edwards” wrote in message news:xxxxx@ntdev…
> Alex,
>
> Depends on your compile environment. For 64-bit user mode code the
> HANDLE becomes a native 64-bit value, so there’s no problem.
>
> As for 32-bit user mode code interacting with 64-bit drivers, you
> should read this,
> http://www.microsoft.com/whdc/driver/kernel/64bit_chklist.mspx.
>
> I did the relevant work in a driver a couple of weeks ago and it was
> surprisingly painless, even in quite a complex case where the driver
> returns an array of structures with several handles and void pointers
> used as identifiers. Though I must admit, that the documentation
> only describes passing pointers in from user mode to kernel mode. I
> need to pass some void pointers back up to user mode so that they can
> be used as identifiers in subsequent calls. This requires a bit of
> an ugly hack, but it works fine.
>
> In less than a day my driver worked seamlessly with being called by
> either 32-bit or 64-bit user mode code.
>
> Follow the above guidelines and you should have few problems.
>
> Mark.
>
>
>
> At 06:41 AM 3/22/2007, Alex Korthny wrote:
>>Hi all,
>>
>>For 64-bit Windows kernel mode driver HANDLE data type became 64 bit and
>>the
>>data type used to store Process ID values, while user mode APIs like
>>OpenProcess still have formal definition like:
>>HANDLE WINAPI OpenProcess(
>> DWORD dwDesiredAccess,
>> BOOL bInheritHandle,
>> DWORD dwProcessId
>>);
>>
>>With Process ID represented by DWORD value. The situation also raise
>>questions - if my driver have HANDLE Process ID to pass for further
>>processing
>>to user mode component that uses OpenProcess - how I can avoid potential
>>data loss case here? What are best practice recommendations for such case
>>right now?
>>
>>Thanks,
>>Alex.
>

4

I heard that all 64 bit handles guarantee the top 32 bits are clear so they
can be passed back and forth through 32-bit interfaces - but I have not
verified this…

Can an expert corroborate?

Mike

----- Original Message -----
From: Mark S. Edwards
To: Windows System Software Devs Interest List
Sent: Thursday, March 22, 2007 9:30 AM
Subject: Re: [ntdev] Inconsistence in API between kernel mode and user mode
for 64-bit Windows.

Alex,

Depends on your compile environment. For 64-bit user mode code the
HANDLE becomes a native 64-bit value, so there’s no problem.

As for 32-bit user mode code interacting with 64-bit drivers, you
should read this,
http://www.microsoft.com/whdc/driver/kernel/64bit_chklist.mspx.

I did the relevant work in a driver a couple of weeks ago and it was
surprisingly painless, even in quite a complex case where the driver
returns an array of structures with several handles and void pointers
used as identifiers. Though I must admit, that the documentation
only describes passing pointers in from user mode to kernel mode. I
need to pass some void pointers back up to user mode so that they can
be used as identifiers in subsequent calls. This requires a bit of
an ugly hack, but it works fine.

In less than a day my driver worked seamlessly with being called by
either 32-bit or 64-bit user mode code.

Follow the above guidelines and you should have few problems.

Mark.

At 06:41 AM 3/22/2007, Alex Korthny wrote:

Hi all,

For 64-bit Windows kernel mode driver HANDLE data type became 64 bit and
the
data type used to store Process ID values, while user mode APIs like
OpenProcess still have formal definition like:
HANDLE WINAPI OpenProcess(
DWORD dwDesiredAccess,
BOOL bInheritHandle,
DWORD dwProcessId
);

With Process ID represented by DWORD value. The situation also raise
questions - if my driver have HANDLE Process ID to pass for further
processing
to user mode component that uses OpenProcess - how I can avoid potential
data loss case here? What are best practice recommendations for such case
right now?

Thanks,
Alex.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

5

Yes that is a mess isn’t it? I ended up compromising on using 64bit
values in my driver for both 32 and 64 bit modes, casting as required,
and giving user mode the 64 bit values to deal, also casting as
required. So far it seems that pids are within 32 bit ranges. My 32 bit
apis up in user mode appear to find all processes using 32 bit values.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Alex Korthny
Sent: Thursday, March 22, 2007 2:41 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Inconsistence in API between kernel mode and user mode
for 64-bit Windows.

Hi all,

For 64-bit Windows kernel mode driver HANDLE data type became 64 bit and
the
data type used to store Process ID values, while user mode APIs like
OpenProcess still have formal definition like:
HANDLE WINAPI OpenProcess(
DWORD dwDesiredAccess,
BOOL bInheritHandle,
DWORD dwProcessId
);

With Process ID represented by DWORD value. The situation also raise
questions - if my driver have HANDLE Process ID to pass for further
processing
to user mode component that uses OpenProcess - how I can avoid potential

data loss case here? What are best practice recommendations for such
case
right now?

Thanks,
Alex.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer