What is causing my computer to BSOD at random times?

Uh-oh. It is not certain that Core Isolation can stop this madness. (Explained below).

Reason:

Gary found the CR0-manipulating code sequence in the official image of Microsoft, at three locations. (See locations on page 4 of this thread.)

I went searching for it on Win10 and Win11 VMs. I found them. It's on all Windows systems. My VMS have no rootkits, and my barebones have no rootkits, I assure you that. I even checked my own private gaming PC and found them as well.

As we all know, the code sequence has a programming error (an unfortunate accident), namely that it doesn't check for the presence of the CET bit set in CR4 before trying to remove the Write Protection. That is the ultimate source of the BSOD.

I went on to look if the sequences contain the necessary CR4.CET check, or zero it out. They don't. Surprise... And I mean: on my VMs and my barebones.

(On none of my systems the CET bit is set, though, but I will come to that.)

It follows that it is a patchguard programming error (you could also call it an oversight). The "CR0-manipulating and forgetting the CR4.CET checks" sequence is on everybodys PC. Of course, it could still be a rootkit, copying the faulty code sequence, but this makes the explanation more complex than it needs be, and I tend to believe the more simple explanation.

As stated by Gary, it appears in multiple locations. If this sequence is executed, it will blow up any system with CET enabled. If the code would zero out or check the CR4.CET bit, the BSODs could be avoided.

A possible explanation for this "unfortunate accident": CET enabled is not common. Or rather, the technology is known since a long time already, but also being enabled and active is a recent thing and it is yet uncommon (but increasing). For instance, I have none. You need a Intel CPU generation 11+ or AMD Zen3+, and by the way, VT-d enabled in BIOS. My explanation is that the patchguard developers didn't have it on the radar with the CET bit. For years (decades?) their patchguard code just worked and they were happy with it and are not aware of this trouble.

Pro arguments that support my hypothesis:

• Majority of afflicted people report they bought a new PC. (with very new CPUs, like AMD Zen3+, CET capable.)
• People with new modern PC, get all mass-infected by sophisticated rootkit? Not likely! Fails my sanity check.
• People with new modern PC completely erase and reinstall their Windows, and get reinfected? Not likely! Fails my sanity check.
• The majority, if not all, have a very modern CPU (AMD Zen 3+ mostly). This allows for Intel CET, but having Intel CET enabled is, currently, a rare thing. This would explain why patchguard of Win10 doesn't have it on the radar.
• The killer sequence, which is the ultimate cause of the BSOD, is from Patchguard. This is certain! The CR4 CET check is missing. It can be found on everybodys PC. Not only the PCs of the afflicted people. But unless you have the CET feature enabled, no BSOD would happen at executing these code bytes.

Contra arguments:

• Currently got only Win10 afflicted people, not Win11. But also I did not truly search. But let me say it loud and clear: I found it on Win11 images as well, and with missing CR4.CET check.
• Alex had (two, I believe) minidumps with a CRITICAL CORRUTION alert from patchguard for code modification, the code modification was both times in an ndis routine and cut through a x64 opcode, making it defect and destroyed the whole rest of the routine. It was, by the way, a moderately important routine. There is no explanation for this, yet. These two cases of code modification and destruction urge to use Core Isolation and not lower security.
• As Gary said, no knowledge about patchguard allocating heap for r(w)x shellcode. Though remind, it shows a peculiar PA space linearity and also some other pecularities. We don't know how it was created. Only that it was not ExAllocate, or any other mundane method. It could be a rootkit that copied the faulty patchguard code and use it. There are also some slight differences between the patchguard code and the shellcode, and the code is hard to understand.

One thing is certain: the potential killer sequence can be found on everybody's Windows, not just on the afflicted, at multiple locations. It might trigger on everybody's system silently but does not harm (it will just remove the Write Protection bit... successfully!). Really most people do not have the CET bit set and cannot get the BSOD. Instead, their Write Protection would get removed for a short time. The shellcode resets the original Write Protection bit some shellcode later (which would also cause a crash if a CET enabled system would ever reach it). Removing the CR0 Write Protection bit for the purpose of writing on read-only pages is crude and barbaric. That gets -100 credits points, and another -100 points for not having checked the CR4.CET bit.

Other questions:

Question: download motherboard drivers from official site?

Answer: yes. Better do.

Question: Try to use Verifier?

Answer: Don't.

a) verifier only works against normal driver images.

b) Enabling verifier against third party drivers has a moderately high chance to be successfull! The more questionable third party drivers you have, the more dangerous. It's high risk locking yourself out of your system and lose your whole system just because verifier decides to hunt down a boot time driver as prey. Not even speaking of all the BSODs killing your system because verifier finds something on a third party driver during *runtime*. Worst case is when it hunts down boot time drivers, and you cannot boot anymore. If you are bored and like some "fun", at least unleash high inquisition only against runtime drivers, no boot drivers. You will certainly live a very dangerous life, be prepared for BSODs.

Solutions:

There is no good solution. The best would be if Core Isolation can stop the madness.

Intel CET can't be disabled in the BIOS except by perhaps by disabling VT-d. CR4.CET is set by the OS. For example Windows 10. Since Win10 22H2+, kernel shadow stack was implemented the first time, and usermode processes can demand have the CR4.CET bit set for their process. Patchguard shellcode in all minidumps did run at IRQL 2, arbitrary process context. If it runs within a process context with a CR4.CET bit set (minidump examples seen: system, csrss), it's game over.

Finally, what about a different OS, including Win11 24H2, which may have a chance of not using the killer sequence even if I found it there. I found one locked thread with somebody that was afflicted and changed to Win11. He never returned, which might indicate success.

But on Win11, the sequence that will kill everybody with Intel CET enabled is at least in nt!KiSwInterruptDispatch, which is also described in the tetrane document (thus, no nameless shellcode but signed ntoskrnl code). It will cause certain BSOD if executed on any system with Intel CET enabled. Because of the mentioned programming error.

The long term solution is to get a patchguard developer's attention so that he adds either an unconditional CR4.CET zeroing or a CR4.CET check. Which is missing right now to my best knowledge.

We need a patchguard developer.

Hi Gary and vivs_lunchtime,

I appreciate the clarification, I didn't realize you could get a BSoD without the screen loading. I enabled Core Isolation without any trouble, and I didn't have to remove any drivers. I will keep you guys in the loop about if I get a crash or not with this enabled. Also in terms of the crash being related to AMD chips specifically, I noticed that my computer didn't blue screen after the Windows refresh until after I redownloaded AMD Adrenaline, which I got my AMD chipset drivers and graphics drivers from. Maybe the problem is related to that software and I would be better off getting drivers directly from AMD's website in the future?

Thank you,

Alex J

Hello vivs_lunchtime,

There are quite a few descriptions of PatchGuard in the web; the one that I have been consulting most is Tetrane_PatchGuard_Analysis_RS4_v1.01.pdf (Author : Luc Reginato).

I have not noticed any mention (in that document or elsewhere) of copying PatchGuard code into a non-paged pool allocation and executing it from there.

I would also imagine that Microsoft test PatchGuard very well; I would see that as an obligation when they deploy obfuscated code to production and end-user systems.

The number of similar cases that we have found in the Internet is enough to indicate that something worthy of research is happening, but still small. And, as you say, it seems (from my limited recollection) to be Windows 10 with AMD chips that are affected; I also think that most of the reports are from year 2024.

Alex's single CRITICAL_STRUCTURE_CORRUPTION bug check also indicates an intention to "corrupt" the kernel.

The above circumstantial factors suggest malware, but the complexity of PatchGuard means it could still be a subtle (and unintentional) Microsoft bug.

I will keep researching and posting updates here.

Gary

Nah, you had a BSOD, but apparently no time anymore to project it on your monitor.

Same as always, you were killed by nice little shellcode trying to bluntly write bit 1 on CR0.WP without having checked CR4.CET. I just checked, was set. That killed you, again. :-)

Turn on the Core Isolation, that's the only thing that might currently save you. :-)

That, or perhaps we could think about disabling the security technology of CET (Control-flow Enforcement Technology). That would take the BSOD also away, help the shellcode succeed...

Perhaps, if you really want to get rid of the BSOD, I mean, I hate saying it, but you could think about looking into the BIOS, find if there is a Control-flow Enforcement Technology option, and disable it. You would disable an important modern security mechanism to help a dubious shellcode succeed and thus, not BSOD. I would not do it even if it works. Try first with Core Isolation.

Hello Alex,

The visible symptoms may be different, but the dump file is another KMODE_EXCEPTION_NOT_HANDLED caused by the "mov cr0,rax" instruction.

Gary