On 8/10/21 8:01 PM, Rémi Bernon wrote:
On 8/10/21 7:57 PM, Rémi Bernon wrote:
On 8/10/21 7:36 PM, Zebediah Figura (she/her) wrote:
On 8/10/21 12:29 PM, Rémi Bernon wrote:
Instead of waiting for it.
Otherwise the module may be unloaded on process shutdown while the thread is still busy processing events, causing possible invalid memory access (for instance when accessing the static pnp_devset device list).
I'm confused; how can the thread still be running during unload if we're waiting for the thread to stop?
The FDO IRP_MN_REMOVE_DEVICE is never called, and I think the process is shutting down and unloading its modules nonetheless. I don't know yet precisely how this is happening.
Sorry, I'm saying nonsense, I need to have a better look.
It actually seems to be something more like what's happening with wineusb.sys, where the device isn't removed from the driver device list, when the IRP_MN_SURPRISE_REMOVAL / IRP_MN_DEVICE_REMOVAL are sent by ntoskrnl on shutdown.
This time the device isn't removed at all from the list, and the thread can get (or may have) a stale device pointer, that has already been destroyed, causing memory and stack corruption (which is where I got confused).