BSOD KMODE_EXCEPTION_NOT_HANDLED in PpmPerfSelectProcessorState

Hi everyone!


I was asked to investigate a KMODE_EXCEPTION_NOT_HANDLED BSOD on a Windows 10 system. Its current minimal configuration is:


Configuration


Mainboard: Asus P8P67

CPU: Intel Core i5-2500K

Memory: 1x Corsair TW3X4G1333C9A 2 GB DDR3 1333 MHz

Graphics Card: VN240GT-MD1G

PSU: Cougar PowerX 550

Storage: Samsung SSD 840 Pro

OS: Windows 10 Version 20H2


Issue


The owner and I have consistently observed the following symptom: The system boots normally. After about one to ten minutes, the beforementioned BSOD occurs. Importantly, it does not seem to be trigerred by any direct user interaction, as the problem may also occur when the computer is idle.


Debugging information


I have collected two memory dumps. As they are extremely similar, I will only show one of them here:


******************************************************************************** ** Bugcheck Analysis ** ********************************************************************************KMODE_EXCEPTION_NOT_HANDLED 1eThis is a very common bugcheck. Usually the exception address pinpointsthe driver/function that caused the problem. Always note this addressas well as the link date of the driver/image that contains this address.Arguments:Arg1: ffffffffc0000094, The exception code that was not handledArg2: fffff8072d0744b6, The address that the exception occurred atArg3: ffffc28fa9430780, Parameter 0 of the exceptionArg4: 000000000000005a, Parameter 1 of the exceptionDebugging Details:------------------KEY_VALUES_STRING: 1 Key : Analysis.CPU.mSec Value: 4937 Key : Analysis.DebugAnalysisProvider.CPP Value: Create: 8007007e on [blackened] Key : Analysis.DebugData Value: CreateObject Key : Analysis.DebugModel Value: CreateObject Key : Analysis.Elapsed.mSec Value: 5016 Key : Analysis.Memory.CommitPeak.Mb Value: 74 Key : Analysis.System Value: CreateObject Key : WER.OS.Branch Value: vb_release Key : WER.OS.Timestamp Value: 2019-12-06T14:06:00Z Key : WER.OS.Version Value: 10.0.19041.1ADDITIONAL_XML: 1OS_BUILD_LAYERS: 1BUGCHECK_CODE: 1eBUGCHECK_P1: ffffffffc0000094BUGCHECK_P2: fffff8072d0744b6BUGCHECK_P3: ffffc28fa9430780BUGCHECK_P4: 5aEXCEPTION_PARAMETER1: ffffc28fa9430780EXCEPTION_PARAMETER2: 000000000000005aBLACKBOXBSD: 1 !blackboxbsdBLACKBOXNTFS: 1 !blackboxntfsBLACKBOXPNP: 1 !blackboxpnpBLACKBOXWINLOGON: 1PROCESS_NAME: SystemBAD_STACK_POINTER: fffff8072f880158STACK_TEXT: fffff807`2f880158 fffff807`2d2ff65e : 00000000`0000001e ffffffff`c0000094 fffff807`2d0744b6 ffffc28f`a9430780 : nt!KeBugCheckExfffff807`2f880160 fffff807`2d208462 : fffff807`2d2ff63c 00000000`00000000 00000000`00000000 00000000`00000000 : nt!HvlpVtlCallExceptionHandler+0x22fffff807`2f8801a0 fffff807`2d05dd97 : fffff807`2f880710 00000000`00000000 fffff807`2f86bc60 fffff807`2d20310e : nt!RtlpExecuteHandlerForException+0x12fffff807`2f8801d0 fffff807`2d05c9a6 : fffff807`2f86b378 fffff807`2f880e20 fffff807`2f86b378 00000000`00000006 : nt!RtlDispatchException+0x297fffff807`2f8808f0 fffff807`2d200432 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiDispatchException+0x186fffff807`2f880fb0 fffff807`2d200400 : fffff807`2d2116a5 00000000`00000000 00000000`00000000 00000000`00000001 : nt!KxExceptionDispatchOnExceptionStack+0x12fffff807`2f86b238 fffff807`2d2116a5 : 00000000`00000000 00000000`00000000 00000000`00000001 00000000`0000002f : nt!KiExceptionDispatchOnExceptionStackContinuefffff807`2f86b240 fffff807`2d20a30a : 00000000`00000000 fffff807`31d311be 00000000`00000000 00000000`00000003 : nt!KiExceptionDispatch+0x125fffff807`2f86b420 fffff807`2d0744b6 : fffff807`2bdee2e8 fffff807`2f86b669 fffff807`2da29dc8 00000000`00000000 : nt!KiDivideErrorFault+0x30afffff807`2f86b5b0 fffff807`2d0742de : 00000069`2aa5c200 00000000`00000001 fffff807`2db074e0 ffffc28f`a989c010 : nt!PpmPerfSelectProcessorState+0x1a6fffff807`2f86b6d0 fffff807`2d1397a0 : 00000000`00000000 fffff807`2f86bb20 fffff807`2f86b960 fffff807`2f86bb20 : nt!PpmPerfSelectProcessorStates+0x5efffff807`2f86b700 fffff807`2d139266 : 00000000`ffffffff 00000000`00000000 fffff807`2f86b960 fffff807`2f86bb20 : nt!PpmCheckRun+0x40fffff807`2f86b770 fffff807`2d13a10e : 00000000`00000000 fffff807`2f86bb20 00000000`00000000 00000000`00000000 : nt!PpmCheckStart+0x106fffff807`2f86b810 fffff807`2d0f049e : 00000000`00000000 00000000`00000000 00000000`00000001 fffff807`31d3870b : nt!PpmCheckPeriodicStart+0x3efffff807`2f86b860 fffff807`2d0ef784 : 00000000`00000000 00000000`00000000 00000000`00140001 00000000`00000000 : nt!KiExecuteAllDpcs+0x30efffff807`2f86b9d0 fffff807`2d20310e : 00000000`00000000 fffff807`2bde6180 00000000`00000000 fffff807`2db32600 : nt!KiRetireDpcList+0x1f4fffff807`2f86bc60 00000000`00000000 : fffff807`2f86c000 fffff807`2f866000 00000000`00000000 00000000`00000000 : nt!KiIdleLoop+0x9eSYMBOL_NAME: nt!PpmPerfSelectProcessorState+1a6MODULE_NAME: ntIMAGE_NAME: ntkrnlmp.exeSTACK_COMMAND: .thread ; .cxr ; kbBUCKET_ID_FUNC_OFFSET: 1a6FAILURE_BUCKET_ID: 0x1E_c0000094_STACKPTR_ERROR_nt!PpmPerfSelectProcessorStateOS_VERSION: 10.0.19041.1BUILDLAB_STR: vb_releaseOSPLATFORM_TYPE: x64OSNAME: Windows 10FAILURE_ID_HASH: {a349e6fc-c773-5f1f-3d98-37443aaf47b7}Followup: MachineOwner


The two dumps only differ in the PROCESS_NAME value. In this case idle, it is SYSTEM. In the other dump heavy load, Prime95 caused the error, but with near-identical stack traces and the same exception code which refers to STATUS_INTEGER_DIVIDE_BY_ZERO.


I can share the full memory dumps, if you think they might be insightful.


Preconditions


I have done extensive memory testing and swapped graphics cards to reduce the probability that this is a memory or hardware-related fault.


Given that the offending function in the stack trace is called "PpmPerfSelectProcessorState", I set the number of active cores to one and disabled C4 and C6 state reporting to the OS. The system seemed to be more stable, failing after about two hours instead of minutes, and only after extensive stress testing with Prime95. I have tested this setup only once, though, so take this information with a grain of salt.


As the owner told me the problems started to occur only recently and he had not changed any parts, I tried to downgrade to Windows 10 Version 1909. The computer has been up and running for more than 24 hours now, so I think it is safe to say that this Windows version is not affected by this problem.


Further details


A peculiarly similar issue was described here: https://docs.microsoft.com/en-us/answers/questions/60996/new-windows-10-install-leads-to-repeat-bsod-ntoskr.html Even the stack traces match.


In the linked thread it is observed that CPU usage is always at 100%. I can verify that this problem occurs on this machine as well, but it has not been fixed by downgrading to version 1909. I am not sure, therefore, if it is related to the problem in question.


What strikes me, though, is that in both threads, the processor in question is a 2nd-generation Intel Core processor. So the problem might only occur on some processors of that architecture.


What can I do next?

Weiterlesen...