-
Notifications
You must be signed in to change notification settings - Fork 95
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BSOD: DRIVER_IRQL_NOT_LESS_OR_EQUAL/SYSTEM_THREAD_EXCEPTION_NOT_HANDLED #116
Comments
Here is the log of another bugcheck
|
This Line 1281 in 983d656
|
The issue seems consistently reproducible here, and each time the length is the lower half of the I wonder if @MartinDrab could you kindly take a look? |
Hello, |
Thanks for the information! Please bear with me for asking out of curiosity — how does normal upper filter drivers of the problematic drivers work if those IRP structures are non-standard and undocumented (as far as I can search)? Also, having read Request Monitoring and IrpTracker homepage, I am wondering if filter driver would be a better choice compared to hooking, for use cases where payload data rather than raw IRP packet content is of greater interest? What would be some potential drawbacks other than the loss of precise IRP contents and overheads? |
I consistently encountered
DRIVER_IRQL_NOT_LESS_OR_EQUAL
bugchecks when trying to hook certain third-party drivers on boot and capture data.Manually setting up data capture of the same drivers after boot, however, works without issues.Edit: Also triggered bugcheck once.WinDbg analysis is dumped below.
I understand that data capture has known stability problems as per https://github.com/MartinDrab/IRPMon/wiki/Monitoring-Drivers-and-Devices. Please feel free to close the issue if the behaviour is expected.
KD
!analyze -v
The text was updated successfully, but these errors were encountered: