BSOD Windows 10 build 1703 and 1709

Could you upload the kernel dump, in C:\Windows\MEMORY.dmp, to onedrive, google drive or dropbox and post a share link.
This one's a bit of an exceptional BSOD, although I've seen it quite often lately, there's not much of documentation online for proper troubleshooting this one so I'm wanting to make one.

Determining the cause of a stop 0x133 with a first parameter of 1 is a bit more difficult because the problem is a result of DPCs running from multiple drivers, so the call stack is insufficient to determine the culprit.

Source: Determining the source of Bug Check 0x133 (DPC_WATCHDOG_VIOLATION) errors on Windows Server 2012 Ntdebugging Blog

Code:

*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 133, {1, 1e00, fffff8004445f348, 0}

*** WARNING: Unable to verify timestamp for nvlddmkm.sys
*** ERROR: Module load completed but symbols could not be loaded for nvlddmkm.sys
Probably caused by : nvlddmkm.sys ( nvlddmkm+28df18 )

It requires a kernel dump to properly troubleshoot it, mainly due to lack of information that is saved in the minidump, not because of corruption.
We need to know what DPC's / ISR's were running and which of them offended the DPC duration limit.

Code:

0: kd> !dpcs
Cannot find the DPC Queue Information. This extension may not work on early builds.
0: kd> !irql
nt!_KPRCB.DebuggerSavedIRQL not found, error : 0x3.
0: kd> !pcr
Unable to read the PCR at fffff780ffff0000

Too bad

AliasOfMyself said:

Any idea why one wasn't created? i couldn't find any info that applies to me, i have enough space on the windows drive, the pagefile is big enough too, i don't understand lol. this system is a royal pain in the you know what!

Corruption.
The system uses

• dump_*.sys drivers, used to write the data to dump,
• information collected from components
  
  • the name of the disk miniport driver
  • IO Manager structures that are needed for the process

to create dumps.


Copies of this information is stored in dump-context structures when you boot, the information is validated by a memory comparision. If it doesn't match no dump can be written.

You can run chkdsk, sfc and ram test, but much more can't be done using software.