Quick answer: 0X0000091F is a bugcheck raised when a kernel driver feeds an out-of-range priority value into a thread or queue — almost always a third-party audio, GPU, or capture driver that needs updating or removing.
I know this one is infuriating because the error text gives you nothing to work with. "The queue priority is invalid" is Windows telling you the kernel caught a driver misbehaving, then slammed the brakes before memory corruption spread. The check itself lives in routines like KeSetPriorityThread and the worker-thread queues that sit on top of it. When a driver calls in with a priority outside the legal range — think a value above 31 on the Windows priority scale, or a stale constant from an old SDK — the kernel bugchecks instead of letting the scheduler corrupt its own run queues. In my experience the usual suspects are Realtek audio packages bundled with OEM machines, older NVIDIA capture components, and cheap USB capture cards running drivers written for Windows 7. I've also seen it after a Logitech webcam driver update silently replaced the signed INF with a beta one.
Step-by-step fix
- Get the crash dump details. Open WinDbg (Preview is fine), press Ctrl+D, and point it at
C:\Windows\Minidump\. Load the most recent.dmpfile and run:
!analyze -v
lmvm <driver_name_from_stack>
Look at the STACK_TEXT section. The top few frames name the driver that handed Windows the bad priority. Write that filename down — probably something like RTKVHD64.sys, nvlddmkm.sys, or lvrs64.sys.
- Check the driver's date. In an elevated Command Prompt:
driverquery /v /fo table | findstr /i "rtk nv lvr usbvideo"
Anything compiled before 2018 running on Windows 11 is a red flag. Old drivers ship with old priority constants.
- Roll back or update that driver. Device Manager → find the device → Properties → Driver tab. If "Roll Back Driver" is available and the crash started after an update, use it. If not, grab the vendor's latest from their own site — not Windows Update. OEM sites often lag by a year; the chip vendor (Realtek, Intel, NVIDIA) usually has the current build.
- Reboot into Safe Mode and confirm. Hold Shift while clicking Restart, then pick Troubleshoot → Advanced → Startup Settings → Safe Mode. If the bugcheck stops, you've confirmed it's a third-party driver rather than a hardware fault. Safe Mode loads only Microsoft's basic driver set, so a clean run there is meaningful evidence.
- Remove the offending package completely. Uninstall from Apps & Features, then delete leftover INF entries:
pnputil /enum-drivers
pnputil /delete-driver oem42.inf /uninstall /force
Replace oem42.inf with the actual published name from the enum output. The /force flag matters when Windows thinks the driver is still in use.
If that doesn't fix it
Sometimes the dump points at a Microsoft driver, which means a kernel component is passing bad parameters to another one. That's when you turn on Driver Verifier. It's aggressive and it will make your machine slow until you turn it off, but it catches the exact class of bug this bugcheck represents.
verifier /standard /driver RTKVHD64.sys
verifier /querysettings
Enable it on one suspect driver at a time. Don't blanket-verify every driver — you'll drown in false positives and the machine may not boot. If it won't boot, hold F8 and pick "Disable Driver Verifier" from Advanced Startup, or boot a recovery USB and run verifier /reset.
Two other things worth ruling out:
- Overclocking. An unstable CPU or RAM overclock can corrupt the priority value mid-write. Reset BIOS to defaults and see if 0X0000091F follows you. It usually stops.
- Corrupted system files. Run
sfc /scannowthenDISM /Online /Cleanup-Image /RestoreHealth. Rarely the root cause, but a five-minute check.
Heads up: if you're seeing 0X0000091F on a virtual machine, check the guest additions or VMware Tools version. I've hit this exact bugcheck twice on old VMs where the host tools were two major versions behind.
Preventing it from coming back
Two habits kill 90% of these crashes. First, never let Windows Update install optional driver updates automatically — turn off "Receive updates for other Microsoft products" under Windows Update → Advanced options. Those "optional" drivers are often years-old OEM builds Windows has been carrying since launch. Second, when you install a peripheral, install the vendor's full driver package once, then stop touching it. The cascade of auto-updates from Windows Update, the vendor's utility, and the app's own updater is what produces mismatched version pairs like a 2016 audio driver next to a 2023 kernel component. They don't get along, and 0X0000091F is how Windows tells you so.