Closed seanthegeek closed 1 year ago
Here's the report from BSOD viewer
==================================================
Dump File : 060723-8015-01.dmp
Crash Time : 6/7/2023 6:24:00 PM
Bug Check String : CRITICAL_PROCESS_DIED
Bug Check Code : 0x000000ef
Parameter 1 : ffffc901`200e0080
Parameter 2 : 00000000`00000000
Parameter 3 : 00000000`00000000
Parameter 4 : 00000000`00000000
Caused By Driver : ntoskrnl.exe
Caused By Address : ntoskrnl.exe+3f71b0
File Description : NT Kernel & System
Product Name : Microsoft® Windows® Operating System
Company : Microsoft Corporation
File Version : 10.0.19041.1288 (WinBuild.160101.0800)
Processor : x64
Crash Address : ntoskrnl.exe+3f71b0
Stack Address 1 :
Stack Address 2 :
Stack Address 3 :
Computer Name :
Full Path : C:\Windows\Minidump\060723-8015-01.dmp
Processors Count : 2
Major Version : 15
Minor Version : 19041
Dump File Size : 510,268
Dump File Time : 6/7/2023 6:24:30 PM
==================================================
I am interested in trying to find the source of the issues but I am afraid that this information is not going to be enough to help...
There are two likely candidates when it comes to bsod - as capemon is a usermode dll it has limited opportunities to cause full system crashes. The two most likely possibilities are after injection into services.exe (for certain types of detonation) or injection into lsass.exe as part of the tldump feature implemented in an auxiliary module.
Therefore if you are able to reproduce these crashes currently with the latest monitor I would ask you to try and determine whether either of these might be a factor. services.exe will only be monitored during some detonations/file types and tlsdump aux module can easily be switched off to quickly determine whether this is a factor.
Thanks. I'll do more testing this weekend.
Turns out the root cause was insufficient memory due to the issue described in #1618. I guess the issue didn't happen as much in newer builds of Windows because they are more memory efficient.
It turns out the "black screen" and random OS crashing had nothing to do with the configuration or build of libvirt/KVM/QEMU, but was caused by come kind of conflict between
capemon
with some versions of Windows 10. Affter so many rebuilds and testing I wasn't sure of that until now. Unfortunately, I wasn't able to identify a specific combination of builds of Windows 10 andcapemon
that fixed the issue, due to the cumulative nature of Windows 10+ updates. All I know is that once I applied the latest Windows 10 21 H2 patches at this time (which brought my build up to 19044.2965, the crashing during analysis stopped.@kevoreilly Not sure if you want to debug this or just put a warning about this in the documentation, I don't know enough about
capemon
or Windows internals to offer a fix, but I did manage to grab a minidump once when I got an actual BSOD instead of a full-on crash. I could also provide my full VM image if you like. I'd rather not share either of those things publicly for OPSEC reasons, but let me know if you have a way I can get them to you privately.