re: Kernel Thread Priority Floor Violation - Windows 8.1
As noted, this bug check has essentially no information whatsoever, so it's up to any pre-existing knowledge to attempt to understand what's going on here. I will do my best to share what I know!
First of all, the big thing to note is to my knowledge, a client/user system/OS will
never experience this bug check, and only server-based OS' 8+ do. To confirm this:
Code:
6: kd> vertarget
Windows 8 Kernel Version 9600 MP (8 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 9600.17085.amd64fre.winblue_gdr.140330-1035
Machine Name:
Kernel base = 0xfffff801`f2488000 PsLoadedModuleList = 0xfffff801`f27522d0
Debug session time: Mon Jun 2 11:17:52.139 2014 (UTC - 4:00)
System Uptime: 0 days 5:26:21.799
This system is a TS, and/or Terminal System. It's not a client/user system.
Right, so now that we know that, let's take a look at the bug check itself.
KERNEL_THREAD_PRIORITY_FLOOR_VIOLATION (157)
An illegal operation was attempted on the priority floor of a particular thread.
BugCheck 157, {
ffffe000d6aa2880,
9,
2, 0}
1st parameter - The address of the thread.
2nd parameter - The target priority value (?).
3rd parameter - The priority counter for the target priority underflowed (?).
4th parameter - Reserved.
As I am unsure as to what the 2nd/3rd parameters are given there's no documentation on them, we can only work with the 1st.
Code:
6: kd> !thread ffffe000d6aa2880
GetPointerFromAddress: unable to read from fffff801f27dc000
THREAD ffffe000d6aa2880 Cid 0e04.139c Teb: 00000000fe5e1000 Win32Thread: 0000000000000000 RUNNING on processor 6
Not impersonating
GetUlongFromAddress: unable to read from fffff801f2728300
Owning Process ffffe000d6a39280 Image: chrome.exe
Attached Process N/A Image: N/A
fffff78000000000: Unable to get shared data
Wait Start TickCount 1253235
Context Switch Count 2108197 IdealProcessor: 6
ReadMemory error: Cannot get nt!KeMaximumIncrement value.
UserTime 00:00:00.000
KernelTime 00:00:00.000
Win32 Start Address 0x000000005f38cd40
Stack Init ffffd00021bd3c90 Current ffffd00021bd35d0
Base ffffd00021bd4000 Limit ffffd00021bce000 Call 0
Priority 9 BasePriority 8 UnusualBoost 0 ForegroundBoost 0 IoPriority 2 PagePriority 5
Child-SP RetAddr : Args to Child : Call Site
ffffd000`21bd3858 fffff801`f25f66cd : 00000000`00000157 ffffe000`d6aa2880 00000000`00000009 00000000`00000002 : nt!KeBugCheckEx
ffffd000`21bd3860 fffff801`f24c4cb5 : 00000000`00000100 ffffd000`21bd3980 ffffe000`d6aa2880 00000000`00000002 : nt! ?? ::FNODOBFM::`string'+0xa21d
ffffd000`21bd38a0 fffff801`f24ecdaa : ffffe000`d6aa2ba0 00000000`00000000 00000000`00000000 ffffd000`21bd3980 : [COLOR=#4b0082]nt!KiAbThreadUnboostCpuPriority+0x39[/COLOR]
ffffd000`21bd38d0 fffff801`f24eca45 : ffffd000`21c47943 00000000`00000000 ffffe000`d6a9e000 fffff801`00000000 : nt!KeAbEntryFree+0x66
ffffd000`21bd3900 fffff801`f24efa09 : ffffe000`0000004f ffffe000`d6aa2880 ffffe000`d6a39758 ffffd000`00000040 : [COLOR=#0000cd]nt!ExfAcquirePushLockExclusiveEx+0x1b5[/COLOR]
ffffd000`21bd39c0 fffff801`f25e622f : 00000000`00000001 00000000`0341fdac 00000000`00000001 ffffd000`21bd3b00 : [COLOR=#ff0000]nt!MmAccessFault+0x7e9[/COLOR]
ffffd000`21bd3b00 00000000`5fa356a7 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiPageFault+0x12f (TrapFrame @ ffffd000`21bd3b00)
00000000`0341f744 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x5fa356a7
nt!MmAccessFault+0x7e9 calls into
nt!ExfAcquirePushLockExclusiveEx+0x1b5. With this said, we likely have a deadlock occurring, but why? We can see a
nt!KiAbThreadUnboostCpuPriority+0x39 call, which we'll now discuss.
Every thread has has what is called a
dynamic priority. This is essentially the priority the scheduler uses to determine which thread to execute. Initially, a thread's dynamic priority is the same as its base priority. The system can boost and lower the dynamic priority, to ensure that it is responsive and that no threads are starved for processor time. The system does not boost the priority of threads with a base priority level between 16 and 31. Only threads with a base priority between 0 and 15 receive dynamic priority boosts.
Some drivers create their own driver and/or device-dedicated system threads and set their thread's base priority to the lowest real-time priority value. Other highest-level drivers, particularly file system drivers, use system worker threads with a base priority that is usually set to the highest variable priority value. The kernel schedules a thread with the lowest real-time priority to run ahead of every thread with a variable priority, which includes almost every user-mode thread in the system.
Way more information here if interested -
Scheduling Priorities (Windows)
What was the illegal instruction exactly? Not entirely sure, really. Not much debugging and/or curiousity digging to be done with a minidump. If I had to take a guess, I would say we had an issue with priority inversion, in which two entirely different threads were scheduled. The way to properly keep things running smooth if this occurs is the low priority threads will run long enough to exit the critical section, and the high-priority thread can enter the critical section. If the low-priority thread does not get enough CPU time to exit the critical section the first time, it will get another chance during the next round of scheduling.
Either that, or the driver that is causing the suspected lock is buggy.
Perusing the loaded modules list, here are the drivers I suspect may be causing a problem:
1. Kaspersky 100% more than anything. I have seen
many issues with Kaspersky and Windows 8/8.1.
2. AsIO.sys (Asus PC Probe, other Asus bloatware).
Regards,
Patrick
