page 1 of 1
Comments: 2 | Views: 4264
#Dec 19th, 2005 @ 5:51 PM
gaelhatchue
gaelhatchue

Here is the scenario:

<BR>HANDLE hHandle1 = CreateThread(...);<BR>


now, at some point in the program, you want to know if the current thread is the same as the thread pointed to by hHandle1.

So, you do
<BR>HANDLE hHandle2;<BR>DuplicateHandle(GetCurrentProcess(), GetCurrentThread(), GetCurrentProcess(), &hHandle2, 0, FALSE, DUPLICATE_SAME_ACCESS);<BR>


The problem is that you end up having two different handles that might refer to the same thread.

Is there a way to determine if they both do refer to the same thread?

I tried getting the thread Ids from both handles and compare them. But they are different, event when I know the two handles refer to the same thread.

Is there a user mode function similar to the kernel mode function ObReferenceObjectByHandle(); This KM function returns the same pointer for both handles.

#Dec 19th, 2005 @ 8:51 PM
gaelhatchue
gaelhatchue

Nevermind. I use the thread IDs to uniquely identify each thread. It still wound be nice to know how to determine if two handles refer to the same object.

#Dec 20th, 2005 @ 8:09 AM
ScanIAm
ScanIAm
On a scale of 1 to 10, people are stupid.

Depends on how much control you have over the object itself.  I was faced with this recently in a system where I could not use .net (and therefor couldn't get the hash code) because the handle referred to an object behind the p/Invoke boundary.  We settled on a function that would take the two handles, set a member variable in the object pointed to by one of the handles and then read it from the other.  If they matched, the objects were the same. 

The value we set was a newly created guid, so there was little chance of duplication.

page 1 of 1
Comments: 2 | Views: 4264
Microsoft Communities