KeWaitForSingleObject BLOCKS

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.

You have a logic problem or deadlock in your driver. Break in to the
driver with WinDBG and look at the threads and what they are waiting for
(!process and !thread are your friends here).


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

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.
>

How do you determine it is the same thread of execution, that is going to
set the event that you are waiting for?

Pls provide some sample code ( that you implemented), and someone will
catch the problem.

-pro

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.


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

Ok

This is little abstracted but i think it is enough

for(;:wink:
KeWaitForSingleObject(
&extension->event1,
… // kernel mode, not alertable and infinite timeout
);
… // this part is ok
// dispatch routeine unblocks previous wait
for(;;){
KeWaitForSingleObject(
&extension->event2,
… // kernel mode, not alertable and infinite timeout
); // this locks everything
// only desktop is available and programs started by taskmanager
// everything other is executing for a while and blocks

}
}

Is there any influence on thread prioryty (so it won’t be preempted?) after first wait instruction (kesetevent is called without boosting waiting thread)

By the way it isn’t a logic problem (at least it isn’t the reason for deadlocking)

Well without the logic for the threads that signal the events, and some
concept of how everything fits together this code smippet is of no value.
This is still likely a deadlock based on poor logic or lack of
understanding of Windows. Statements about it is not a logic problem
almost invariably prove wrong.

I would still recomend breaking in with the debugger and seeing what the
other threads are waiting on.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

wrote in message news:xxxxx@ntdev…
> Ok
>
> This is little abstracted but i think it is enough
>
> for(;:wink:
> KeWaitForSingleObject(
> &extension->event1,
> … // kernel mode, not alertable and infinite
> timeout
> );
> … // this part is ok
> // dispatch routeine unblocks previous wait
> for(;;){
> KeWaitForSingleObject(
> &extension->event2,
> … // kernel mode, not
> alertable and infinite timeout
> ); // this locks everything
> // only desktop is available and
> programs started by taskmanager
> // everything other is executing for a
> while and blocks
>
>
>
> }
> }
>
>
> Is there any influence on thread prioryty (so it won’t be preempted?)
> after first wait instruction (kesetevent is called without boosting
> waiting thread)
>

Are you writing a driver in the storage path (FS filter, disk filter, etc…)?

-p

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Sunday, May 06, 2007 10:58 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] KeWaitForSingleObject BLOCKS

Well without the logic for the threads that signal the events, and some
concept of how everything fits together this code smippet is of no value.
This is still likely a deadlock based on poor logic or lack of
understanding of Windows. Statements about it is not a logic problem
almost invariably prove wrong.

I would still recomend breaking in with the debugger and seeing what the
other threads are waiting on.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

wrote in message news:xxxxx@ntdev…
> Ok
>
> This is little abstracted but i think it is enough
>
> for(;:wink:
> KeWaitForSingleObject(
> &extension->event1,
> … // kernel mode, not alertable and infinite
> timeout
> );
> … // this part is ok
> // dispatch routeine unblocks previous wait
> for(;;){
> KeWaitForSingleObject(
> &extension->event2,
> … // kernel mode, not
> alertable and infinite timeout
> ); // this locks everything
> // only desktop is available and
> programs started by taskmanager
> // everything other is executing for a
> while and blocks
>
>
>
> }
> }
>
>
> Is there any influence on thread prioryty (so it won’t be preempted?)
> after first wait instruction (kesetevent is called without boosting
> waiting thread)
>


Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

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

Yes, but where is the code that calls KeSetEvent() and under what conditions is it invoked???

Anton Bassov

Yes it is a storage driver. First Wait waits for request. It gets and continues, it is ok. Second wait waits for special irp from user level app. But that thread is blocked ( after second wait ) and never reaches kesetevent. So it’s is a deadlock (it can be called logic error) But i can’t understand why the other thread is blocked. Thats why i mentioned the priority few times. Is it posible that thread that waits io request is blocked (i’ve already returned pending) and it is the reason for blocking my user level thread?

Not sure if others can understand your implementation but I really
cannot follow you. Could you explain why you use these waits in your
driver then probably we can have a good figure of your driver and find
out the problem.

Cheers,
R. Yang

  • Windows Kernel Developer [Custom Dev and Consulting]

On Sun, 6 May 2007 16:00:46 -0400 (EDT), xxxxx@gmail.com wrote:

Yes it is a storage driver. First Wait waits for request. It gets and continues, it is ok. Second wait waits for special irp from user level app. But that thread is blocked ( after second wait ) and never reaches kesetevent. So it’s is a deadlock (it can be called logic error) But i can’t understand why the other thread is blocked. Thats why i mentioned the priority few times. Is it posible that thread that waits io request is blocked (i’ve already returned pending) and it is the reason for blocking my user level thread?

Ok i’ll try to explain it

I’m trying to simulate storage. So when somebody tries to get something from the disk i am telling him whats on it. The data I want to return him back i can get from user mode app. and this is the architecture of the system. (if somebody knows better way to get data from user mode pls tell me, there is microsoft white paper that tells about synchonization by events, plug 'n play and pending irp i’m using that with pending irp)

dispatcher routine sets requests in apropriate queues.
there is a thread that loops and returns irps like geometry stuff. and it’s ok.
there is another thread that loops and cares about read/writes. and here is the problem.
up there is a skeleton of the code (it’s a little abstracted but i think it’s enough to explain what i’m trying to do) First Wait waits for read/write request. When somethink tries to read something dispatch routine sets first event and thread passes through it. Now when i have read/write irp i’m trying to send important info (like length and offset) to my thread that loops in user mode by some pending request. (User mode thread sends some request that is made pending in dispatch routine but sets event2) So this request should unblock second wait. But the problem is this is stucked when second wait occurs. So this thread never gets signaled.
The problem is i don’t understand why every thread is blocked when second kewaitforsingleobject is called. If it isn’t blocked as long as i know everything should be ok (thats why i said there is no problemin logic).

I still don’t understand what is your code doing :-).

What dispatch path you have this for(;;)? And why you doing this?. As
Peter pointed out ( is it in the storage path?, and as you said it is
yes). If one of your dispatch causes such a deadlock ( priority is not
going to be an issue ), it eventually blocks anyone comes thru this path.

Take out your feature logic, and put the rest of the code path.

Also if you conversant with windbg ( or any other kernel debugger), debug
it to see the state of the threads of the processes ( as you said it’s
blocking pretty much everything in the system, it is going tobe a very
ardous task to debug this way).

Finally (IMO), this is the best place to put debug trace (Kdprint or some
such) to see what is happening interms of ( event1, event2 's waits and
corresponding releases).

-pro

Yes it is a storage driver. First Wait waits for request. It gets and
continues, it is ok. Second wait waits for special irp from user level
app. But that thread is blocked ( after second wait ) and never reaches
kesetevent. So it’s is a deadlock (it can be called logic error) But i
can’t understand why the other thread is blocked. Thats why i mentioned
the priority few times. Is it posible that thread that waits io request is
blocked (i’ve already returned pending) and it is the reason for blocking
my user level thread?


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

Is this a disk driver, a hacked SCSI miniport or what? This makes a
difference, since for instance a SCSI miniort will single thread most
operations, so block your alerter thread.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

wrote in message news:xxxxx@ntdev…
> Ok i’ll try to explain it
>
> I’m trying to simulate storage. So when somebody tries to get something
> from the disk i am telling him whats on it. The data I want to return him
> back i can get from user mode app. and this is the architecture of the
> system. (if somebody knows better way to get data from user mode pls tell
> me, there is microsoft white paper that tells about synchonization by
> events, plug 'n play and pending irp i’m using that with pending irp)
>
> dispatcher routine sets requests in apropriate queues.
> there is a thread that loops and returns irps like geometry stuff. and
> it’s ok.
> there is another thread that loops and cares about read/writes. and here
> is the problem.
> up there is a skeleton of the code (it’s a little abstracted but i think
> it’s enough to explain what i’m trying to do) First Wait waits for
> read/write request. When somethink tries to read something dispatch
> routine sets first event and thread passes through it. Now when i have
> read/write irp i’m trying to send important info (like length and offset)
> to my thread that loops in user mode by some pending request. (User mode
> thread sends some request that is made pending in dispatch routine but
> sets event2) So this request should unblock second wait. But the problem
> is this is stucked when second wait occurs. So this thread never gets
> signaled.
> The problem is i don’t understand why every thread is blocked when second
> kewaitforsingleobject is called. If it isn’t blocked as long as i know
> everything should be ok (thats why i said there is no problemin logic).
>
>

i think it’s obvious it’s a disk driver it’s not scsi miniport. I’m not working with any piece of hardware. I’m just trying to simulate disk (it’s content can be get only from user mode). What is the difference if i am using disk or audio or video driver and it’s effect on threads. ? I hope my last post was enough clear what i’m trying to do.

xxxxx@gmail.com wrote:

i think it’s obvious it’s a disk driver it’s not scsi miniport. I’m not working with any piece of hardware. I’m just trying to simulate disk (it’s content can be get only from user mode). What is the difference if i am using disk or audio or video driver and it’s effect on threads. ?

It matters because, for some classes of device, the I/O subsystem and
the upper level drivers impose additional restrictions on concurrency.
For example, if an upper level driver was serializing IRPs, your code
would deadlock. Your “unlock” request couldn’t get in while the thread
was blocked.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

You basically shouldn’t block in paging I/O operations (which can occur on any file, not just the page file). There are a limited number of threads which can perform paging operations and if you block enough of them & depend on paging to service them (as your application does by definition) then you’re going to cause a deadlock.

You shouldn’t be blocking at all. You should pend the IRP and asynchronously complete it once your app returns the data.

-p

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Sunday, May 06, 2007 5:48 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] KeWaitForSingleObject BLOCKS

Ok i’ll try to explain it

I’m trying to simulate storage. So when somebody tries to get something from the disk i am telling him whats on it. The data I want to return him back i can get from user mode app. and this is the architecture of the system. (if somebody knows better way to get data from user mode pls tell me, there is microsoft white paper that tells about synchonization by events, plug 'n play and pending irp i’m using that with pending irp)

dispatcher routine sets requests in apropriate queues.
there is a thread that loops and returns irps like geometry stuff. and it’s ok.
there is another thread that loops and cares about read/writes. and here is the problem.
up there is a skeleton of the code (it’s a little abstracted but i think it’s enough to explain what i’m trying to do) First Wait waits for read/write request. When somethink tries to read something dispatch routine sets first event and thread passes through it. Now when i have read/write irp i’m trying to send important info (like length and offset) to my thread that loops in user mode by some pending request. (User mode thread sends some request that is made pending in dispatch routine but sets event2) So this request should unblock second wait. But the problem is this is stucked when second wait occurs. So this thread never gets signaled.
The problem is i don’t understand why every thread is blocked when second kewaitforsingleobject is called. If it isn’t blocked as long as i know everything should be ok (thats why i said there is no problemin logic).


Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

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

Thanks a lot (Tim & Peter) i guess i should make some redesign of my FSA. I thought every thread is executed independent of others. In that case it would probably worked well.
and peter you wrote

You shouldn’t be blocking at all. You should pend the IRP and asynchronously complete it once your app returns the data.

I must wait for user level request. Once i get it i’m returning back data to that request, so i have to be sure i has arrived once and then work with it.
Doesn’t matter after all i think i should redesign this taking care about this limitation.

Thanks again

You don’t need to block the thread to service the I/O request. You can leave it up to the caller to block until you complete the IRP, which you do when the request from your UM service comes down to the driver providing the data.

-p

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Monday, May 07, 2007 12:31 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] KeWaitForSingleObject BLOCKS

Thanks a lot (Tim & Peter) i guess i should make some redesign of my FSA. I thought every thread is executed independent of others. In that case it would probably worked well.
and peter you wrote

You shouldn’t be blocking at all. You should pend the IRP and asynchronously complete it once your app returns the data.

I must wait for user level request. Once i get it i’m returning back data to that request, so i have to be sure i has arrived once and then work with it.
Doesn’t matter after all i think i should redesign this taking care about this limitation.

Thanks again


Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

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

xxxxx@gmail.com wrote:

peter you wrote

You shouldn’t be blocking at all. You should pend the IRP and asynchronously complete it once your app returns the data.

I must wait for user level request.

You don’t understand. You can mark the IRP as pending, save it in a
queue somewhere in your driver, and return STATUS_PENDING. The calling
application will still not be allowed to continue, since the request has
not finished, but you aren’t locking that thread into a kernel-mode
wait. Then, when you get the “go-ahead” data, you pull the request out
of your queue and complete it.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

I guess we are a little misunderstood. The UM thread should make a call that will be made pending in the dispatch routine. But this where i’m waiting is the worker thread where i should process IO request. So I get io request from uncompleted requests queue and then i want to be sure that i have at least one pending request that i can use to send length offset info to UM thread. (and here is the problem when this thread blocks many other threads are blocked including UM thread which is supoused to make some request and that request should later be answered with data i’ve told.) The theory with serializing irp’s by io manager makes a little sense.
I hope we are on same way