This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(128, 8%, 22%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EA%3C/text%3E%3C/svg%3E)
I have a custom built gaming PC that has recently been blue screening randomly and it seems completely unprompted. It happens when I'm in the middle of a game, or when I'm working on a Word document with Spotify playing, or when I'm browsing google chrome with nothing else open. I don't know what could be causing it.
The error I get is always "KMODE_EXCEPTION_NOT_HANDLED"
I recently had an issue where my computer would BSOD with the same error every time I woke it up from sleep mode. I got a warranty replacement for my RAM and that fixed that issue. These BSODs seem to be caused by something else. This also means that I find it highly unlikely that there's something wrong with my RAM.
Here is a link to the dump files I've gathered so far. I will add more as my computer continues to crash. It happens once every few hours, it seems.
https://drive.google.com/drive/folders/1_QM2imGRMNnQtNsdU8W98a16JUMTyj0d?usp=sharing
Does anybody know what could be causing this issue? Do the dump files point to anything specifically that could be causing the crashes?
Thank you
Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.
Both DPC timeout bsod and Registry-not-finding-stuff bsod are unexplained. Usually that's the point where people say it's hardware failure, but it could be everything, and without a clear indication towards the source of the problem it is impossible to tell. Perhaps Alex needs to continue using the system and hope at some point something points more clear towards the problem.
Another weird thing? The cr4.CET bit was set to TRUE in the early critical corruption bsods, in SYSTEM thread. At that time Alex had no Core Isolation enabled. As I get it, on Windows OS (10,11) kernel CET is enabled only when the prerequisite, Core Isolation (memory integrity, HVCI) was enabled[1,2].
I read in all documentation that the bit must only be set on processes/threads that use it.
[1] https://learn.microsoft.com/en-us/windows-server/security/kernel-mode-hardware-stack-protection
[2] Youtube: "No Hat 2024 - Andrea Allievi - [Keynote] Modern Mitigations in Windows OS: Enhancing Security AGAINST KERNEL EXPLOITATIONS"
(Andrea Allievi being the Microsoft main developer of the Core Isolation so you can certainly rely on the information.)
As Gary, even though I have dozens of laptops and PCs, no one is capable of Intel CET. In other words, I can't go looking (with KD). Who sets the bit then? Certainly not the secure kernel, because the critical corruption bsods were before Alex activated the Core Isolation and therefore, there was no secure kernel (no VTL 1).
Why is that so? That does not seem to be right to me. Who sets it then? Because it's set. As everybody can see. :D
Hello vivs_lunchtime,
It will take some time to reconcile all of that information but, to keep the ball rolling, let me propose a tentative hypothesis:
CR4.CET is always set if the hardware supports it (as reported by the CPUID instruction) and it is not explicitly removed via Boot Configuration Data (BCD).
The steps needed to enable and operate a "shadow stack" (allocating memory, writing MSRs 0x6A0 (IA32_U_CET) and 0x6A2 (IA32_S_CET), etc.) are only performed if the conditions that you mentioned are met.
As mentioned in a previous post, I think that I found the code path that implements the first statement. I am now working on the second statement.
Gary
I can empirically positively certify your tentative hypothesis. The Cr4.CET bit is always set. For every process. It does not matter if CET is used, userspace or kernel, regardless.
I went to a friend and took over his gaming computer, setting up a KD session. I looked with and without Core Isolation + kernel shadow stack, and at both kernel and usermode threads and used even a legacy Windows 7 hypertrm.exe, for which it is fact that it was compiled without CET support.
Doesn't that mean that Alex won't have the choice to use the xsaveremovefeature 0x800 option, because this only disables userspace shadow stack. Not the bit? And it's the bit, together with the incompetent rwx ring0 shellcode, that causes the BSOD.
Who sets the damn bit (early boot? late stage boot? ntoskrnl at some point?) and can it be prevented? Because that means essentially that Alex is forced to use Core Isolation.
It would be nice to have a freedom not to be forced under Core Isolation and to have a choice. An incompetent rwx ring0 shellcode killing your system otherwise is just ridiculous.
Addendum: KiUserCetAllowed governs the kernel mode CET then as well? And you mean, governs the bit or you mean setup of the shadow stack?
(How do you know / find out?)
I did not dare to use the xRemoveSaveFeature 0x800, because I didn't know for sure if I would be able to revert it. So I don't know how CR4 looks like after using this command and the reboot.
Is there a revert command for xRemoveSaveFeature 0x800?
