Are you calling KeWaitForSingleObject while holding some lock like
FAST_MUTEX or ERESOURCE?
This is not 100% prohibited, but a very bad idea which at least decreases
scalability and introduces the deadlock potential.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
wrote in message news:xxxxx@ntdev…
> Hi
>
> I’m trying to synchronize my threads with KeSetEvent and
KeWaitForSingleObject. But when KeWaitForSingleObject is executed all threads
in are blocked. So thread that should call KeSetEvent can’t be reached. Is
there any priority problem about this? I already called one Wait in the same
thread and it was ok, few seconds later it blocks.
>
In WinDbg there is a VERY slow-running (but useful) command:
!process 0 7
which dumps you the stacks of all existing threads in the OS. This is very
useful to find deadlocks.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
wrote in message news:xxxxx@ntdev…
> Hi
>
> I’m trying to synchronize my threads with KeSetEvent and
KeWaitForSingleObject. But when KeWaitForSingleObject is executed all threads
in are blocked. So thread that should call KeSetEvent can’t be reached. Is
there any priority problem about this? I already called one Wait in the same
thread and it was ok, few seconds later it blocks.
>
> Yes it is a storage driver. First Wait waits for request.
Storage driver paths are often called at DISPATCH_LEVEL, so, it is a VERY bad
idea to wait in them.
Your user app can have its paging path (after hitting a nonpresent page)
blocked by your own mechanism. A classic deadlock in Windows.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
Are you calling KeWaitForSingleObject while holding some lock like FAST_MUTEX or ERESOURCE?
There isn’t any lock except this (end few pending IO requests that shoul be answered)
Thread where i’m waiting is in PASSIVE_LEVEL(ok kewait… i think puts it in dispath_level but i think this should preepmt it out of execution and raise it’s priority for getting back - i think it’s disp_level purpouse, so other threads can execute independently of this).
Your user app can have its paging path (after hitting a nonpresent page) blocked by your own mechanism. A classic deadlock in Windows.
my user app just makes request that should be answered with (length offset stuff) and after that should return real data back in KM and then real request should be completed.
what’s the idea here: if something in KM is waiting something then paged code in user mode can’t be returnd back until block is sattisfied? (and that’s why the UM thread blocks)