ubuysa
The BSOD Doctor
This dump is dated 8th December 2022, is that from before you replaced the GPU, CPU cooler and PSU (which you did just before Christmas)? If it is prior to the hardware changes then it's going to be of little use unfortunately.
In case it is after the hardware change, this dump has a stop code of 0x133 DPC_WATCHDOG_VIOLATION. DPCs are Deferred Procedure Calls, they are the 'back-end' of interrupt processing.
[TLDR]
When a hardware interrupt is received from a device one of the loigical processors is assigned to handle it. It will save status, identify the device that is interrupting and then run the ISR (Interrupt Service Routine) for that device (it's part of the driver). The ISR must run very quickly because no other work can be done on that logical processor until the ISR has completed. All the ISR does is save the status of the interrupt (ie. whatever the status of the interrupt is; if the result of a read operation for example, then a pointer to the buffer is saved along with the status of the read), and schedule the DPC for that device (also part of the driver). The ISR then terminates and the dispatcher starts another thread on that logical processor.
When a logical processor goes idle (ie. no more work on the ready queue) then the list of scheduled DPCs is executed. A DPC will read the status of the interrupt and decide whether it was successful or not. If a read operation for example, the DPC will notify the thread that started the read and supply a pointer to the buffer where the data can be found. Once one DPC ends then the next in the scheduled list is run, until all DPCs have been executed.
This method of handling interrupts allows for interrupts to be serviced in a timely fashion but without adversely impacting the system throughput.
[/TLDR]
In your dump, argument 1 contains the value 0x1, this indicates that the BSOD happened because the total length of time that all DPCs took to execute exceeded a threshold. Even though DPCs run when a logical processor is idle, they must still run in a timely fashion. The DPC Watchdog checks that all DPCs run within this specified time limit, if this is exceeded then there must be a problem and the system BSODs.
Usually it's a tad tricky to discover which DPC(s) were running for too long, but in your case it's easy, because the long-running DPC is still on the call stack...
The nvlddmkm.sys driver is the Nvidia graphics card driver.
The reason it ran for too long is either because there is a problem with the driver, or because there is a problem with the graphics card (it takes too long to respond to driver instructions for example).
If you've uninstalled all older drivers with DDU and installed the latest driver, and it still BSODs, then I would suggest using DDU again and install then next previous driver. If it still BSODs then try the next previous driver. If it BSODs on the latest three driver versions however then I would think you can discount a driver error.
It could possibly be a Windows issue, but I think that's unlikely. A clean install, as suggested, would eliminate that possibility however.
If it's not a driver issue and it's not a Windows issue then it's a hardware issue - most likely with the graphics card. And since it's a new graphics card I would immediately suspect it. Can you try the original graphics card (remember to use DDU to remove the driver for the 'new' card and install the right driver for the 'old' card) and see whether it still BSODs?
In case it is after the hardware change, this dump has a stop code of 0x133 DPC_WATCHDOG_VIOLATION. DPCs are Deferred Procedure Calls, they are the 'back-end' of interrupt processing.
[TLDR]
When a hardware interrupt is received from a device one of the loigical processors is assigned to handle it. It will save status, identify the device that is interrupting and then run the ISR (Interrupt Service Routine) for that device (it's part of the driver). The ISR must run very quickly because no other work can be done on that logical processor until the ISR has completed. All the ISR does is save the status of the interrupt (ie. whatever the status of the interrupt is; if the result of a read operation for example, then a pointer to the buffer is saved along with the status of the read), and schedule the DPC for that device (also part of the driver). The ISR then terminates and the dispatcher starts another thread on that logical processor.
When a logical processor goes idle (ie. no more work on the ready queue) then the list of scheduled DPCs is executed. A DPC will read the status of the interrupt and decide whether it was successful or not. If a read operation for example, the DPC will notify the thread that started the read and supply a pointer to the buffer where the data can be found. Once one DPC ends then the next in the scheduled list is run, until all DPCs have been executed.
This method of handling interrupts allows for interrupts to be serviced in a timely fashion but without adversely impacting the system throughput.
[/TLDR]
In your dump, argument 1 contains the value 0x1, this indicates that the BSOD happened because the total length of time that all DPCs took to execute exceeded a threshold. Even though DPCs run when a logical processor is idle, they must still run in a timely fashion. The DPC Watchdog checks that all DPCs run within this specified time limit, if this is exceeded then there must be a problem and the system BSODs.
Usually it's a tad tricky to discover which DPC(s) were running for too long, but in your case it's easy, because the long-running DPC is still on the call stack...
Code:
0: kd> knL
# Child-SP RetAddr Call Site
00 fffff807`734a1e18 fffff807`6fc5bf02 nt!KeBugCheckEx
01 fffff807`734a1e20 fffff807`6fad2973 nt!KeAccumulateTicks+0x186d32
02 fffff807`734a1e80 fffff807`6fad245a nt!KeClockInterruptNotify+0x453
03 fffff807`734a1f30 fffff807`6fa08a45 nt!HalpTimerClockIpiRoutine+0x1a
04 fffff807`734a1f60 fffff807`6fbfb26a nt!KiCallInterruptServiceRoutine+0xa5
05 fffff807`734a1fb0 fffff807`6fbfba37 nt!KiInterruptSubDispatchNoLockNoEtw+0xfa
06 fffff807`7349a170 fffff807`6fabb8ab nt!KiInterruptDispatchNoLockNoEtw+0x37
07 fffff807`7349a300 fffff807`87f7b9e3 nt!KzLowerIrql+0x1b
08 fffff807`7349a330 fffff807`7349a3f0 nvlddmkm+0xab9e3
09 fffff807`7349a338 00000000`00000010 0xfffff807`7349a3f0
0a fffff807`7349a340 ffff7475`16c9befb 0x10
0b fffff807`7349a348 fffff807`87f62c5d 0xffff7475`16c9befb
0c fffff807`7349a350 00000000`00000000 nvlddmkm+0x92c5dThe reason it ran for too long is either because there is a problem with the driver, or because there is a problem with the graphics card (it takes too long to respond to driver instructions for example).
If you've uninstalled all older drivers with DDU and installed the latest driver, and it still BSODs, then I would suggest using DDU again and install then next previous driver. If it still BSODs then try the next previous driver. If it BSODs on the latest three driver versions however then I would think you can discount a driver error.
It could possibly be a Windows issue, but I think that's unlikely. A clean install, as suggested, would eliminate that possibility however.
If it's not a driver issue and it's not a Windows issue then it's a hardware issue - most likely with the graphics card. And since it's a new graphics card I would immediately suspect it. Can you try the original graphics card (remember to use DDU to remove the driver for the 'new' card and install the right driver for the 'old' card) and see whether it still BSODs?
