Hello,
When process is terminating, one of things that system does is to close all opened handles by process (and possibly remove proper object instances).
What exacly is happening with IRPs that has been send, but not yet completed. I assume that system will try to cancel it - is that correct?
Can you describe how system is realizing it (I mean how it is finding IRPs to cancel - is it taking it from object, like from file_object and than looking into originator to see if this is thread that is going to be terminated - or in a different way)?
Also could you describe few situations in which buggy driver (e.g that is not properly handling IRP cancelations) can cause unkilleable process to happen (instant KeDelayExecutionThread)?
Thank you for your help.
This comes to concept of threaded irps. Each thread owns a list of requests that originated on that thread. When the thread dies, the list is walked and the outstanding irps are canceled. It is not tied to the file object. Any irps which are not completed orphan the thread and owning process until completed.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Wednesday, April 16, 2014 1:21 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] process termination explanation
Hello,
When process is terminating, one of things that system does is to close all opened handles by process (and possibly remove proper object instances).
What exacly is happening with IRPs that has been send, but not yet completed. I assume that system will try to cancel it - is that correct?
Can you describe how system is realizing it (I mean how it is finding IRPs to cancel - is it taking it from object, like from file_object and than looking into originator to see if this is thread that is going to be terminated - or in a different way)?
Also could you describe few situations in which buggy driver (e.g that is not properly handling IRP cancelations) can cause unkilleable process to happen (instant KeDelayExecutionThread)?
Thank you for your help.
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
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
xxxxx@gmail.com wrote:
Also could you describe few situations in which buggy driver (e.g that is not properly handling IRP cancelations) can cause unkilleable process to happen (instant KeDelayExecutionThread)?
When the file handle is closed, the system cancels any outstanding
requests, but you always need to remember that cancellation in Windows
is just a suggestion. The I/O system sets a bit in the IRP and waits
for something to happen. It is entirely up to the driver to honor that
cancellation request. If the driver doesn’t notice it, the IRP remains
outstanding, the file handle is not allowed to close, and the process
remains open.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Doron, Tim thank you for fast response.
@Doron,
It is not tied to the file object
I think in file_object there is something like IrpList - at least on Windows 7. What is it?
@Tim
Theoretical questions then: so in case driver is kind of a filter driver (whatever) does it means that to properly handle termination scenario - it always have to register cancel routine when passing IRP down stack? Or it is related only to self allocated IRPs that driver created and passed down?
> xxxxx@gmail.com wrote:
> Also could you describe few situations in which buggy driver (e.g that
> is not properly handling IRP cancelations) can cause unkilleable process
> to happen (instant KeDelayExecutionThread)?
When the file handle is closed, the system cancels any outstanding
requests, but you always need to remember that cancellation in Windows
is just a suggestion. The I/O system sets a bit in the IRP and waits
for something to happen. It is entirely up to the driver to honor that
cancellation request. If the driver doesn’t notice it, the IRP remains
outstanding, the file handle is not allowed to close, and the process
remains open.
Is the process truly unkillable? What about shutdown situations, or even
Task Manager “end process” requests? TerminateProcess? I see much danger
here…
Joe
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
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
Shutdown just turns off power, a hung irp wont’ hang shutdown (unless it somehow blocks the S5 irp)
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@flounder.com
Sent: Wednesday, April 16, 2014 1:35 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] process termination explanation
xxxxx@gmail.com wrote:
> Also could you describe few situations in which buggy driver (e.g
> that is not properly handling IRP cancelations) can cause unkilleable
> process to happen (instant KeDelayExecutionThread)?
When the file handle is closed, the system cancels any outstanding
requests, but you always need to remember that cancellation in Windows
is just a suggestion. The I/O system sets a bit in the IRP and waits
for something to happen. It is entirely up to the driver to honor
that cancellation request. If the driver doesn’t notice it, the IRP
remains outstanding, the file handle is not allowed to close, and the
process remains open.
Is the process truly unkillable? What about shutdown situations, or even Task Manager “end process” requests? TerminateProcess? I see much danger here…
Joe
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
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
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
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
A driver needs to handle cancelation if it is HOLDING ONTO the irp. Pass through or self-allocation doesn’t matter, what happens if the request is enqueued and pended within the driver
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Wednesday, April 16, 2014 1:35 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] process termination explanation
Doron, Tim thank you for fast response.
@Doron,
It is not tied to the file object
I think in file_object there is something like IrpList - at least on Windows 7. What is it?
@Tim
Theoretical questions then: so in case driver is kind of a filter driver (whatever) does it means that to properly handle termination scenario - it always have to register cancel routine when passing IRP down stack? Or it is related only to self allocated IRPs that driver created and passed down?
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
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
xxxxx@gmail.com wrote:
@Tim
Theoretical questions then: so in case driver is kind of a filter driver (whatever) does it means that to properly handle termination scenario - it always have to register cancel routine when passing IRP down stack? Or it is related only to self allocated IRPs that driver created and passed down?
An IRP is only owned by one driver at a time. The driver that owns the
IRP is responsible for handling cancellation. Filter drivers don’t
usually own IRPs for very long.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> What exacly is happening with IRPs that has been send, but not yet completed. I assume that system
will try to cancel it - is that correct?
Yes.
If the IRP is processed synchronously - then the thread cannot quit before the IRP is completed. So, if the cancellation no-oped (due to bug/race in a driver) and the IRP is still hanging pending - the process hangs at termination for a long time, if not even forever.
If the IRP is async - then there is a timeout waiting for it to complete. And, if timeout passes and the IRP is still not completed (cancellation was ignored by the driver) - then you have a popup message and an event log entry on it.
TerminateProcess in the caller still returns immediately in any case, it is just “send the termination command”.
Can you describe how system is realizing it (I mean how it is finding IRPs to cancel - is it taking it
from object, like from file_object
From thread object.
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com
> Theoretical questions then: so in case driver is kind of a filter driver (whatever) does it means that to
properly handle termination scenario - it always have to register cancel routine when passing IRP
down stack?
There is a notion of blocking IO, for instance, read from the socket, which will complete only when the data arrives from the other end, and this can occur with indefinite delay.
So are reads from COM ports and some USB pipes.
The driver must handle cancellation for such IRPs.
And, if there is a definite not-so-large response time, like reads from a disk drive (disk IRP cannot hang for an indefinite time) - then there is no need in cancellation.
Windows disk stack does not support cancellation, so are FSDs. The process termination will wait for all disk/FS IO to complete naturally.
Or it is related only to self allocated IRPs that driver created and passed down?
Such non-threaded IRPs are not in the picture of process termination at all. They do not belong to any process.
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com
> Is the process truly unkillable? What about shutdown situations, or even
Processes are not killed on shutdown.
Task Manager “end process” requests? TerminateProcess? I see much danger
here…
Yes.
In NT4, AFD.SYS had a bug so that some traffic caused by RPC/DCOM was not cancellable.
This really created unkillable processes in the Task Manager.
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com
For what I think is a relatively lucid discussion of when you need to handle cancel, you can read this article that I wrote many years back: http:
Bottom line: If you hold a request in your driver for “some time”, you need to handle cancel. If you don’t, you DO NOT want to write a cancel routine.
Peter
OSR
@OSRDrivers</http:>