A recent analysis of a Windows kernel-memory dump has provided a detailed look into a DRIVER_POWER_STATE_FAILURE, a critical error that results in a Blue Screen of Death (BSOD).
The investigation reveals how a single malfunctioning driver can cause a system-wide deadlock, ultimately forcing the operating system to crash.
The failure, identified by the bugcheck code 0x9F, was traced back to the rassstp.sys driver, a component responsible for handling Secure Socket Tunneling Protocol (SSTP) VPN connections.
The debugging session began by examining the system state at the time of the crash. The !analyze -v command, a powerful diagnostic tool in the Windows Debugger, quickly identified the DRIVER_POWER_STATE_FAILURE.
This error signifies that a driver failed to respond to a power-related I/O Request Packet (IRP) within the designated time frame. In this case, the timeout was set to 300 seconds.
The first argument of the bugcheck indicated that the timeout occurred while the system was waiting to synchronize with the Plug and Play (PnP) subsystem.
The PnP manager is responsible for coordinating the addition, removal, and management of hardware and drivers. The third argument pointed to the specific thread that was holding onto the PnP lock, preventing other system processes from proceeding.
Tracing The Root Cause
Further investigation from the researcher into the faulting thread revealed that it was a PnP device event worker operating within the System process.
This worker thread was tasked with processing a “surprise removal” of the WAN Miniport (SSTP) network adapter. During this process, the thread acquired an exclusive lock on the PnP engine (PiEngineLock) to ensure the removal could proceed without interference.
However, the process stalled when the worker thread called upon the rassstp.sys driver to perform its part of the device removal. The driver failed to complete the operation and never signaled back to the worker thread that it was finished.
As a result, the worker thread remained in a waiting state, holding the critical PiEngineLock for the entire 300-second timeout period. The failure of the rassstp.sys driver to release the worker thread created a domino effect across the system.
With the PiEngineLock held indefinitely, other essential system operations that required access to the PnP subsystem were blocked. The analysis identified three other threads that were waiting for this lock.
Most critically, one of the waiting threads belonged to wininit.exe, a core Windows process responsible for system startup and shutdown.
This thread was attempting to execute a system shutdown by transitioning the system’s power state. To do this, it needed to acquire the PiEngineLock to notify all devices of the impending power change.
Since the stalled PnP worker already held the lock, the shutdown process was completely halted. This deadlock scenario, where the system could neither complete the device removal nor initiate a shutdown, left the operating system with no choice but to trigger a bugcheck to prevent further instability.
Find this Story Interesting! Follow us on Google News, LinkedIn, and X to Get More Instant Updates.
Source link
