If you come upon a dump with bugcheck and parms = 0x9f (0x3,,,fffffa80'0ab61bd0)¹ (the memory address in P4 is variable - no 2 dumps or systems will contain the exact same memory address). NOTE: there is no P2 or P3 listed in the parameters of the bugcheck - I simply listed the commas with no values between them where these items would normally be)
For 0x9f bugcheck dumps, first, you look at P1. In this case it is 0x3, which tells you immediately that the Windbg command !irp can be run, which hopefully will reveal the name of a 3rd party driver (non-Microsoft driver). Microsoft drivers are considered to be sacrosanct and therefore are ruled out as the culprit in a BSOD.
If after Windows Updates are installed by hundreds-of-millions of systems on one night, or even spread over a few nights, if there is a rogue driver by Microsoft that got through, Microsoft's error reporting arm, WERCON, would immediately begin sending crash data back to Microsoft (including dump files) and Microsoft would know very quickly that one of its own modules is responsible. It does happen from time-to-time, but it is also a very rare event. In the event that Microsoft inadvertently sent out a bad driver, they would know it within 1-3 days; pull the affected module from future Windows Update runs; fix the module in question, re-release it to the public via Windows Updates and/or set up a download page for those users who wish to do it immediately and do it themselves.
The structure of the Windbg command (entered toward the bottom of the Windbg screen, to the right of kd>), is:
Rich (BB code):
!irp fffffa80'0ab61bd0The memory address next to !irp comes from P4)
¹ The 2 commas between P1 and P4 represent Parameter 2, 3 (P2, P3). They may or may not be filled with a number or memory address. In a 0x9f (0x3,,,) dump, we do not particularly care about the contents of P2 or P3. We look at P1 to see if it is a 0x3; if it is, then we issue the !irp Windbg command with the memory address found in P4.
Sometimes it is not even necessary to issue the !irp command as a "Warning" statements about missing symbols will give you a clue.
Code:
fffff800`00b9c8f8 fffff880`0638e288Unable to load image \SystemRoot\system32\DRIVERS\[HI]igdkmd64.sys[/HI], Win32 error 0n2
*** WARNING: Unable to verify timestamp for [HI]igdkmd64.sys[/HI]
*** ERROR: Module load completed but symbols could not be loaded for [HI]igdkmd64.sys[/HI]
igdkmd64+0x2c22880x9F: DRIVER_POWER_STATE_FAILURE
Here is the IRP command in action. As you can see, the bugcheck on the dump was -
Rich (BB code):
BugCheck 9F, {3, ffffe58f5fa6d060, ffffe2000f6298d0, ffffe58f67630bf0}
Rich (BB code):
Rich (BB code):
Rich (BB code):
The driver named on the line with the greater than symbol > is nvlddmkm.sys - which I happen to know is a NVIDIA video driver and because it is a 3rd party (non-Microsoft), we give it our full attention as it is likely our culprit here.
I recommended that the OP update the NVIDIA driver because it was from 2016 and the thread occurred 1 March 2019. So the driver was probably about 3 years old. In some cases it is necessary to have the OP roll the driver back.
Unfortunately, the OP never replied back, so we don't know the outcome.
Here is additional literature on 0x9f bugcheck BSODs - the first two were written in-house by our Sysnative BSOD Experts.
LITERATURE
- The Complete Guide for Debugging a Stop 0x9F
- PnP timeouts (0x9F)
- Bug Check 0x9F DRIVER_POWER_STATE_FAILURE - Windows drivers
- 0x9F: DRIVER_POWER_STATE_FAILURE
jcgriff2
Last edited by a moderator:
