[SOLVED] BSDO "Watchdog Violation"

Feb 3, 2020
17
1
15
Hello,

I keep getting BSOD which says it's a watchdog violation. I tried to search for it and fix it but to no avail.

The problem only happens under heavy load. Working with 3d rendering (gpu based iray rendering). Never during gaming nor anything else.
And most of the time when the scene is full. So maybe Vram or ram issues?

I don't know but what I do know that it is incredibly frustrating to restart mid-work...

Specs:

Cpu: Ryzen 7 3700x
Motherboard : Asrock Taichi x570
BIOS date: 01/03/20 ver:05.0000E V2.80
Ram : 64gb
GPU: rtx 2080ti
PSU: psu corsair rm1000i

I update the GPU with the geforce software and the rest I try to do manually.

I will upload a memory.dmp as soon as possible. Sorry about that!

Mini dmp: Mega Link 217kb
Memory.dmp: Mega Link 833 mb
 
Last edited:
Solution
I have run one of the dump files and you can see the full report(s) in the link below.
If you are prompted to "Run only if trusted" simply click play/run and the html will be viewed. This warning is always present.

Report: https://jsfiddle.net/tcLqmr5u/show

Summary of findings:
DRIVER_VERIFIER_DETECTED_VIOLATION
This bug check can only occur when Driver Verifier has been instructed to monitor one or more drivers. If you did not intend to use Driver Verifier, you should deactivate it. You might also consider removing the driver that caused this problem.

If you are the driver writer, use the information obtained through this bug check to fix the bugs in your code.

For full details on Driver Verifier, see the...
Feb 3, 2020
17
1
15
Feb 3, 2020
17
1
15
I just ran MemTestPro overnight to see if there were any issues with the ram.

https://ibb.co/nCgb78L

Seems like there are no issues with the ram.

Maybe Vram? Or something else?
Hope someone who has experienced something like this can give a helping hand.
 

PC Tailor

Illustrious
Ambassador
I have run the dump file(s) and you can see the full report(s) in the link below.
If you are prompted to "Run only if trusted" simply click play/run and the html will be viewed. This warning is always present.

Report: https://jsfiddle.net/8akrtLjx/show

Summary of findings:
DPC_WATCHDOG_VIOLATION
In general this stop code is caused by faulty driver code that under certain conditions, does not complete its work within the allotted time frame.

  • If a driver is identified in the bug check message, to isolate the issue, disable the driver. Check with the manufacturer for driver updates.
  • Check the System Log in Event Viewer for additional error messages that might help identify the device or driver that is causing bug check 0x133.
  • Confirm that any new hardware that is installed is compatible with the installed version of Windows. For example, you can get information about required hardware at Windows 10 Specifications.

You can see in the stack text the NVIDIA GPU driver (nvlddmkm) was present leading up to the crash:
Code:
nt!KeBugCheckEx
nt!KeAccumulateTicks+0x18cbee
nt!KeClockInterruptNotify+0xbd
nt!HalpTimerClockIpiRoutine+0x1a
nt!KiCallInterruptServiceRoutine+0xa5
nt!KiInterruptSubDispatchNoLockNoEtw+0xfa
nt!KiInterruptDispatchNoLockNoEtw+0x37
nvlddmkm+0x10f899
nvlddmkm+0x12ffed
0xffffe78a`67c4c000

So looking at your GPU driver:
nvlddmkm.sys05/07/2020NVIDIANVIDIA Video Drivers

Some considerations:
  • Did the crashes occur before you updated this driver? If the crashes seemed to have only occurred after this update, I would roll back the driver to the previous version.
  • There is a new BIOS update available for your board which may help: https://www.asrock.com/mb/amd/x570 taichi/#BIOS
  • If you are running any OC / XMP at all, I would disable them until you verify the cause.
  • I'd also be tempted to undo any IOBit changes, anything with a registry cleaner is potentially dangerous.
 
Feb 3, 2020
17
1
15
Thank you for your reply!

1. This crash has been doing so since I first changed into my new motherboard (taichi x570) which is around 5-6 months ago. Just feels like the crash happens more frequently now.

2. The problem with updating bios is... My screens are blank during startup... It only shows up once the login page appears. I have tried different methods. But with that said, I do not think it is a bios issue as I had this issue before I did the update to 2.80

3. No OC or XMP at all as far as I know.

4. The IOBit changes were mostly done due to the errors and not the other way around. But I will still try to see if I can undo them.

Do you think I may have a faulty gpu?
 

PC Tailor

Illustrious
Ambassador
This crash has been doing so since I first changed into my new motherboard (taichi x570) which is around 5-6 months ago. Just feels like the crash happens more frequently now.
So crashes didn't occur before this change?
Did you reinstall Windows when you did this change? (if you didn't, you might need to).
Did you also upgrade CPU?

The problem with updating bios is... My screens are blank during startup... It only shows up once the login page appears. I have tried different methods. But with that said, I do not think it is a bios issue as I had this issue before I did the update to 2.80
Yes but that's what BIOS updates are for, each one can come with better compatibility and performance improvements over the last.

3. No OC or XMP at all as far as I know.
So are you not running your modules at 3200? As they won't run at this speed without manually setting this in the BIOS.

Do you think I may have a faulty gpu?
Can't tell yet, a DPC Watchdog Violation can often be driver related as it's usually when something has been running at too high an IRQL level for a period of time, and is often from faulty drivers, but can be caused by hardware. If we get stuck, we may need to call upon Driver Verifier, which if there is a driver at fault, it should help pull it out - details of this can be found in the BSOD link in my signature below.

We may also be tempted to completely clean NVIDIA drivers using DDU and reinstalling. If not we can look at Driver Verifier potentially: https://www.sysnative.com/forums/threads/driver-verifier-bsod-related-windows-10-8-1-8-7-vista.29/
 
Feb 3, 2020
17
1
15
So crashes didn't occur before this change?
Did you reinstall Windows when you did this change? (if you didn't, you might need to).
Did you also upgrade CPU?


Yes but that's what BIOS updates are for, each one can come with better compatibility and performance improvements over the last.


So are you not running your modules at 3200? As they won't run at this speed without manually setting this in the BIOS.


Can't tell yet, a DPC Watchdog Violation can often be driver related as it's usually when something has been running at too high an IRQL level for a period of time, and is often from faulty drivers, but can be caused by hardware. If we get stuck, we may need to call upon Driver Verifier, which if there is a driver at fault, it should help pull it out - details of this can be found in the BSOD link in my signature below.

We may also be tempted to completely clean NVIDIA drivers using DDU and reinstalling. If not we can look at Driver Verifier potentially: https://www.sysnative.com/forums/threads/driver-verifier-bsod-related-windows-10-8-1-8-7-vista.29/

No, crashes didn't occur before I changed my motherboard.
I installed windows into a new ssd driver because the old one didn't want to boot with the new motherboard.

All the new components were; Motherboard, Cpu and Ram.
I manually set the ram to 3200

Thank you for the clarification on the bios. Will try to update once I figure out the blank screen issue.

Btw, when I installed the new windows into the new ssd, I copy-pasted a lot of old stuff into c:users and documents (from backup file)
Can that mess up stuff?

I am willing to try DDU and inspector etc.
Already created a restore point
 
Feb 3, 2020
17
1
15
Little update;

I tried to do the inspector and it gave me an BSOD loop (happens around the login page phase)
DRIVER_VERIFIER_DETECTED_VIOLATION

Luckily, I could enter via safe boot with network (which I am in currently)
So, I guess this means this is a driver related issue and not hardware?

I have uploaded minidumps of the recent BSOD

Link

I have created a restore point but I think I will try the second option (deleting the gpu drivers) before using the restore point to see if that helps
 

PC Tailor

Illustrious
Ambassador
Well for now I'd potentially consider holding on the Driver Verifier. The paremeter 1 on yours is a 1 which means multiple drivers could be involved. So driver verifier might end up taking some time as it will be drawing out drivers one by one.

I will have a look at the minidumps created as it is, but yeah, hold fire on the Driver Verifier for the moment and go back to your restore point with DV disabled.
 

PC Tailor

Illustrious
Ambassador
I have run one of the dump files and you can see the full report(s) in the link below.
If you are prompted to "Run only if trusted" simply click play/run and the html will be viewed. This warning is always present.

Report: https://jsfiddle.net/tcLqmr5u/show

Summary of findings:
DRIVER_VERIFIER_DETECTED_VIOLATION
This bug check can only occur when Driver Verifier has been instructed to monitor one or more drivers. If you did not intend to use Driver Verifier, you should deactivate it. You might also consider removing the driver that caused this problem.

If you are the driver writer, use the information obtained through this bug check to fix the bugs in your code.

For full details on Driver Verifier, see the Driver Verifier section of the Windows Driver Kit (WDK).

As you can see here at the moment:

BugCheck C4 -----> DRIVER_VERIFIER_DETECTED_VIOLATION
Probably caused by : farflt.sys ( farflt+29b35 )

farflt.sys
is your Malwarebytes Anti-Ransomware Driver

For the time being i would remove Malwarebytes entirely. Another issue may occur, but clearly DV has found this one to be causing some violations currently.
 
Solution
Feb 3, 2020
17
1
15
I have now tried it all.

  1. DDU removing GPU driver and reinstalling as instructed.
  2. Reset the cmos via motherboard button.
  3. Updated the bios to the latest version.
  4. Total uninstallation of malware anti-ransomware

- it still crashed (bsod dpc watch violation) while I was just rendering.
 

PC Tailor

Illustrious
Ambassador
Right so the latest is telling a similar story. And because a 0x133 bugcheck with a parameter 1 = 1 means it can be quite difficult to track down. For this reason, do you have the full kernel dump file available? The minidumps are not shedding more light on this one.
 
Feb 3, 2020
17
1
15
Right so the latest is telling a similar story. And because a 0x133 bugcheck with a parameter 1 = 1 means it can be quite difficult to track down. For this reason, do you have the full kernel dump file available? The minidumps are not shedding more light on this one.

In the main OP I have a full memory.dmp 3gb but download 800mb.
Is that it?
 

PC Tailor

Illustrious
Ambassador
In the main OP I have a full memory.dmp 3gb but download 800mb.
Is that it?
Thats a full kernel dump yes, if it is possible to get these for any dumps that would be useful. I appreciate this is annoying due to their size, but you have a more complex BSOD unfortunately!

Basically you have a bugcheck of 0x133 which means in effect a DPC took too long to process. Now if your BSOD was one particular type of 0x133, then that would usually mean one driver is the culprit, and it will usually be found.

Problem is yours is the other type, which means multiple drivers could be at play. DV has identified MWB potentially causing an issue somewhere, but it might not be the only one or the culprit altogether causing the overall problem.

Thus the bigger dump file is needed. I actually have an expert behind the scenes @axe0axe0 helping massively with this one. I can't take credit!
 
Last edited:
  • Like
Reactions: HopeU
Feb 3, 2020
17
1
15
Thats a full kernel dump yes, if it is possible to get these for any dumps that would be useful. I appreciate this is annoying due to their size, but you have a more complex BSOD unfortunately!

Basically you have a bugcheck of 0x133 which means in effect a DPC took too long to process. Now if your BSOD was one particular type of 0x133, then that would usually mean one driver is the culprit, and it will usually be found.

Problem is yours is the other type, which means multiple drivers could be at play. DV obviously pointed out one of them, but it might not be the only one or the culprit altogether. Thus the bigger dump file is needed. I actually have an expert behind the scenes @axe0axe0 helping massively with this one. I can't take credit!

I very much appreciate the time already invested in helping me with this! To both of you, thank you a lot!

Now to a bit of a stupid question. The big memory.tmp I already have uploaded (first post). Why can't that one be used? Is it because it needs to be from the most recent one?
Most recent big memory.tmp:
Link
 
Feb 3, 2020
17
1
15
  • Like
Reactions: PC Tailor

PC Tailor

Illustrious
Ambassador
Leave DV on for at least 48 hours if possible, even if a few crashes occur, let them all happen and collect the dump files for each one and post them with the Sysnative app which will zip them all together.

Some could theoretically go down testing hardware or any software but at this point it would be like whack a mole and potentially incredibly inefficient and confusing - so I hope you understand these can be difficult to solve. We want to eradicate software from being the cause first.

Thus why it's taking this one step at a time. At this stage, it could be anything and it's discovering the next lot of information and seeing what it tells us.
 
  • Like
Reactions: HopeU
Feb 3, 2020
17
1
15
Here is the latest sysnative collection and mini dumps.
Link

Some things I've noticed since last time;
Since deleting malwarebytes I have drastically lowered the DPC violation.
Went from a few BSOD a day to only 2-3 since last time. And only after a long rendering session.

While verifier was on - Asrock ledrgb software instantly gives the verifier BSOD once clicked. But that may be a security check thing as it play with the bios?

And lastly, I regret to say that I compleley forgot to mention an important detail (I think it's important that is).
I had 4 IDE ATA/ATAPI controllers. When I tried to update them several months ago my computer went on a loop and had to go to safe mood to remove the driver updates. (tried both with iobit driver update and manually.)
Today, I updated them again with Iobit and it worked and in device manager it now shows I only have 2 IDE ATA/ATAPI instead of the 4 that I have had up until now.
Maybe the 4 was the issue as it seems to be from leftover drivers.
For now, I will keep the verifier on and see how it is now after the IDE changes (updates and went from 4 to 2 drivers on device manager)
 

PC Tailor

Illustrious
Ambassador
Hi HopeU apologies for not responding, I've been away and then inundated with work elsewhere. I'm hoping to be able to hop back on soon. Any updates you wanted to provide after the last for us to digest? (I'll pick up on everything you've posted above as soon as I can)!
 
  • Like
Reactions: HopeU