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,
- A windows process A crashes, while at least one of its threads has acquired rundown protection of our filter.
- WER suspends process A and attempts to perform a memory dump / whatever it is
- WER processing takes a long time / hangs.
- Our filter receives a stop command
- 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.