What is causing my computer to BSOD at random times?

Hi Alex,

You should not use the bcdedit solution unless you are forced to. This is an alternative solution branch where you help the nameless ring0 shellcode by disabling your own hardware security. This would essentially resolve the shellcode-related problem as an alternative way.

If the Core Isolation way works, it is much better, because you do not have to disable your own security to help a dubious shellcode. Since we are not 100% sure it is patchguard the way not disabling your security would much be preferred.

Also, it's either Core Isolation OR disabling the Intel CET. You can't take both approaches!

Garys way is a last-resort solution, and/or an option when you are a competitive gamer / doing hardcore eSports and you absolutely can't live together with the Core Isolation, because Core Isolation has a strong tendency of fending off Anti-Cheat software using drivers that mess with the kernel in an inproper way.

Wow, two sources of BSODs is just exceptionally unlucky. I will have a short look at the new dump.

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.