I rather suspect this is either a flaky graphics card or a badly seated graphics card. As
@zbook says, many of those bugcheck codes are graphics card related, but the two dumps you uploaded are the most interesting. They are both 0x113 bugchecks - and that's rare...
Code:
VIDEO_DXGKRNL_FATAL_ERROR (113)
The dxgkrnl has detected that a violation has occurred. This resulted
in a condition that dxgkrnl can no longer progress. By crashing, dxgkrnl
is attempting to get enough information into the minidump such that somebody
can pinpoint the crash cause. Any other values after parameter 1 must be
individually examined according to the subtype.
Arguments:
Arg1: 0000000000000019, The subtype of the bugcheck:
Arg2: 0000000000000001
Arg3: 00000000000010de
Arg4: 0000000000002208
The argument values here aren't documented anywhere, but arguments 3 and 4 are the
VEN and DEV identifiers for the failing device - they point at the RTX 3080Ti graphics card. We could have suspected that of course, given the bugcheck code.
If we examine the call parameters on the calls stack we can see exactly what went wrong...
Code:
15: kd> !spack -p
No export spack found
15: kd> !stack -p
Call Stack : 12 frames
## Stack-Pointer Return-Address Call-Site
00 ffffa98d3ef1f1e8 fffff80684175685 nt!KeBugCheckEx+0
Parameter[0] = 0000000000000113
Parameter[1] = 0000000000000019
Parameter[2] = 0000000000000001
Parameter[3] = 00000000000010de
01 ffffa98d3ef1f1f0 fffff8068407a41c watchdog!WdLogSingleEntry5+3b45 (perf)
Parameter[0] = 0000000000000000
Parameter[1] = 0000000000000013
Parameter[2] = (unknown)
Parameter[3] = (unknown)
02 ffffa98d3ef1f2a0 fffff80683f03f84 dxgkrnl!DpiFdoHandleSurpriseRemoval+15c
Parameter[0] = ffff868c3e197030
Parameter[1] = ffff868c51a3aaa0
Parameter[2] = (unknown)
Parameter[3] = (unknown)
03 ffffa98d3ef1f2f0 fffff80683e80bc9 dxgkrnl!DpiFdoDispatchPnp+d4
Parameter[0] = ffff868c3e197030
Parameter[1] = ffff868c51a3aaa0
Parameter[2] = (unknown)
Parameter[3] = (unknown)
04 ffffa98d3ef1f390 fffff806978d4acc dxgkrnl!DpiDispatchPnp+e9
Parameter[0] = ffff868c3e197030
Parameter[1] = ffff868c51a3aaa0
Parameter[2] = (unknown)
Parameter[3] = (unknown)
05 ffffa98d3ef1f4b0 ffff868c3e402000 nvlddmkm+1094acc (leaf)
Parameter[0] = (unknown)
Parameter[1] = (unknown)
Parameter[2] = (unknown)
Parameter[3] = (unknown)
Notice the dxgkrnl!DpiFdoHandleSurpriseRemoval function call, there's a clue there in that a graphics card should never be surprise removed. Parameter 0 here is the device object, and parameter 1 is the IRP address.
Displaying the device object shows that the graphics driver nvlddmklm.sys was accessing the device - as we might expect, but this all confirms that this is a graphics problem (this also shows the driver object address which we will need later)...
Code:
15: kd> !devobj ffff868c3e197030
Device object (ffff868c3e197030) is for:
InfoMask field not found for _OBJECT_HEADER at ffff868c3e197000
\Driver\nvlddmkm DriverObject ffff868c3e0e4530
Current Irp 00000000 RefCount 0 Type 00000023 Flags 00002004
SecurityDescriptor ffff988cec9fbae0 DevExt ffff868c3e197180 DevObjExt ffff868c3e1987f8
ExtensionFlags (0000000000)
Characteristics (0x00000100) FILE_DEVICE_SECURE_OPEN
AttachedTo (Lower) ffff868c35518d30 Name paged out
Device queue is not busy.
Displaying the IRP address we clearly see that 'surprise removal' of the card was the problem here...
Code:
15: kd> !irp ffff868c51a3aaa0
Irp is active with 3 stacks 3 is current (= 0xffff868c51a3ac00)
No Mdl: No System Buffer: Thread ffff868c4f321040: Irp stack trace.
cmd flg cl Device File Completion-Context
[N/A(0), N/A(0)]
0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[N/A(0), N/A(0)]
0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
>[IRP_MJ_PNP(1b), IRP_MN_SURPRISE_REMOVAL(17)]
0 0 ffff868c3e197030 00000000 00000000-00000000
\Driver\nvlddmkm
Args: 00000000 00000000 00000000 00000000
Notice the IRP_MJ_PNP(1b) prefix to the IRP_MN_SURPRISE_REMOVAL text? That's the graphics driver routine that will be called if the card is surprise removed. If we use the driver object address (from the device object output above) we can see what address that surprise removal routine is at...
Code:
15: kd> !drvobj ffff868c3e0e4530 7
fffff8067423ff78: Unable to get value of ObpRootDirectoryObject
fffff8067423ff78: Unable to get value of ObpRootDirectoryObject
Driver object (ffff868c3e0e4530) is for:
\Driver\nvlddmkm
Driver Extension List: (id , addr)
Couldn't read extension at 0xffff868c3e1e98f0
Device Object list:
ffff868c4901f9f0 ffff868c4b15dc90 ffff868c4b232d10: Could not read device object
DriverEntry: fffff8069a190b60 nvlddmkm
DriverStartIo: 00000000
DriverUnload: fffff806978d6110 nvlddmkm
AddDevice: fffff806978d3d10 nvlddmkm
Dispatch routines:
[00] IRP_MJ_CREATE fffff806978d41b0 nvlddmkm+0x10941b0
[01] IRP_MJ_CREATE_NAMED_PIPE fffff806978d41b0 nvlddmkm+0x10941b0
[02] IRP_MJ_CLOSE fffff806978d41b0 nvlddmkm+0x10941b0
[03] IRP_MJ_READ fffff806978d41b0 nvlddmkm+0x10941b0
[04] IRP_MJ_WRITE fffff806978d41b0 nvlddmkm+0x10941b0
[05] IRP_MJ_QUERY_INFORMATION fffff806978d41b0 nvlddmkm+0x10941b0
[06] IRP_MJ_SET_INFORMATION fffff806978d41b0 nvlddmkm+0x10941b0
[07] IRP_MJ_QUERY_EA fffff806978d41b0 nvlddmkm+0x10941b0
[08] IRP_MJ_SET_EA fffff806978d41b0 nvlddmkm+0x10941b0
[09] IRP_MJ_FLUSH_BUFFERS fffff806978d41b0 nvlddmkm+0x10941b0
[0a] IRP_MJ_QUERY_VOLUME_INFORMATION fffff806978d41b0 nvlddmkm+0x10941b0
[0b] IRP_MJ_SET_VOLUME_INFORMATION fffff806978d41b0 nvlddmkm+0x10941b0
[0c] IRP_MJ_DIRECTORY_CONTROL fffff806978d41b0 nvlddmkm+0x10941b0
[0d] IRP_MJ_FILE_SYSTEM_CONTROL fffff806978d41b0 nvlddmkm+0x10941b0
[0e] IRP_MJ_DEVICE_CONTROL fffff806978d41b0 nvlddmkm+0x10941b0
[0f] IRP_MJ_INTERNAL_DEVICE_CONTROL fffff806978d41b0 nvlddmkm+0x10941b0
[10] IRP_MJ_SHUTDOWN fffff806978d41b0 nvlddmkm+0x10941b0
[11] IRP_MJ_LOCK_CONTROL fffff806978d41b0 nvlddmkm+0x10941b0
[12] IRP_MJ_CLEANUP 00000000
[13] IRP_MJ_CREATE_MAILSLOT 00000000
[14] IRP_MJ_QUERY_SECURITY 00000000
[15] IRP_MJ_SET_SECURITY 00000000
[16] IRP_MJ_POWER 00000000
[17] IRP_MJ_SYSTEM_CONTROL 00000000
[18] IRP_MJ_DEVICE_CHANGE 00000000
[19] IRP_MJ_QUERY_QUOTA 00000000
[1a] IRP_MJ_SET_QUOTA 00000000
[1b] IRP_MJ_PNP 00000000
The IRP_MJ_PNP function is right at the end of that list of functions, and you'll note there is no address or driver listed. That's because the graphics driver doesn't have a surprise removal routine - because the graphics card should never be surprise removed! This is why you got the 0x113 bugcheck. When the kernel detected the surprise removal of the graphics card and looked up the driver object to find the address of a driver routine to handle that, it found only zeros. That caused the kernel to BSOD with a 0x113 bugcheck code.
The question of course is , why did the kernel detect a surprise removal of the graphics card? It may simply need re-seating, so I'd suggest you remove and reinsert it fully. If you have another suitable PCIe slot then try it in the other slot. Also make sure any extra power cables are properly connected at both ends.
If re-seating doesn't work then I'd strongly suspect that the graphics card itself is flaky. In which case I suggest you print this, take it back to your builder, and ask for a replacement graphics card. If that BSODs too then it may well be the motherboard slots(s).
drive.google.com
