flynn017

The !podev , !poreqlist and !poaction aren't documented within WinDbg for some reason, but there is a person which has written about them thankfully. These extensions are a must for Stop 0x0A and debugging any issues related to power like Stop 0x9F. !popolicy  The !popolicy displays information related to the current power policy of the current user.  !pocaps The !pocaps extensions displays information in relation to the power capabilities of the system, this is ideal for checking if drivers are attempting to use a unsupported sleep state. !poreqlist The !poreqlist extension will list all outstanding power IRPs from any driver which has called the PoRequestPowerIrp function. The function will create a Power IRP and then send it to the top of the device stack for a given device object.  The list of power IRPs will be shown under the FieldOffset field. The extension will provide the device object, driver object and the nature of the power IRP. !poaction  The !p...

You may have noticed or not have noticed with a few Stop 0x9F, the 0x4 value being the first parameter which indicates that a power IRP has failed to synchronize with the PnP Manager. The PnP Manager is a subsystem of the I/O Manager, and is used to allow devices to be added or removed without little interaction from the user. The best example to illustrate this point, would the insertion or removal of USB flash drives or any USB connected. The user will not have to install any additional drivers to use the device or configure any settings. The USB flash drive will almost instantaneously be added to the file system, and be able to managed by the user. This is a result of the design of the PnP Manager and the code used within the driver. The PnP Manager can't be directly interacted with any driver routines. The PnP Manager is both present in Kernel-Mode and User-Mode. The User-Mode version will interact with the Kernel-Mode version. The PnP Manager is also responsible for maintainin...

Usually, you may notice when using !irp in with a Stop 0x9F, that the completion status shows three different fields; sometimes with the addition of the pending flag being set. In this blog post, I'm going to explain what is actually happening and which completion status field is set. As you can see, there is three different IO Completion Status fields present, so the question is, which one is WinDbg suggesting? These fields are defined depending upon what the driver was going to do with the completed IRP. They are used with the IoSetCompletionRoutine function, which is defined as follows: These are all BOOL values, and thereby will be either true or false, depending upon the bit values. InvokeOnSuccess and InvokeOnError decided wherever the completion routine defined within the IO_STACK_LOCATION data structure will be called upon if the IRP is completed with a NTSTATUS Success value or NTSTATUS Error value. The next important data structure is the IO_STACK_LOCATION data str...

I've explained how to debug a Stop 0x9F in previous blog posts, but here I'm going to explain how exactly it detects a timeout, and thus bugchecks with the Stop 0x9F. We should understand now, that the two highlighted parameters are the most important for this type of bugcheck. The fourth parameter shows the Blocked IRP which caused the timeout, and the second parameter is the PDO of the device the driver is associated with. Lets look at the blocked IRP, using the !irp extension. So, we can see that a power related IRP is pending, and has held too long by a device object leading to the crash. tunnel.sys seems to be associated with the IRP, however, this isn't the exact problem here. We can see that tunnel.sys calls GsDriverEntry , which is a routine called after the driver is loaded and initialized. It take two parameters: a pointer to the DRIVER_OBJECT data structure, and a pointer to the path in the registry where the driver is stored. It's called at IRQL Level 0. ...

Hey everyone, I've got another Stop 0x9F example to show you, in this example I'm going to explain how to find the supported sleep states for a device and find the model of the hardware. I thought this would be especially helpful with the athrx.sys BSODs, since the looking up on the Driver Reference Table usually points to a generic entry. Firstly, we'll use the !devstack extension on the second parameter of the bugcheck. The !devstack extension will display the device stack for a associated device object. Remember parameter two is the physical device object. The > symbol points to the entry which matches the device object address used. I should also explain what a device stack is. A device stack is simply a list of device objects associated with a device node, each device object also has a associated a driver objects.  IRPs are usually processed by multiple device stacks. It's important to remember that a single driver object can have multiple device objects. A ...