Alex wrote:
It looks like a guarded mutex is being acquired at DPC level. That's pretty bad.
Well, at least it's redundant and useless. :-)
Pushlocks shouldn't be acquired at DPC level either
Indeed. If "you" are at DPC level, you have but one synchronization to care about - SMP (i.e. CPU<->CPU).
, but there's no ASSERTs in the pushlock code that check for that.
An oversight that should be fixed, I'm sure (even if it happened to slow down the system by a whole order of magnitude, which it won't).
MMProbeAndLockPages should never be called for paged pool addreses while at DPC level,
Should MmProbeAndLock ever be called at IRQL above APC level? I mean, what if the probing fails? Should the paging executive somehow preempt this call and page in the missing pages (or should it simply throw a "page not present" exception - not too great to do at DPC level I'd say)?
which means the driver probably called it for a non-paged pool address.
If my previous suspicion is correct, I build on that and suspect this is an error in itself. The ProbeAndLock call should be done at APC level (though I may be completely wrong, but do read my finishing line).
In that case, the whole loop about checking if the page is present
and
then faulting it in is irrelevant, and won't happen.
Right. Page fault at DPC level == Bad Move(tm).