What is causing my computer to BSOD at random times?

Hi vivs_lunchtime and Gary,

I hope you both had wonderful holidays! To give an update, I have only had 2 crashes since enabling Core Isolation. As you guys have noted the first crash was unrelated to our previous issue. The second crash happened on January 1st, which I just now uploaded to the google drive. I'm going to assume this one was also unrelated, but I didn't get to see the BSoD screen so I'm not sure what the code for it was.

It sounds like enabling Core Isolation is working as expected, and the problem has gone away. I didn't try the bcdedit command because I haven't been having issues since I last posted here.

I do plan on upgrading to Windows 11 some time before the support for Win10 ends, so I'll likely do that soon. If that crash on January 1st happens to be caused by the CET issue then I know moving to Win11 will give me a permanent solution.

Thank you both again so much for all the help.

Let me know if there's anything else I can do to help other people with the issue I was having.

-Alex

That's only my expectations! :D

With Core Isolation enabled, expected:

usermode processes: not every thread has the Intel CET bit enabled, but the nt kernel sets the bit for all usermode processes that support it. (This can be viewed in procexp custom view.)

system threads: enabled, because the secure kernel uses it (from the outside).

With Core Isolation disabled, expected:

usermode processes: not every thread has the Intel CET bit enabled, but the nt kernel sets the bit for all all usermode processes that support it. (This can be viewed in procexp custom view.)

system threads: no system thread with Intel CET bit.

With the very special bcdedit parameter:

usermode processes: no Intel CET bit, because the nt kernel won't set it.

system threads: somewhat undefined. The decision is technically up to the secure kernel (only exists when Core Isolation was enabled), and also if the bcdedit parameter was really meant only for usermode Intel CET or if it is rather a "not Intel CET at all" flag. It's not exactly well documented at all. We should perhaps go looking. :D
@edit: I really think the special flag is meant only for usermode CET. But I am unable to find any solid documentation.

In theory it should be the secure kernel that sets the bit. The secure kernel manages the kernel shadow stack. Not the normal OS. The normal OS isn't doing that.

But now I am unsure, the early BSOD dumps, was CR4.CET bit already set in any system thread before Core Isolation was even enabled? That should not be. I didn't pay too much attention. It would be wrong to set the bit in kernel context thread when kernel is not using Intel CET and lead to undefined behavior. It must only be set for threads that actually use Intel CET.

Hello vivs_lunchtime,

My notes on the only code path that set CET in CR4 that I could find are:

if KiUserCetAllowed then set bit CET in CR4

KiUserCetAllowed is set if SharedUserData.XState.EnabledSupervisorFeatures has bit 11 (0x800) (XSTATE_CET_U) set

KiInitializeXSave initializes SharedUserData.XState.EnabledSupervisorFeatures (combines CPUID information with BCD information)

Obviously, I may have missed something important and upgrading to Windows 11 would probably be the best advice, but trying the BCDEdit command might provide quick relief...

Gary