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 (1e)
This is a very common bugcheck.  Usually the exception address pinpoints
the driver/function that caused the problem.  Always note this address
as well as the link date of the driver/image that contains this address.
Arguments:
Arg1: ffffffffc0000094, The exception code that was not handled
Arg2: fffff8072d0744b6, The address that the exception occurred at
Arg3: ffffc28fa9430780, Parameter 0 of the exception
Arg4: 000000000000005a, Parameter 1 of the exception

Debugging 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.1


ADDITIONAL_XML: 1

OS_BUILD_LAYERS: 1

BUGCHECK_CODE:  1e

BUGCHECK_P1: ffffffffc0000094

BUGCHECK_P2: fffff8072d0744b6

BUGCHECK_P3: ffffc28fa9430780

BUGCHECK_P4: 5a

EXCEPTION_PARAMETER1:  ffffc28fa9430780

EXCEPTION_PARAMETER2:  000000000000005a

BLACKBOXBSD: 1 (!blackboxbsd)


BLACKBOXNTFS: 1 (!blackboxntfs)


BLACKBOXPNP: 1 (!blackboxpnp)


BLACKBOXWINLOGON: 1

PROCESS_NAME:  System

BAD_STACK_POINTER:  fffff8072f880158

STACK_TEXT:  
fffff807`2f880158 fffff807`2d2ff65e     : 00000000`0000001e ffffffff`c0000094 fffff807`2d0744b6 ffffc28f`a9430780 : nt!KeBugCheckEx
fffff807`2f880160 fffff807`2d208462     : fffff807`2d2ff63c 00000000`00000000 00000000`00000000 00000000`00000000 : nt!HvlpVtlCallExceptionHandler+0x22
fffff807`2f8801a0 fffff807`2d05dd97     : fffff807`2f880710 00000000`00000000 fffff807`2f86bc60 fffff807`2d20310e : nt!RtlpExecuteHandlerForException+0x12
fffff807`2f8801d0 fffff807`2d05c9a6     : fffff807`2f86b378 fffff807`2f880e20 fffff807`2f86b378 00000000`00000006 : nt!RtlDispatchException+0x297
fffff807`2f8808f0 fffff807`2d200432     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiDispatchException+0x186
fffff807`2f880fb0 fffff807`2d200400     : fffff807`2d2116a5 00000000`00000000 00000000`00000000 00000000`00000001 : nt!KxExceptionDispatchOnExceptionStack+0x12
fffff807`2f86b238 fffff807`2d2116a5     : 00000000`00000000 00000000`00000000 00000000`00000001 00000000`0000002f : nt!KiExceptionDispatchOnExceptionStackContinue
fffff807`2f86b240 fffff807`2d20a30a     : 00000000`00000000 fffff807`31d311be 00000000`00000000 00000000`00000003 : nt!KiExceptionDispatch+0x125
fffff807`2f86b420 fffff807`2d0744b6     : fffff807`2bdee2e8 fffff807`2f86b669 fffff807`2da29dc8 00000000`00000000 : nt!KiDivideErrorFault+0x30a
fffff807`2f86b5b0 fffff807`2d0742de     : 00000069`2aa5c200 00000000`00000001 fffff807`2db074e0 ffffc28f`a989c010 : nt!PpmPerfSelectProcessorState+0x1a6
fffff807`2f86b6d0 fffff807`2d1397a0     : 00000000`00000000 fffff807`2f86bb20 fffff807`2f86b960 fffff807`2f86bb20 : nt!PpmPerfSelectProcessorStates+0x5e
fffff807`2f86b700 fffff807`2d139266     : 00000000`ffffffff 00000000`00000000 fffff807`2f86b960 fffff807`2f86bb20 : nt!PpmCheckRun+0x40
fffff807`2f86b770 fffff807`2d13a10e     : 00000000`00000000 fffff807`2f86bb20 00000000`00000000 00000000`00000000 : nt!PpmCheckStart+0x106
fffff807`2f86b810 fffff807`2d0f049e     : 00000000`00000000 00000000`00000000 00000000`00000001 fffff807`31d3870b : nt!PpmCheckPeriodicStart+0x3e
fffff807`2f86b860 fffff807`2d0ef784     : 00000000`00000000 00000000`00000000 00000000`00140001 00000000`00000000 : nt!KiExecuteAllDpcs+0x30e
fffff807`2f86b9d0 fffff807`2d20310e     : 00000000`00000000 fffff807`2bde6180 00000000`00000000 fffff807`2db32600 : nt!KiRetireDpcList+0x1f4
fffff807`2f86bc60 00000000`00000000     : fffff807`2f86c000 fffff807`2f866000 00000000`00000000 00000000`00000000 : nt!KiIdleLoop+0x9e


SYMBOL_NAME:  nt!PpmPerfSelectProcessorState+1a6

MODULE_NAME: nt

IMAGE_NAME:  ntkrnlmp.exe

STACK_COMMAND:  .thread ; .cxr ; kb

BUCKET_ID_FUNC_OFFSET:  1a6

FAILURE_BUCKET_ID:  0x1E_c0000094_STACKPTR_ERROR_nt!PpmPerfSelectProcessorState

OS_VERSION:  10.0.19041.1

BUILDLAB_STR:  vb_release

OSPLATFORM_TYPE:  x64

OSNAME:  Windows 10

FAILURE_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.

More Data

Exemplary Event Log excerpts:

https://securesha.re?#u=ee5051f696c4c79270febdbc624abe50.bin&p=0Omv4aHsD04EQjNoClCyAF5PqDJ4ZLPpu1ROpU_6De8

https://securesha.re?#u=f684af5eceaafe468177718afb33e29a.bin&p=0Omv4aHsD04EQjNoClCyAF5PqDJ4ZLPpu1ROpU_6De8

Memory Dumps:

https://securesha.re?#u=d5cc377c5e2127261df2c8ffb2ed557e.bin&p=oe47mjCEP7-2VSOi2Sc-ikrOEWXMncUpFI5eX2i3W2Q

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. 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.