ThreadId to HANDLE for 64 bit?

NTFSD
1

So GetCurrentThreadId returns a DWORD, which I send up to the kernel in
a message. PsLookupThreadByThreadId takes the thread Id in a HANDLE,
which is a different size than a DWORD on 64 bit platforms. Is it safe
to just cast it? Or do I need to do something different?

~Eric

2

Gah, let me re-ask that:

I can’t just cast it, I’m getting a C4312 ‘type cast’ : conversion from
‘DWORD’ to ‘HANDLE’ of greater size. Is doing the following an
acceptable way around this, or is there another wrinkle to it that’ll
bite me at runtime?

UINT_PTR gross;
HANDLE tid_handle;
// contains a DWORD tid
MESSAGE msg;

gross = (UINT_PTR) msg->tid;
tid_handle = (HANDLE) gross;

~Eric

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Eric Diven
Sent: Friday, August 08, 2008 1:57 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] ThreadId to HANDLE for 64 bit?

So GetCurrentThreadId returns a DWORD, which I send up to the kernel in
a message. PsLookupThreadByThreadId takes the thread Id in a HANDLE,
which is a different size than a DWORD on 64 bit platforms. Is it safe
to just cast it? Or do I need to do something different?

~Eric

NTFSD is sponsored by OSR

For our schedule debugging and file system seminars (including our new
fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

This is a known Windows API bug (“known” in that I talked to the
relevant filter manager DEV about this, as it shows up in Filter Manager
as well because of the I/O Manager API issue.)

As long as you don’t have more than a half billion or so threads and
processes (they use a single shared handle table) you’ll be fine. Maybe
by the time that’s a real issue, we’ll be running something different.

Tony
OSR

4

There is a standard HandleToUlong macro to do this without the warnings.

Given that the decision was made not to update pids in Win32 with the move to 64-bit, I think that it is going to be unlikely that there will be a move for pids over 32 bits.

However, I have never seen anything official from Microsoft stating that - though I once again think that they have backed themselves into a corner with keeping pids/tids 32bit in the Win32 layer.


Not to be hijacking your thread completely, but I wonder what Microsoft is going to do about MAXIMUM_PROCESSORS being only 64 (bits in an affinity mask), in the day and age when anyone can get an 8-proc box for under $2k usd. Not long now till 64 procs is not inordinately expensive, methinks.

  • S

-----Original Message-----
From: Eric Diven
Sent: Friday, August 08, 2008 13:04
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] ThreadId to HANDLE for 64 bit?

Gah, let me re-ask that:

I can’t just cast it, I’m getting a C4312 ‘type cast’ : conversion from
‘DWORD’ to ‘HANDLE’ of greater size. Is doing the following an
acceptable way around this, or is there another wrinkle to it that’ll
bite me at runtime?

UINT_PTR gross;
HANDLE tid_handle;
// contains a DWORD tid
MESSAGE msg;

gross = (UINT_PTR) msg->tid;
tid_handle = (HANDLE) gross;

~Eric

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Eric Diven
Sent: Friday, August 08, 2008 1:57 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] ThreadId to HANDLE for 64 bit?

So GetCurrentThreadId returns a DWORD, which I send up to the kernel in
a message. PsLookupThreadByThreadId takes the thread Id in a HANDLE,
which is a different size than a DWORD on 64 bit platforms. Is it safe
to just cast it? Or do I need to do something different?

~Eric

—
NTFSD is sponsored by OSR

For our schedule debugging and file system seminars (including our new
fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

5

Thanks for the help on this one guys, it now builds both ways.

There is a standard HandleToUlong macro to do this without the
warnings.

I had missed that one, but that goes the wrong way sadly. I need to
turn my ULONG32 into a HANDLE. It doesn’t look like there’s a function
to do that though. At least not that I’ve found on the MSDN. Though I
did turn up this gem:

http://msdn.microsoft.com/en-us/library/aa489638.aspx

DWORD32 and DWORD64. Are you serious? Thank goodness we’re still
fixated on the word size of a 16 bit processor, that way we can have
types with completely misleading names. Who would have imagined that
making typedefs based on the word size of the processor could possibly
cause problems down the road? (Okay, I’ll admit this is at least as
much C’s fault as it is MSFT’s for not having a standard way to declare
an x-bit integer for so long)

As long as you don’t have more than a half billion or so threads and
processes (they use a single shared handle table) you’ll be fine.

You’ve had this problem when you’ve tried to start 2^30 processes too?
:wink:

Maybe by the time that’s a real issue, we’ll be running something
different.

Isn’t that how we ended up having the Y2K problem a couple years ago?
(And I’ll admit once again that it’s going to be how we’ll end up having
a Y2K37 problem in just 29 short years).

~Eric

6

Whoops, sorry. There’s also a UlongToHandle macro as well.

BTW - For reference though, even on Windows Server 2008 x64, handle tables are still limited to 2^24 entries in the current implementation, so the actual limit conks out at a lot less than half a billion. (Wrote an experiment to test this awhile ago, in an attempt to see what would break with absurdly high numbers of handle / pointer references.) Of course, future implementations are not constrained to 2^24. Win32, as mentioned, continues to constrain itself to a 32-bit view of PID/TID values, even though the kernel views them as pointer-sized quantities.

  • S

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Eric Diven
Sent: Friday, August 08, 2008 3:10 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] ThreadId to HANDLE for 64 bit?

Thanks for the help on this one guys, it now builds both ways.

There is a standard HandleToUlong macro to do this without the
warnings.

I had missed that one, but that goes the wrong way sadly. I need to
turn my ULONG32 into a HANDLE. It doesn’t look like there’s a function
to do that though. At least not that I’ve found on the MSDN. Though I
did turn up this gem:

http://msdn.microsoft.com/en-us/library/aa489638.aspx

DWORD32 and DWORD64. Are you serious? Thank goodness we’re still
fixated on the word size of a 16 bit processor, that way we can have
types with completely misleading names. Who would have imagined that
making typedefs based on the word size of the processor could possibly
cause problems down the road? (Okay, I’ll admit this is at least as
much C’s fault as it is MSFT’s for not having a standard way to declare
an x-bit integer for so long)

As long as you don’t have more than a half billion or so threads and
processes (they use a single shared handle table) you’ll be fine.

You’ve had this problem when you’ve tried to start 2^30 processes too?
:wink:

Maybe by the time that’s a real issue, we’ll be running something
different.

Isn’t that how we ended up having the Y2K problem a couple years ago?
(And I’ll admit once again that it’s going to be how we’ll end up having
a Y2K37 problem in just 29 short years).

~Eric

NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

7

Actually the kernel has issued here as well. For example, see
PO_TRANSITION_VETO or the one I was talking about:

NTKERNELAPI
ULONG
IoGetRequestorProcessId(
__in PIRP Irp
);

And the resulting gaff in the filter manager:

ULONG
FLTAPI
FltGetRequestorProcessId (
__in PFLT_CALLBACK_DATA CallbackData
);

These APIs are broken and will need to be fixed before the kernel can
use process IDs properly (as HANDLE values rather than ULONG values.)

Tony
OSR

8

Thanks - didnt know about HandleToUlong/UlongToHandle - have been doing
handleThing = (HANDLE)(ULONG_PTR)(ulongThing);

The sidetrack very good, quite agreed. I have the feeling the kit might well
be available in the windows nt vX>=7 era …

“Skywing” wrote in message news:xxxxx@ntfsd…
There is a standard HandleToUlong macro to do this without the warnings.

Given that the decision was made not to update pids in Win32 with the move
to 64-bit, I think that it is going to be unlikely that there will be a move
for pids over 32 bits.

However, I have never seen anything official from Microsoft stating that -
though I once again think that they have backed themselves into a corner
with keeping pids/tids 32bit in the Win32 layer.


Not to be hijacking your thread completely, but I wonder what Microsoft is
going to do about MAXIMUM_PROCESSORS being only 64 (bits in an affinity
mask), in the day and age when anyone can get an 8-proc box for under $2k
usd. Not long now till 64 procs is not inordinately expensive, methinks.


- S

-----Original Message-----
From: Eric Diven
Sent: Friday, August 08, 2008 13:04
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] ThreadId to HANDLE for 64 bit?

Gah, let me re-ask that:

I can’t just cast it, I’m getting a C4312 ‘type cast’ : conversion from
‘DWORD’ to ‘HANDLE’ of greater size. Is doing the following an
acceptable way around this, or is there another wrinkle to it that’ll
bite me at runtime?

UINT_PTR gross;
HANDLE tid_handle;
// contains a DWORD tid
MESSAGE msg;

gross = (UINT_PTR) msg->tid;
tid_handle = (HANDLE) gross;

~Eric

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Eric Diven
Sent: Friday, August 08, 2008 1:57 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] ThreadId to HANDLE for 64 bit?

So GetCurrentThreadId returns a DWORD, which I send up to the kernel in
a message. PsLookupThreadByThreadId takes the thread Id in a HANDLE,
which is a different size than a DWORD on 64 bit platforms. Is it safe
to just cast it? Or do I need to do something different?

~Eric

—
NTFSD is sponsored by OSR

For our schedule debugging and file system seminars (including our new
fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com