Win10 Kernel Crash

Question

Hi,

I have a user-mode C++ app that reliably hangs/crashes my machine after several hours.

It used to just hang, requiring a power off.

After upgrading to Visual Studio 2022, it actually crashes the machine and leaves a memory.dmp.

Unfortunately, the info displayed by WinDbg means very little to me.

I would appreciate any pointers to what causes this crash and how to fix this.

Thanks in advance, Bengt-Olaf.

Location of my zipped memory.dmp: https://1drv.ms/u/s!AkjGEwEXFwUlkm_8pWLQ9n2ejaS7?e=GyWEnW

Below is what WinDbg produced:

Microsoft (R) Windows Debugger Version 10.0.22473.1005 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.

Loading Dump File [C:\Windows\MEMORY.DMP]
Kernel Bitmap Dump File: Full address space is available

Symbol search path is: srv*
Executable search path is: 
Windows 10 Kernel Version 19041 MP (8 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Edition build lab: 19041.1.amd64fre.vb_release.191206-1406
Machine Name:
Kernel base = 0xfffff805`11600000 PsLoadedModuleList = 0xfffff805`1222a2d0
Debug session time: Fri Nov 26 01:30:59.731 2021 (UTC - 5:00)
System Uptime: 0 days 11:02:42.405
Loading Kernel Symbols
...............................................................
................................................................
................................................................
..............................
Loading User Symbols

Loading unloaded module list
..................................................
For analysis of this file, run !analyze -v
nt!KeBugCheckEx:
fffff805`119f72a0 48894c2408      mov     qword ptr [rsp+8],rcx ss:0018:ffffcf8d`d866f8e0=000000000000000a
6: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high.  This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: ffffaa8077e40850, memory referenced
Arg2: 00000000000000ff, IRQL
Arg3: 0000000000000000, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: fffff8051190100c, address which referenced memory

Debugging Details:
------------------

KEY_VALUES_STRING: 1

    Key  : Analysis.CPU.mSec
    Value: 2687

    Key  : Analysis.DebugAnalysisManager
    Value: Create

    Key  : Analysis.Elapsed.mSec
    Value: 3611

    Key  : Analysis.Init.CPU.mSec
    Value: 48437

    Key  : Analysis.Init.Elapsed.mSec
    Value: 278785

    Key  : Analysis.Memory.CommitPeak.Mb
    Value: 377

    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

FILE_IN_CAB:  MEMORY.DMP

BUGCHECK_CODE:  a

BUGCHECK_P1: ffffaa8077e40850

BUGCHECK_P2: ff

BUGCHECK_P3: 0

BUGCHECK_P4: fffff8051190100c

READ_ADDRESS:  ffffaa8077e40850 

BLACKBOXBSD: 1 (!blackboxbsd)

BLACKBOXNTFS: 1 (!blackboxntfs)

BLACKBOXPNP: 1 (!blackboxpnp)

BLACKBOXWINLOGON: 1

PROCESS_NAME:  System

TRAP_FRAME:  ffffcf8dd866fa20 -- (.trap 0xffffcf8dd866fa20)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000000 rbx=0000000000000000 rcx=00000000061210f6
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff8051190100c rsp=ffffcf8dd866fbb0 rbp=ffffaa8037e40180
 r8=0000000000000000  r9=ffffaa8037e40180 r10=fffff80512324a00
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up di pl nz na pe nc
nt!KiUpdateSpeculationControl+0x10c:
fffff805`1190100c 41808ed006000002 or      byte ptr [r14+6D0h],2 ds:00000000`000006d0=??
Resetting default scope

STACK_TEXT:  
ffffcf8d`d866f8d8 fffff805`11a09269     : 00000000`0000000a ffffaa80`77e40850 00000000`000000ff 00000000`00000000 : nt!KeBugCheckEx
ffffcf8d`d866f8e0 fffff805`11a05569     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiBugCheckDispatch+0x69
ffffcf8d`d866fa20 fffff805`1190100c     : 00000000`00000000 00000000`00000001 ffffaa80`37e40180 ffffaa80`37e40180 : nt!KiPageFault+0x469
ffffcf8d`d866fbb0 fffff805`119fe4b2     : 000fa425`b59bbfff 00000000`00000001 00000000`00000000 fffff805`119fadca : nt!KiUpdateSpeculationControl+0x10c
ffffcf8d`d866fc20 fffff805`119faee6     : ffffffff`00000000 ffffaa80`37e4b240 ffff8609`08e60080 00000000`0000040f : nt!SwapContext+0x1b2
ffffcf8d`d866fc60 00000000`00000000     : ffffcf8d`d8670000 ffffcf8d`d866a000 00000000`00000000 00000000`00000000 : nt!KiIdleLoop+0x176

SYMBOL_NAME:  nt!KiUpdateSpeculationControl+10c

MODULE_NAME: nt

IMAGE_NAME:  ntkrnlmp.exe

STACK_COMMAND:  .cxr; .ecxr ; kb

BUCKET_ID_FUNC_OFFSET:  10c

FAILURE_BUCKET_ID:  AV_nt!KiUpdateSpeculationControl

OS_VERSION:  10.0.19041.1

BUILDLAB_STR:  vb_release

OSPLATFORM_TYPE:  x64

OSNAME:  Windows 10

FAILURE_ID_HASH:  {431d2158-d4ba-bb46-b2a9-7d404cafa803}

Followup:     MachineOwner
---------

Answer 1

I did that, thanks!

Answer 2

Technically, the application should not crash the system. Windows should deal with an application crashing so it doesn't bring down Windows or the system. Windows, drivers, BIOS issues, hardware can.

However, it could be possible to over use/tax the system from bad code (not regarding heat) so that it starves Windows and that starvation eventually crashes the system because Windows can no longer do anything. But that's what debugging and logs are for. I don't know if you wrote the code or not based on this. Use of the drivers, Windows APIs etc in the application where the problem occurs inside of the code for those isn't really the application at fault but the application could workaround it by doing things differently.

I can get a few ideas from above but not sure how they factor in as in where the problem is or what you should do. But there's IRQL_NOT_LESS_OR_EQUAL and also KiUpdateSpeculationControl as two ideas. The first could take you into drivers, bad system files, and other things, and the other looks to be speculative execution side channel mitigations eg Spectre and meltdown security flaws.

You could try to disable the spectre and meldown security which I think you can to either a full extent or partial extent. I have never seen a reason on AMD CPU's to do so. But, I would assume you trust the application enough to do so. Don't know if it would work or not. Just a shot in the dark. https://msrc.microsoft.com/update-guide/vulnerability/ADV180002

Obviously, also if its the only thing doing it then you can also just not use it and move on from it.

Answer 3

In this case, I advise you to open start and search for feedback and open the Feedback Hub app and report this issue and include dump files , so the Windows team would be able to investigate it.

Answer 4

I don't want to rule out issues with my code. It's just that I have no idea how to track it down.

The machine crashes and reboots. So, there is no message.

I ran the code in Debug and Release mode - only difference is how long it takes to crash.

I ran it inside VS and it did not encounter any issues, i.e. no exception.

I assume that means the exception occurs in kernel mode ???

Answer 5

Sometimes it might be due to the code and memory reference.

I observed the similar behavior when you write a code with memory reference or pointer and it is due to bug in the code.

I am wondering, when it crashes what error code is being displayed?