What is causing my computer to BSOD at random times?

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.

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

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

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.

Hi all,
yeah, Gary is right. I thought it was a hyper-v and missed the p :D, but it's a registry-related function. And I should have seen that the process was Registry. So, unexplained crash. Not necessarily a hardware fault. Good that Gary was paying attention. That's why it's better to have multiple persons looking it over. :-)