Hello and welcome to the forum!
Sadly I don't have a concrete answer for you. Dump analysis isn't as cut-and-dried as some people imagine, it's often a process of looking at what's happened and using one's knowledge and experience to make a best judgement. This is one of those cases.
Both dumps are a 0xA (IRQL_NOT_LESS_OR_EQUAL) bugchecks, that indicates that a memory reference was invalid (page not allocated, paged-out, or bad RAM) whilst running at an elevated IRQL (when page faults are not permitted). This bugcheck is common in many third-party drivers, they foul up their memory pointers, or even their memory allocations, and end up referencing memory that is invalid whilst running at an elevated IRQL.
Windows modules do not make these kinds of error. Windows modules can be considered error free.
In both of your dumps there are no third-party drivers referenced on the call stack (the function calls leading up to the bug check), but that doesn't mean that this isn't a third party driver issue. I note that both dumps fail in eaxctly the same way...
Code:
TRAP_FRAME: fffff1896c5677b0 -- (.trap 0xfffff1896c5677b0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=ffffde0f92267e60 rbx=0000000000000000 rcx=0000000000000003
rdx=ffffde0f91c43340 rsi=0000000000000000 rdi=0000000000000000
rip=fffff8025a8f8c39 rsp=fffff1896c567940 rbp=fffff1896c567999
r8=0000000000000000 r9=0000000000000002 r10=0000fffff8025ac3
r11=ffff887955000000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl zr na po nc
nt!KiDeliverApc+0x2a9:
fffff802`5a8f8c39 48395108 cmp qword ptr [rcx+8],rdx ds:00000000`0000000b=????????????????
Resetting default scope
At the bottom there you can see the Windows function nt!KiDeliverApc, which is delivering an asynchronous procedure call (APC), this is a way of calling procedures in real-time. The instruction that failed is a CMP instruction using the RCX pointer to reference one value to be compared (the RDX register references the other). You can see that the RCX register contains the value (0x3) and when added to the 0x8 in the CMP instruction a reference to the memory location 0x00000000 0000000B is made - and that location is invalid (note the ????????????????).
Clearly some other bit of code (or some other function) set the RCX register value incorrectly.
I note also that both dumps failed with League of Legends.exe in control and I note that you have the FACEIT_AC.sys driver installed, this is a component of the FaceIt anti-cheat feature...
Code:
17: kd> lmDvmFACEIT_AC
Browse full module list
start end module name
fffff802`77cf0000 fffff802`7c008000 FACEIT_AC (deferred)
Image path: \??\C:\Program Files\FACEIT AC\FACEIT_AC.sys
Image name: FACEIT_AC.sys
Browse all global symbols functions data
Timestamp: Wed Nov 8 12:05:06 2023 (654B5D52)
CheckSum: 043208AF
ImageSize: 04318000
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4
Information from resource tables:
The very recent date of this driver makes me wonder whether it's the installation of this driver that is causing your BSODS? In the absence of any other information I would query the FaceIt anti-cheat product. Can you do without that? Or roll-back to whatever version you were running?
You mentioned Driver Verifier and that it 'passed' your system. That's not at all what Driver Verfier does. It's designed to subject selected drivers to additional tests and checks to see whether they are behaving properly, the objective being to trap flaky drivers. Driver Verifier needs to be run correctly to be of any use, so if you're happy to run with Driver Verifier enabled that would be an excellent way of finding what driver is causing these BSODs. Here's how to enable Driver Verifier properly...
1. Take a System Restore point and/or take a disk image of your system drive (with Acronis, Macrium Reflect, or similar). It is possible that Driver Verifier may BSOD a driver during the boot process (some drivers are loaded during boot). If that happens you'll be stuck in a boot-BSOD loop.
If you should end up in a boot-BSOD loop, boot the Windows installation media and use that to run system restore and restore to the restore point you took, to remove Driver Verifier and get you booting again. Alternatively you can use the Acronis, Macrium Reflect, or similar, boot media to restore the disk image you took.
Please don't skip this step. it's the only way out of a Driver Verifier boot-BSOD loop.
2. Start the Driver Verifier setup dialog by entering the command verifier in either the Run command box or in a command prompt.
3. On that initial dialog, click the radio button for 'Create custom settings (for code developers)' - the second option - and click the Next button.
4. On the second dialog check (click) the checkboxes for the following tests...
- Special Pool
- Force IRQL checking
- Pool Tracking
- Deadlock Detection
- Security Checks
- Miscellaneous Checks
- Power framework delay fuzzing
- DDI compliance checking
Then click the Next button.
5. On the next dialog click the radio button for 'Select driver names from a list' - the last option - and click the Next button.
6. On the next dialog click on the 'Provider' heading, this will sort the drivers on this column (it makes it easier to isolate Microsoft drivers).
7. Now check (click)
ALL drivers that
DO NOT have Microsoft as the provider (ie. check all third-party drivers).
8. Then, on the same dialog, check the following Microsoft drivers (and ONLY these Microsoft drivers)...
- Wdf01000.sys
- ndis.sys
- fltMgr.sys
- Storport.sys
These are high-level Microsoft drivers that manage lower-level third-party drivers that we otherwise wouldn't be able to trap. That's why they're included.
9. Now click Finish and then reboot. Driver Verifiier will be enabled.
Be aware that Driver Verifier will remain enabled across all reboots and shutdowns. It can only be disabled manually.
Also be aware that we expect BSODs. Indeed, we want BSODs, to be able to identify the flaky driver(s). You MUST keep all minidumps created whilst Driver Verifier is running, so disable any disk cleanup tools you may have.
10. Leave Driver Verifier running for 48 hours, use your PC as normal during this time, but do try and make it BSOD. Use every game or app and device that you normally use, and especially those where you have seen it BSOD in the past. If Windows doesn't automatically reboot after each BSOD then just reboot as normal and continue testing.
Note: Because Driver Verifier is doing extra work each time a third-party driver is loaded you will notice some performance degradation with Driver Verifier enabled. This is a price you'll have to pay in order to locate any flaky drivers. And remember, Driver Verifier can only test drivers that are loaded, so you need to ensure that every third-party driver gets loaded by using all apps, features and devices.
11. To turn Driver Verifier off enter the command verifier /reset in either Run command box or a command prompt and reboot.
Should you wish to check whether Driver Verfier is enabled or not, open a command prompt and enter the command verifier /query. If drivers are listed then it's enabled, if no drivers are listed then it's not.
12. When Driver Verifier has been disabled, navigate to the folder C:\Windows\Minidump and locate all .dmp files in there that are related to the period when Driver Verifier was running (check the timestamps). Zip these files up if you like, or not as you choose. Upload the file(s) to the cloud with a link to it/them here (be sure to make it public).
Facebook
Twitter
Instagram