I'm working on a security product minifilter project.
As part of the product, we monitor file, registry, process and network callbacks, and employ various out of context techniques (system threads, worker items, DPCs and APCs).
During filter unload, we use several rundown protection techniques, to make sure there are no outstanding callbacks (or APCs or DPCs) that are performing work in our driver context.
Recently we've run against the following scenario,
1) A windows process A crashes, while at least one of its threads has acquired rundown protection of our filter.
2) WER suspends process A and attempts to perform a memory dump / whatever it is
3) WER processing takes a long time / hangs.
4) Our filter receives a stop command
5) During unload procedure, we hang waiting in vain for the rundown protections that process A took, to reach zero,
(which it won't do, since process A will never reach that code, as it hangs between suspension and death)
What is the safe and correct way to handle this, without getting our driver stuck forever?
I considered making the rundown callbacks granular per process (to identify callbacks which no longer exist),
however, it seems during WER process the process A is not marked as dead per se.
We could try guessing that it won't comeback, but I'm not sure if unloading will have averse effects on WER trying to dump its memory/stacks.
Any ideas will be appreciated.
It looks like you're new here. If you want to get involved, click one of these buttons!
|Upcoming OSR Seminars|
|Developing Minifilters||29 July 2019||OSR Seminar Space|
|Writing WDF Drivers||23 Sept 2019||OSR Seminar Space|
|Kernel Debugging||21 Oct 2019||OSR Seminar Space|
|Internals & Software Drivers||18 Nov 2019||Dulles, VA|