When using SAR and with something using at least one of the endpoints,
killing the process that use SAR could cause the process to hang in a
unkillable state.
In that case, the process is hung waiting pending IRP against the SAR
driver to complete.
The issue appear when at least one of the endpoint is used, which cause
SarASIO to issue SAR_WAIT_HANDLE_QUEUE IOCTLs against the SAR driver.
SarASIO ensure that one IOCTL is always pending so if there is a handle
event on the driver side, SarASIO is triggered via the completion of the
pending SAR_WAIT_HANDLE_QUEUE IOCTL.
But in the event of a process kill, the process doesn't close its file
handle to the SAR driver cleanly, and instead file handles are closed by
windows itself.
When killing a process, open handles seems to be closed like this:
Issue a IRP_MJ_CLEANUP, which cause the orphaning of the SAR context
context in the driver (SarOrphanControlContext)
Loop all pending IRPs and cancel them. At this point, the cancel
function of the SAR driver does nothing as the control context was
released already.
So pending IRPs are leaked and never completed.
Windows wait the canceled IRPs to complete (with a status
STATUS_PENDING)
The root cause of all of this, is that when releasing the SAR
driver control context on IRP_MJ_CLEANUP or CLOSE, pending IRPs are leaked
and never completed.
This commit fix that and cancel all pending IRPs when orphaning the
control context.
As a side note, the modification of SarDeleteEndpoint fix a crash when
endpoint->filterFactory is NULL (which can happen in case of a failure in
SarCreateEndpoint before the filterFactory is initialized. Detected with
the driver verifier tool.
eiz
commented
5 years ago
When using SAR and with something using at least one of the endpoints, killing the process that use SAR could cause the process to hang in a unkillable state. In that case, the process is hung waiting pending IRP against the SAR driver to complete.
The issue appear when at least one of the endpoint is used, which cause SarASIO to issue SAR_WAIT_HANDLE_QUEUE IOCTLs against the SAR driver. SarASIO ensure that one IOCTL is always pending so if there is a handle event on the driver side, SarASIO is triggered via the completion of the pending SAR_WAIT_HANDLE_QUEUE IOCTL. But in the event of a process kill, the process doesn't close its file handle to the SAR driver cleanly, and instead file handles are closed by windows itself. When killing a process, open handles seems to be closed like this:
The root cause of all of this, is that when releasing the SAR driver control context on IRP_MJ_CLEANUP or CLOSE, pending IRPs are leaked and never completed.
This commit fix that and cancel all pending IRPs when orphaning the control context.
As a side note, the modification of SarDeleteEndpoint fix a crash when endpoint->filterFactory is NULL (which can happen in case of a failure in SarCreateEndpoint before the filterFactory is initialized. Detected with the driver verifier tool.
Fix issue eiz#59.