My driver crashes sporadically with the below bug check.
DRIVER_POWER_STATE_FAILURE (9f)
A driver has failed to complete a power IRP within a specific time.
Arguments:
Arg1: 0000000000000003, A device object has been blocking an IRP for too long a time
Arg2: ffffa702db867360, Physical Device Object of the stack
Arg3: fffffc8dc1aa7118, nt!TRIAGE_9F_POWER on Win7 and higher, otherwise the Functional Device Object of the stack
Arg4: ffffa702f89075a0, The blocked IRP
Initial understanding is that when there is power state change driver crashes. However when we put the machine to sleep, driver doesnt crash. we dont have repo step to reproduce it.
should we handle anything for power IRPs in minifilter driver?
can we call ExRegistercallback with \Callback\PowerState so that I can unload the driver when machine goes to sleep? Not sure whether it is correct approach.
I couldnt get much from the dump though. I could see my driver sending events to the usermode service during the crash.
My driver works in synchronous model. for every reg/file/process event it calls Fltsendmessage to send the event to user mode where we get the verdict and send it to driver for it to either block or allow.
Any pointers? Not sure where to start and look for this issue.
Thanks in advance
Not a clue, but I’d start by looking at the irp and then see whether you are in the loop (if filter manager is on the irp stack the cbd is usually the parameter at that stack location )
I could see my driver sending messgae to usermode and waiting for the reply. For some reason it did not receive a reply from application.
Is there a way to capture the running application/services from the dump?
I wanted to know whether my application is running or for some reason it got terminated and the driver is waiting/getting blocked for a reply from the application.
That will show you the user mode stacks if it’s a full memory dump and they’re paged in. If it’s a kernel summary dump you won’t see anything in user mode, though it should show you your process if it’s running.
Mine is just a 4MB dump…not complete memory dump. The above command did not display any data…so not sure whether my application was running at that moment or not…
so I tried the following…
Manually killed the application from task manager and put the machine to sleep mode. I could see the crash where stack trace is exactly matching.
My hypothesis is that this crash happens when application crashed/terminated and driver is waiting for the update from application and machine goes to sleep mode.
when I further debugged I figured out that unload callback routine is not called when application is terminated or crashed. it gets called only when the application is stopped.
I was also thinking if we could handle ExRegistercallback with \Callback\PowerState as machine crashes when application is there and machine going to sleep mode.
Any idea how to handle this?
What unload callback are you expecting to happen? You should get a DisconnectNotifyCallback callback (passed to FltCreateCommunicationPort) but the app crashing definitely won’t unload your driver.
Thanks Scott. I am checking what callback will be called when application is getting killed or goes to suspend state so that I can handle the scenarios in driver