BSOD - 0x139 (KERNEL_SECURITY_CHECK_FAILURE)

I

IcePanther

Member
Hi,

I consistently get said BSOD on hwinfo64 startup, when or after it tries to enumerate PCI buses.

Windows 11 x64
HWinfo Version 7.64

Attached are the dump analysis from the minidump, that seems to point at the hwinfo64 driver ; also the hwinfo64.dbg log.
Zip password : h w i 6 4 (minus spaces, to prevent bots from scanning potential identifying info from the dumps, idk enough about them to know if there is any inside)

In case it can be useful :
In "core isolation" in the windows security app, are enabled :
- Memory Integrity
- Kernel Mode Hardware Enforced Stack Protection
- Microsoft vulnerable driver blacklist (greyed out, forced on)

Any help is appreciated.
TIA,
 

Attachments

  • hwilog.zip
    111.9 KB · Views: 3
Hi,

It did crash indeed. Here is the generated DBG file, zip password the same as before. The minidump analysis was very similar to the previous one so I omitted it.
 

Attachments

  • hwilog_765.zip
    95 KB · Views: 1
Thanks. This is quite weird, as if something in the system was blocking access to certain PCIe devices. Is there perhaps some security software installed?
 
I am using BitDefender, but it has been installed for a while now (>1 year) and didn't cause problems before. I guess it's possible an update would cause problems. I tried disabling it, and it still crashed.

However, it did reliably not crash when disabling "Kernel Mode Hardware Enforced Stack Protection" in Windows Security. Maybe the driver isn't fully compatible with that functionality ?
 
Indeed, same with the last build. With the "kernel mode..." stuff on, it crashes, without it, it doesn't.
 

Attachments

  • hwi_765_2.zip
    94.7 KB · Views: 1
Hmm, the driver is compatible with this feature but in certain special cases it seems that this technology (Control-Flow Enforcement Technology (CET) Shadow Stack) can lead to undesirable side-effects.
I have already discussed this problem with Microsoft and they couldn't explain this behavior either. To me it seems like an erratum in the CET...
 
OK, I have a plan.. But that will take some time, should have a new test build tomorrow...
 
One more request though.. Can you please attach a Debug File from build 5259 with "Kernel Mode Hardware Enforced Stack Protection" disabled, so when it doesn't crash?
 
Last edited:
Thanks! I'm wondering why your system is exhibiting such strange behavior in combination with CET (shadow stack).
Anyway, I will have a new test build soon.
 
Sorry, didn't see your second reply, I don't know if the forum sends only an email for the first unread post or what.
Anyway, it still crashes, DBG file attached.

I tried to reproduce the problem on my other computer, but despite it being a 12th gen Intel CPU, it doesn't offer me the option to enable CET Shadow Stack at all (HWinfo shows the CPU is capable of it, so maybe the manufacturer didn't enable something in the BIOS) so I can't test it there.
 

Attachments

  • crash_5260.zip
    100.6 KB · Views: 1
Thanks for the feedback. What kind of BSOD have you got with this build, is it the same KERNEL_SECURITY_CHECK_FAILURE?
 
Yup

KERNEL_SECURITY_CHECK_FAILURE (139)
A kernel component has corrupted a critical data structure. The corruption
could potentially allow a malicious user to gain control of this machine.
Arguments:
Arg1: 0000000000000039, A shadow stack violation has occurred due to mismatched return addresses
on the call stack vs the shadow stack.
Arg2: ffff8b890a05f310, Address of the trap frame for the exception that caused the BugCheck
Arg3: ffff8b890a05f268, Address of the exception record for the exception that caused the BugCheck
Arg4: 0000000000000000, Reserved
Click to expand...
 
Sweet ! This one didn't crash, I was able to use it normally. I tried launching it several times, first with debug mode, then without.
Here is a trace with the working version, in case you see something useful in it.

Anyway, thank you very much for your patience and efficiency in solving this. Really appreciated. :)

I gather you were able to track the root cause of the crash then ?
 

Attachments

  • 5268_works.zip
    149.8 KB · Views: 1
That's great news! :) Thank you too for your testing and feedback!
Yes, it's indeed a sort of lockout enforced by Microsoft on some devices. What remains weird however is that those BSODs were indicating a CET violation while in fact it's something else. MS couldn't explain this yet...
 
How nice it is to debug software when the error messages are wrong... Well, you managed to figure it out anyway. Kudos, and thanks again !
 
You must log in or register to reply here.
Back
Top