What is Owner field in a Fast Mutex

NTDEV
1

Under XP,
which is the meaning of the Owner field in a fast mutex ?
I thought, by looking at the structure, it was the owner PKTHREAD but it is not. It looks like a stack pointer.

Does it have any purpose under XP ?

Inaki.

2

You shouldn’t be relying on the contents of a PFAST_MUTEX. Let the OS do
the work and use the documented functions for working with the object.

–
Ken Johnson (Skywing)
Windows SDK MVP
http://www.nynaeve.net
“Iñaki Castillo” wrote in message
news:xxxxx@ntdev…
Under XP,
which is the meaning of the Owner field in a fast mutex ?
I thought, by looking at the structure, it was the owner PKTHREAD but it is
not. It looks like a stack pointer.

Does it have any purpose under XP ?

Inaki.

3

Hmmmm… Are you sure you’re looking at the OWNER field? For which architecture?

This should indeed be a pointer to the owning KTHREAD, at least as far as I know.

Peter
OSR

(Ken… This type of info can be very helpful during debugging, as you !DT the various objects)

4

Peter,
please, take a look at the following code, disassembled in a Windows XP+SP2 over Intel Xeon. It is identical to a Windows 2000+SP4 over P4.
Note the line at the end of the code: MOV [ECX+4], ESP

@ExAcquireFastMutex (ECX=&FastMutex)

0008:80A2C940 MOV EAX,[FFFE0080] ; Reads APIC TPR
0008:80A2C945 MOV DWORD PTR [FFFE0080],0000003D; Sets it to APC
0008:80A2C94F LOCK DEC DWORD PTR [ECX] ; FastMutex->Count
0008:80A2C952 JZ 80A2C96D
0008:80A2C954 INC DWORD PTR [ECX+08] ; FastMutex->Contention
0008:80A2C957 PUSH ECX
0008:80A2C958 PUSH EAX
0008:80A2C959 ADD ECX,0C ; FastMutex->Event
0008:80A2C95C PUSH 00
0008:80A2C95E PUSH 00
0008:80A2C960 PUSH 00
0008:80A2C962 PUSH 00
0008:80A2C964 PUSH ECX
0008:80A2C965 CALL KeWaitForSingleObject
0008:80A2C96B POP EAX ; Old APIC TPR
0008:80A2C96C POP ECX
0008:80A2C96D MOV [ECX+1C],AL ; FastMutex->OldIrql
0008:80A2C970 MOV [ECX+04],ESP ; FastMutex->OWNER
0008:80A2C973 RET

-----Mensaje original-----
De: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]En nombre de xxxxx@osr.com
Enviado el: mi?rcoles, 25 de julio de 2007 20:50
Para: Windows System Software Devs Interest List
Asunto: RE:[ntdev] What is Owner field in a Fast Mutex

Hmmmm… Are you sure you’re looking at the OWNER field? For which architecture?

This should indeed be a pointer to the owning KTHREAD, at least as far as I know.

Peter
OSR

(Ken… This type of info can be very helpful during debugging, as you !DT the various objects)

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

5

I kinda remembered in the back of my head that that was right, so when I saw
Peter’s message, I too looked at this, but on Server 2003. On Server 2003,
it does indeed use the KTHREAD address.

But it doesn’t really matter, since it’s for debugging purposes. You can do
a !thread on a stack address, and it will show you the thread that the stack
belongs to.

  • Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Iñaki Castillo
Sent: Thursday, July 26, 2007 4:03 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] What is Owner field in a Fast Mutex

Peter,
please, take a look at the following code, disassembled in a Windows XP+SP2
over Intel Xeon. It is identical to a Windows 2000+SP4 over P4. Note the
line at the end of the code: MOV [ECX+4], ESP

@ExAcquireFastMutex (ECX=&FastMutex)

0008:80A2C940 MOV EAX,[FFFE0080] ; Reads APIC TPR
0008:80A2C945 MOV DWORD PTR [FFFE0080],0000003D; Sets it to APC
0008:80A2C94F LOCK DEC DWORD PTR [ECX] ;
FastMutex->Count
0008:80A2C952 JZ 80A2C96D
0008:80A2C954 INC DWORD PTR [ECX+08] ;
FastMutex->Contention
0008:80A2C957 PUSH ECX
0008:80A2C958 PUSH EAX
0008:80A2C959 ADD ECX,0C ; FastMutex->Event
0008:80A2C95C PUSH 00
0008:80A2C95E PUSH 00
0008:80A2C960 PUSH 00
0008:80A2C962 PUSH 00
0008:80A2C964 PUSH ECX
0008:80A2C965 CALL KeWaitForSingleObject
0008:80A2C96B POP EAX ; Old APIC
TPR
0008:80A2C96C POP ECX
0008:80A2C96D MOV [ECX+1C],AL ; FastMutex->OldIrql
0008:80A2C970 MOV [ECX+04],ESP ; FastMutex->OWNER
0008:80A2C973 RET

-----Mensaje original-----
De: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]En nombre de xxxxx@osr.com
Enviado el: miércoles, 25 de julio de 2007 20:50
Para: Windows System Software Devs Interest List
Asunto: RE:[ntdev] What is Owner field in a Fast Mutex

Hmmmm… Are you sure you’re looking at the OWNER field? For which
architecture?

This should indeed be a pointer to the owning KTHREAD, at least as far as I
know.

Peter
OSR

(Ken… This type of info can be very helpful during debugging, as you !DT
the various objects)

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

6

Ah, OK… quite right, Iñaki.

This intrigued me enough to get me to go look it up. It seems that on some OS revs, the implementation of fast mutex depends on:

a) The processor architecture
b) The HAL being used
c) The OS build (free or checked)

It seems that in some versions, in some HALs, on the free build, that they do indeed set the owner field to the stack pointer (as clearly demonstrated by your disassembly). This is apparently for debugging purposes – not only can you figure out the thread using !thread as Dan noted, but you can see where the mutex was acquired (I guess).

Nice pickup… And another example of why we shouldn’t rely on undocumented fields in data structures, I guess. Just when you think you can use your internals knowledge to debug a problem, you discover somebody’s gone off and changed the code… Which is their perfect right, of course.

Keeps us all on our toes, doesn’t it,

Peter
OSR

7

Usually, FAST_MUTEX is like this:

ExAcquireFastMutex(Fm)
{
if( InterlockedIncrement(&(Fm->Count)) == 0 ) return;
KeWaitForSingleObject(&(Fm->Event)…);
}

ExReleaseFastMutex(Fm)
{
if( InterlockedDecrement(&(Fm->Count)) < 0 ) return;
KeSetEvent(&(Fm->Event)…);
}

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

wrote in message news:xxxxx@ntdev…



Ah, OK… quite right, Iñaki.

This intrigued me enough to get me to go look it up. It seems that on some OS
revs, the implementation of fast mutex depends on:

a) The processor architecture
b) The HAL being used
c) The OS build (free or checked)

It seems that in some versions, in some HALs, on the free build, that they do
indeed set the owner field to the stack pointer (as clearly demonstrated by
your disassembly). This is apparently for debugging purposes – not only can
you figure out the thread using !thread as Dan noted, but you can see where the
mutex was acquired (I guess).

Nice pickup… And another example of why we shouldn’t rely on undocumented
fields in data structures, I guess. Just when you think you can use your
internals knowledge to debug a problem, you discover somebody’s gone off and
changed the code… Which is their perfect right, of course.

Keeps us all on our toes, doesn’t it,

Peter
OSR