Device Guard VBS BSOD: SYSTEM_THREAD_EXCEPTION_NOT_HANDLED_M amdppm.sys
- Thread starter ravenize
- Start date
Ok upon further testing suddenly device guard started working on its own after doing the restore to the debug state with no bad drivers or software installed and verifier enabled... I have no clue what the heck happened. NX began working out of the blu and at the same time DG no longer bluescreens. I did not change any bios settings, and restored to the state where it previously failed.
Last edited:
- May 7, 2013
- 10,400
Odd, there might have been remains of the incompatible software in the registry somewhere; I'm not completely sure.
I would continue to use the system as you usually would for a few days and see if it remains stable.
I would continue to use the system as you usually would for a few days and see if it remains stable.
found out one thing, aicharger by asus, even the latest version (2018) which effectively increases charging power to usb devices, by detecting if a device is charge capable, causes keyboard, mouse and other devices to stop functioning when booting; I suspect this has to do with the IMMOU virtualization protection changing DMA addresses, the aicharger buggers everything; seems to happen during boot as well, lights go off on devices and stay off, its automatically installed as "demand start"
Last edited:
Yes I have for 24 hours with no issues at all; thank you for your help!
Last edited:
- May 7, 2013
- 10,400
I would personally remove AICharger, it's known to be pretty buggy and has even caused BSOD issues in the past as well.
The Ai Charger program has obtained the EOL status and is not supported by Asus, therefore I agree with @x BlueRobot to uninstall it
So the problem began again, with one exception, device guard is working, but only when CBS is enabled in the bios, but if I enable strict UEFI only it bluescreens. Immediately prior to finding this out it appears someone had planted a boot kit onto my PC. I detected it with GMER in the first byte of the MBR; GMER stated "rootkit like activity", never seen that before. This is with boot guard and VBS enabled. All this happened immediately after re-enabling DCOM, and allowing remote DCOM to troubleshoot problems with windows Sandbox. I enabled PS_Lockdown environment variables to help secure the PC and rebooted, upon reboot I got a password screen which is something I had explicitly disabled at logon, so I assume it was mimikatz or something looking to log my keystrokes; upon a second reboot there was no password screen, I ran GMER and the threat was not persistent, nothing found in offline scans.
Anyway, the problem persists; I don't know why or what happened exactly to cause it to trigger again... but at least it IS working with CBS enabled, I figure it may reduce the security of secure boot to some degree, which appears not to be infallible.
Anyway, the problem persists; I don't know why or what happened exactly to cause it to trigger again... but at least it IS working with CBS enabled, I figure it may reduce the security of secure boot to some degree, which appears not to be infallible.
Last edited:
Correct; I found this reading around online, "I understand that you can't have CSM and Secure Boot enabled at the same time because CSM gives the possibility of unsigned OptionROMs. I also understand that once you install Windows with CSM enabled, you can't go back and disable CSM later and therefore: no Secure Boot."
I've got a strange blend of both; as do other people. Some install with secure boot disabled, and have no problem enabling later. I guess it depends on the hardware. I don't know how true it is about needing to install fresh in strict UEFI mode, or if this is just a bug. I am quite certain this is what I did originally, but I may have performed distupgrades with CSM enabled. Any tips, ideas?
Last edited:
- May 7, 2013
- 10,400
I'm not sure if that is correct, doesn't make sense to me. I'll have to check the UEFI documentation and see if that provides any clarification.
They're internal functions written by Windows for chipset drivers to utilise. You won't be able to find much information at all regarding these unfortunately.
Please let us how it goes!
- May 7, 2013
- 10,400
You may also want to start another thread in the security section regarding the rootkit - Security Arena
Just in case, there's any remnants or other potential malware hidden somewhere.
Just in case, there's any remnants or other potential malware hidden somewhere.
I have done both online and offline scans, I suspect if there was a virus it would be embedded in WMI. I found inconsistencies and salvaged the WMI, but am not sure how to locate malware in WMI, or if salvaging WMI may automatically help do that... I guess resetting WMI to factory defaults may do the trick. The trigger appeared to be enabling remote connections in DCOM temporarily for DCOM troubleshooting, but DCOM is unable to communicate with MSDTC, does this not render dcom completely ineffective? I suspect it is not running because I had disabled DCOM prior to running windows updates and dist-upgrades... given that, I am unsure if DCOM is even capable of functioning at all. Any ideas? The service is logged on as "NT AUTHORITY\NetworkService", people suggest if it was not set to NetworkService, it generally causes this issue
Here is some Event Viewer Info:
Its the same in my virtual machine, and DCOM is working there.
Here is some Event Viewer Info:
Code:
MSDTC started with the following settings:
Security Configuration (OFF = 0 and ON = 1):
Allow Remote Administrator = 0,
Network Clients = 0,
Transaction Manager Communication:
Allow Inbound Transactions = 0,
Allow Outbound Transactions = 0,
Transaction Internet Protocol (TIP) = 0,
Enable XA Transactions = 0,
Enable SNA LU 6.2 Transactions = 1,
MSDTC Communications Security = Mutual Authentication Required,
Account = NT AUTHORITY\NetworkService,
Firewall Exclusion Detected = 0
Transaction Bridge Installed = 0
Filtering Duplicate Events = 1Its the same in my virtual machine, and DCOM is working there.
Last edited:
- May 7, 2013
- 10,400
The trigger for the error message? Did you complete a fresh install of Windows? You mentioned that you might do one in your earlier post.
The trigger... I enabled DCOM, and remote access defaults in DCOM and immediately ran gmer, in case WMI/DCOM unleashed hidden malware, and sure enough that is when gmer detected MBR rookkit activity, followed by the password screen which appeared upon reboot, and is technically disabled at logon.
Just did a fresh install to test, had the same BSOD error immediately after the initial fresh install from boot medium after the first reboot... " Used windows media creation tool to create medium, for windows 10 2004.
SYSTEM_THREAD_EXCEPTION_NOT_HANDLED
Using latest BIOS, Asus TUF x570 Pro Gaming/w Ryzen 3600, windows 10 2004; Removed & reset Secureboot Keys this time as well. Only solution so far is to enable CSM, and for Microsoft and or ASUS to fix this bug; Any other suggestions?
Last edited:
Has Sysnative Forums helped you? Please consider donating to help us support the site!