I’m running into a hang condition with using ExAquireResourceExclusiveLite. If I look at who owns the resouse and who is waiting on it i get (using WinDbg):
Thread that is waiting (our FS driver trying to acquire):
ae9aa7ac 804fd78e 85272608 85272598 863d83d0 nt!KiSwapContext+0x2f (FPO: [EBP 0xae9aa7e4] [0,0,4])
ae9aa7bc 804f64e8 85272598 85272598 00000000 nt!KiSwapThread+0x6a (FPO: [EBP 0xae9aa7e4] [0,0,4])
ae9aa7e4 80525ff8 00000000 00000000 00000000 nt!KeWaitForSingleObject+0x1c0 (FPO: [Non-Fpo])
ae9aa820 80526428 00000000 852ae5d8 8538f498 nt!ExpWaitForResource+0xde (FPO: [Non-Fpo])
ae9aa840 aefa38b3 852ae6a0 00000001 00000080 nt!ExAcquireResourceExclusiveLite+0x8c (FPO: [Non-Fpo])
ae9aa890 aefa4584 8538f498 ae9aa938 00000002 some_mod!ZxFindOrCreateFcb+0x3b (FPO: [Non-Fpo]) (CONV: stdcall)
ae9aa8ec aefa498e 8538f498 ae9aa938 aefa47f8 some_mod!ZxCreateFromNetRoot+0x10c (FPO: [Non-Fpo]) (CONV: stdcall)
ae9aa974 aef864b0 8538f498 8627f8f0 853507c8 some_mod!ZxCommonCreate+0x196 (FPO: [Non-Fpo]) (CONV: stdcall)
ae9aa9d8 aef63c44 aef99d60 ae9aac00 853507c8 some_mod!ZxFsdCommonDispatch+0x2ae (FPO: [Non-Fpo]) (CONV: stdcall)
ae9aaa14 804eb3c1 8627fc30 853505f0 853505f0 some_mod!MrxUdfDispatch+0xe4 (CONV: stdcall)
ae9aaa24 805679ad 86454b38 8547b72c ae9aabc0 nt!IopfCallDriver+0x31 (FPO: [0,0,1])
ae9aab08 805a0f52 86454b50 00000000 8547b688 nt!IopParseDevice+0xa4d (FPO: [Non-Fpo])
ae9aab80 8059da82 00000000 ae9aabc0 00000040 nt!ObpLookupObjectName+0x53a (FPO: [Non-Fpo])
ae9aabd4 8055c1a3 00000000 00000000 ffffff01 nt!ObOpenObjectByName+0xe8 (FPO: [Non-Fpo])
ae9aad54 805306a4 0191eedc 0191eeb4 00000000 nt!NtQueryAttributesFile+0xe9 (FPO: [Non-Fpo])
ae9aad54 7ffe0304 0191eedc 0191eeb4 00000000 nt!KiSystemService+0xc9 (FPO: [0,0] TrapFrame @ ae9aad64)
0191ef08 00000000 00000000 00000000 00000000 SharedUserData!SystemCallStub+0x4 (FPO: [0,0,0])
Thread that owns the resource (in a system service thread??):
b238bc84 804fd78e 863b89d8 863b8968 86294178 nt!KiSwapContext+0x2f (FPO: [EBP 0xb238bcc0] [0,0,4])
b238bc94 804f7d54 b238bd64 00000000 8055ce5c nt!KiSwapThread+0x6a (FPO: [EBP 0xb238bcc0] [0,0,4])
b238bcc0 8055cf3b 00000001 0123fe01 b238bd1c nt!KeRemoveQueue+0x228 (FPO: [Non-Fpo])
b238bd48 805306a4 00000174 0123ffac 0123ffb0 nt!NtRemoveIoCompletion+0xdf (FPO: [Non-Fpo])
b238bd48 7ffe0304 00000174 0123ffac 0123ffb0 nt!KiSystemService+0xc9 (FPO: [0,0] TrapFrame @ b238bd64)
0123ffb4 00000000 00000000 00000000 00000000 SharedUserData!SystemCallStub+0x4 (FPO: [0,0,0])
If anyone could shed some light on how ExAcquire…Lite works or some suggestions here it would be great. When you release the resource could it fail for some reasons (ie: wrong thread id ect)?
Thanks for any help,
Greg
It looks to me like you have a bug in your code whereby you acquire the
lock and forget to release it. Otherwise, how could the second thread
have ownership of your lock and not have your code in the stack? And no,
ExReleaseResourceForThreadLite cannot fail (if it could then its return
value wouldn’t be declared as VOID).
Greg Jacklin wrote:
I’m running into a hang condition with using
ExAquireResourceExclusiveLite. If I look at who owns the resouse and
who is waiting on it i get (using WinDbg):
Thread that is waiting (our FS driver trying to acquire):
ae9aa7ac 804fd78e 85272608 85272598 863d83d0 nt!KiSwapContext+0x2f (FPO:
[EBP 0xae9aa7e4] [0,0,4])
ae9aa7bc 804f64e8 85272598 85272598 00000000 nt!KiSwapThread+0x6a (FPO:
[EBP 0xae9aa7e4] [0,0,4])
ae9aa7e4 80525ff8 00000000 00000000 00000000
nt!KeWaitForSingleObject+0x1c0 (FPO: [Non-Fpo])
ae9aa820 80526428 00000000 852ae5d8 8538f498 nt!ExpWaitForResource+0xde
(FPO: [Non-Fpo])
ae9aa840 aefa38b3 852ae6a0 00000001 00000080
nt!ExAcquireResourceExclusiveLite+0x8c (FPO: [Non-Fpo])
ae9aa890 aefa4584 8538f498 ae9aa938 00000002
some_mod!ZxFindOrCreateFcb+0x3b (FPO: [Non-Fpo]) (CONV: stdcall)
ae9aa8ec aefa498e 8538f498 ae9aa938 aefa47f8
some_mod!ZxCreateFromNetRoot+0x10c (FPO: [Non-Fpo]) (CONV: stdcall)
ae9aa974 aef864b0 8538f498 8627f8f0 853507c8
some_mod!ZxCommonCreate+0x196 (FPO: [Non-Fpo]) (CONV: stdcall)
ae9aa9d8 aef63c44 aef99d60 ae9aac00 853507c8
some_mod!ZxFsdCommonDispatch+0x2ae (FPO: [Non-Fpo]) (CONV: stdcall)
ae9aaa14 804eb3c1 8627fc30 853505f0 853505f0
some_mod!MrxUdfDispatch+0xe4 (CONV: stdcall)
ae9aaa24 805679ad 86454b38 8547b72c ae9aabc0 nt!IopfCallDriver+0x31
(FPO: [0,0,1])
ae9aab08 805a0f52 86454b50 00000000 8547b688 nt!IopParseDevice+0xa4d
(FPO: [Non-Fpo])
ae9aab80 8059da82 00000000 ae9aabc0 00000040
nt!ObpLookupObjectName+0x53a (FPO: [Non-Fpo])
ae9aabd4 8055c1a3 00000000 00000000 ffffff01 nt!ObOpenObjectByName+0xe8
(FPO: [Non-Fpo])
ae9aad54 805306a4 0191eedc 0191eeb4 00000000
nt!NtQueryAttributesFile+0xe9 (FPO: [Non-Fpo])
ae9aad54 7ffe0304 0191eedc 0191eeb4 00000000 nt!KiSystemService+0xc9
(FPO: [0,0] TrapFrame @ ae9aad64)
0191ef08 00000000 00000000 00000000 00000000
SharedUserData!SystemCallStub+0x4 (FPO: [0,0,0])
Thread that owns the resource (in a system service thread??):
b238bc84 804fd78e 863b89d8 863b8968 86294178 nt!KiSwapContext+0x2f (FPO:
[EBP 0xb238bcc0] [0,0,4])
b238bc94 804f7d54 b238bd64 00000000 8055ce5c nt!KiSwapThread+0x6a (FPO:
[EBP 0xb238bcc0] [0,0,4])
b238bcc0 8055cf3b 00000001 0123fe01 b238bd1c nt!KeRemoveQueue+0x228
(FPO: [Non-Fpo])
b238bd48 805306a4 00000174 0123ffac 0123ffb0
nt!NtRemoveIoCompletion+0xdf (FPO: [Non-Fpo])
b238bd48 7ffe0304 00000174 0123ffac 0123ffb0 nt!KiSystemService+0xc9
(FPO: [0,0] TrapFrame @ b238bd64)
0123ffb4 00000000 00000000 00000000 00000000
SharedUserData!SystemCallStub+0x4 (FPO: [0,0,0])
If anyone could shed some light on how ExAcquire…Lite works or some
suggestions here it would be great. When you release the resource could
it fail for some reasons (ie: wrong thread id ect)?
Thanks for any help,
Greg
–
Nick Ryan (MVP for DDK)
OK… What about the behaviour of ExAquireResourceExclusiveLite…
Can you Aquire recursively with this type of resource?
“Nick Ryan” wrote in message
news:MC6-F7yBaT4ghriS3250001c653@mc6-f7.hotmail.com…
> It looks to me like you have a bug in your code whereby you acquire the
> lock and forget to release it. Otherwise, how could the second thread
> have ownership of your lock and not have your code in the stack? And no,
> ExReleaseResourceForThreadLite cannot fail (if it could then its return
> value wouldn’t be declared as VOID).
>
> Greg Jacklin wrote:
>
> > I’m running into a hang condition with using
> > ExAquireResourceExclusiveLite. If I look at who owns the resouse and
> > who is waiting on it i get (using WinDbg):
> >
> > Thread that is waiting (our FS driver trying to acquire):
> >
> > ae9aa7ac 804fd78e 85272608 85272598 863d83d0 nt!KiSwapContext+0x2f (FPO:
> > [EBP 0xae9aa7e4] [0,0,4])
> > ae9aa7bc 804f64e8 85272598 85272598 00000000 nt!KiSwapThread+0x6a (FPO:
> > [EBP 0xae9aa7e4] [0,0,4])
> > ae9aa7e4 80525ff8 00000000 00000000 00000000
> > nt!KeWaitForSingleObject+0x1c0 (FPO: [Non-Fpo])
> > ae9aa820 80526428 00000000 852ae5d8 8538f498 nt!ExpWaitForResource+0xde
> > (FPO: [Non-Fpo])
> > ae9aa840 aefa38b3 852ae6a0 00000001 00000080
> > nt!ExAcquireResourceExclusiveLite+0x8c (FPO: [Non-Fpo])
> > ae9aa890 aefa4584 8538f498 ae9aa938 00000002
> > some_mod!ZxFindOrCreateFcb+0x3b (FPO: [Non-Fpo]) (CONV: stdcall)
> > ae9aa8ec aefa498e 8538f498 ae9aa938 aefa47f8
> > some_mod!ZxCreateFromNetRoot+0x10c (FPO: [Non-Fpo]) (CONV: stdcall)
> > ae9aa974 aef864b0 8538f498 8627f8f0 853507c8
> > some_mod!ZxCommonCreate+0x196 (FPO: [Non-Fpo]) (CONV: stdcall)
> > ae9aa9d8 aef63c44 aef99d60 ae9aac00 853507c8
> > some_mod!ZxFsdCommonDispatch+0x2ae (FPO: [Non-Fpo]) (CONV: stdcall)
> > ae9aaa14 804eb3c1 8627fc30 853505f0 853505f0
> > some_mod!MrxUdfDispatch+0xe4 (CONV: stdcall)
> > ae9aaa24 805679ad 86454b38 8547b72c ae9aabc0 nt!IopfCallDriver+0x31
> > (FPO: [0,0,1])
> > ae9aab08 805a0f52 86454b50 00000000 8547b688 nt!IopParseDevice+0xa4d
> > (FPO: [Non-Fpo])
> > ae9aab80 8059da82 00000000 ae9aabc0 00000040
> > nt!ObpLookupObjectName+0x53a (FPO: [Non-Fpo])
> > ae9aabd4 8055c1a3 00000000 00000000 ffffff01 nt!ObOpenObjectByName+0xe8
> > (FPO: [Non-Fpo])
> > ae9aad54 805306a4 0191eedc 0191eeb4 00000000
> > nt!NtQueryAttributesFile+0xe9 (FPO: [Non-Fpo])
> > ae9aad54 7ffe0304 0191eedc 0191eeb4 00000000 nt!KiSystemService+0xc9
> > (FPO: [0,0] TrapFrame @ ae9aad64)
> > 0191ef08 00000000 00000000 00000000 00000000
> > SharedUserData!SystemCallStub+0x4 (FPO: [0,0,0])
> >
> > Thread that owns the resource (in a system service thread??):
> >
> > b238bc84 804fd78e 863b89d8 863b8968 86294178 nt!KiSwapContext+0x2f (FPO:
> > [EBP 0xb238bcc0] [0,0,4])
> > b238bc94 804f7d54 b238bd64 00000000 8055ce5c nt!KiSwapThread+0x6a (FPO:
> > [EBP 0xb238bcc0] [0,0,4])
> > b238bcc0 8055cf3b 00000001 0123fe01 b238bd1c nt!KeRemoveQueue+0x228
> > (FPO: [Non-Fpo])
> > b238bd48 805306a4 00000174 0123ffac 0123ffb0
> > nt!NtRemoveIoCompletion+0xdf (FPO: [Non-Fpo])
> > b238bd48 7ffe0304 00000174 0123ffac 0123ffb0 nt!KiSystemService+0xc9
> > (FPO: [0,0] TrapFrame @ b238bd64)
> > 0123ffb4 00000000 00000000 00000000 00000000
> > SharedUserData!SystemCallStub+0x4 (FPO: [0,0,0])
> >
> > If anyone could shed some light on how ExAcquire…Lite works or some
> > suggestions here it would be great. When you release the resource could
> > it fail for some reasons (ie: wrong thread id ect)?
> >
> > Thanks for any help,
> >
> > Greg
> >
>
> –
> Nick Ryan (MVP for DDK)
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@hotmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
See the comments in the DDK docs for this DDI:
“If the caller already has acquired the resource (for shared or
exclusive access), the current thread is granted the same type of access
recursively. Note that making this call does not convert a caller’s
exclusive ownership of a given resource to shared.”
Greg Jacklin wrote:
OK… What about the behaviour of ExAquireResourceExclusiveLite…
Can you Aquire recursively with this type of resource?
“Nick Ryan” wrote in message
> news:MC6-F7yBaT4ghriS3250001c653@mc6-f7.hotmail.com…
>
>>It looks to me like you have a bug in your code whereby you acquire the
>>lock and forget to release it. Otherwise, how could the second thread
>>have ownership of your lock and not have your code in the stack? And no,
>>ExReleaseResourceForThreadLite cannot fail (if it could then its return
>>value wouldn’t be declared as VOID).
>>
>>Greg Jacklin wrote:
>>
>>
>>>I’m running into a hang condition with using
>>>ExAquireResourceExclusiveLite. If I look at who owns the resouse and
>>>who is waiting on it i get (using WinDbg):
>>>
>>>Thread that is waiting (our FS driver trying to acquire):
>>>
>>>ae9aa7ac 804fd78e 85272608 85272598 863d83d0 nt!KiSwapContext+0x2f (FPO:
>>>[EBP 0xae9aa7e4] [0,0,4])
>>>ae9aa7bc 804f64e8 85272598 85272598 00000000 nt!KiSwapThread+0x6a (FPO:
>>>[EBP 0xae9aa7e4] [0,0,4])
>>>ae9aa7e4 80525ff8 00000000 00000000 00000000
>>>nt!KeWaitForSingleObject+0x1c0 (FPO: [Non-Fpo])
>>>ae9aa820 80526428 00000000 852ae5d8 8538f498 nt!ExpWaitForResource+0xde
>>>(FPO: [Non-Fpo])
>>>ae9aa840 aefa38b3 852ae6a0 00000001 00000080
>>>nt!ExAcquireResourceExclusiveLite+0x8c (FPO: [Non-Fpo])
>>>ae9aa890 aefa4584 8538f498 ae9aa938 00000002
>>>some_mod!ZxFindOrCreateFcb+0x3b (FPO: [Non-Fpo]) (CONV: stdcall)
>>>ae9aa8ec aefa498e 8538f498 ae9aa938 aefa47f8
>>>some_mod!ZxCreateFromNetRoot+0x10c (FPO: [Non-Fpo]) (CONV: stdcall)
>>>ae9aa974 aef864b0 8538f498 8627f8f0 853507c8
>>>some_mod!ZxCommonCreate+0x196 (FPO: [Non-Fpo]) (CONV: stdcall)
>>>ae9aa9d8 aef63c44 aef99d60 ae9aac00 853507c8
>>>some_mod!ZxFsdCommonDispatch+0x2ae (FPO: [Non-Fpo]) (CONV: stdcall)
>>>ae9aaa14 804eb3c1 8627fc30 853505f0 853505f0
>>>some_mod!MrxUdfDispatch+0xe4 (CONV: stdcall)
>>>ae9aaa24 805679ad 86454b38 8547b72c ae9aabc0 nt!IopfCallDriver+0x31
>>>(FPO: [0,0,1])
>>>ae9aab08 805a0f52 86454b50 00000000 8547b688 nt!IopParseDevice+0xa4d
>>>(FPO: [Non-Fpo])
>>>ae9aab80 8059da82 00000000 ae9aabc0 00000040
>>>nt!ObpLookupObjectName+0x53a (FPO: [Non-Fpo])
>>>ae9aabd4 8055c1a3 00000000 00000000 ffffff01 nt!ObOpenObjectByName+0xe8
>>>(FPO: [Non-Fpo])
>>>ae9aad54 805306a4 0191eedc 0191eeb4 00000000
>>>nt!NtQueryAttributesFile+0xe9 (FPO: [Non-Fpo])
>>>ae9aad54 7ffe0304 0191eedc 0191eeb4 00000000 nt!KiSystemService+0xc9
>>>(FPO: [0,0] TrapFrame @ ae9aad64)
>>>0191ef08 00000000 00000000 00000000 00000000
>>>SharedUserData!SystemCallStub+0x4 (FPO: [0,0,0])
>>>
>>>Thread that owns the resource (in a system service thread??):
>>>
>>>b238bc84 804fd78e 863b89d8 863b8968 86294178 nt!KiSwapContext+0x2f (FPO:
>>>[EBP 0xb238bcc0] [0,0,4])
>>>b238bc94 804f7d54 b238bd64 00000000 8055ce5c nt!KiSwapThread+0x6a (FPO:
>>>[EBP 0xb238bcc0] [0,0,4])
>>>b238bcc0 8055cf3b 00000001 0123fe01 b238bd1c nt!KeRemoveQueue+0x228
>>>(FPO: [Non-Fpo])
>>>b238bd48 805306a4 00000174 0123ffac 0123ffb0
>>>nt!NtRemoveIoCompletion+0xdf (FPO: [Non-Fpo])
>>>b238bd48 7ffe0304 00000174 0123ffac 0123ffb0 nt!KiSystemService+0xc9
>>>(FPO: [0,0] TrapFrame @ b238bd64)
>>>0123ffb4 00000000 00000000 00000000 00000000
>>>SharedUserData!SystemCallStub+0x4 (FPO: [0,0,0])
>>>
>>>If anyone could shed some light on how ExAcquire…Lite works or some
>>>suggestions here it would be great. When you release the resource could
>>>it fail for some reasons (ie: wrong thread id ect)?
>>>
>>>Thanks for any help,
>>>
>>>Greg
>>>
>>
>>–
>>Nick Ryan (MVP for DDK)
>>
>>
>>—
>>Questions? First check the Kernel Driver FAQ at
>
> http://www.osronline.com/article.cfm?id=256
>
>>You are currently subscribed to ntdev as: xxxxx@hotmail.com
>>To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>
>
>
–
Nick Ryan (MVP for DDK)