Question "DPC Watchdog Violation" BSOD, and no dump files are created ?

[BrotherJay]

I built this system around Jan 2022 and these BSOD's have been happening at random since day 1. BSOD's happen at completely random times. Could be under heavy load or sitting at desktop in more or less Idle. BSOD is always a DPC Watchdog Violation. It always hangs at 0% and waits for me to do the reboot. System creates no dump files no matter what I have the system set to in that regard.

SPEC
- Gigabyte X570 Aorus Elite Wifi
- Ryzen 9 5900x
- Noctua NH-D15 Cooler
- 970 EVO Plus NVMe M.2 SSD, 1TB (all other drives removed during troubleshooting - made no difference)
- 2x Crucial Ballistix BL16G36C16U4R 16GB 3600MHz DDR4 CL16
- Sapphire Nitro 7900 xtx (just installed 2 days ago - Same BSOD since install as on previous GTX 1080)
- Corsair HX 1000 PSU

This machine was a mix of old system and new as it is the only way I can absorb the cost of upgrades.
Motherboard and CPU came as a bundle (purchased new for this build)
memory (purchased new for this build)
cpu cooler (purchased new for this build)
m.2 drive (purchased new for this build)
GTX 1080 (old system)
Many other drives (old system)
Hardware Replaced During troubleshooting:
Old PSU Corsair 650 was recently replaced with Corsaid HX 1000
GTX 1080 was just replaced with 7900 xtx

Steps Taken,

• set bios to factory settings with no overclock of any kind
• windows fully updated
• Performed system file checker scan now command on cmd. Did find corrupted files and corrected but still having BSoD after.
• bios check of all hardware and updated where applicable
• memory sticks swapped with each other
• All drives except boot drive removed
• RAM tested with free version of memtest86 - ran multiple times to stress it as much as I could, no issues found
• tested boot drive, no issues found
• tested CPU with Cinebech and several other tools furmark and several others
• GPU tested extensively, no issues found
• complete re-install of windows
• used driver easy to identify out of date drivers system wide and update to current versions
• updated system drivers with all the most current stuff Gigabyte had for me to download

I have a gut feeling this is Realtek related, but have obviously not been able to fix this.

For years I have seen countless people come here looking for help and often walking away with problems solved. I figured at least one of those many people with seemingly the same problem, at least one of their solutions MUST be the one to fix me up.

I now come before you all, hat in hand begging for your help. Whatever you need me to do I will try to do; Whatever questions you ask I will try to the best of my ability to answer.

Smart people of Tom's Hardware, you are my only hope.

 

[Ralston18]

Look for error codes, warnings, and even informational events that may be being captured just before or at the time of the BSODs.

Two tools to start with: Reliability History/Monitor and Event Viewer.

Reliability History/Monitor is end user friendly and provides a time line format that may reveal some pattern.

Event Viewer requires more time and effort to navigate and understand.

To help with Event Viewer:

How To - How to use Windows 10 Event Viewer | Tom's Hardware Forum (tomshardware.com)

Just take your time to explore and get a sense of both tools. No need to rush or jump to any immediate conclusions.

Focus on the errors being captured and note the error codes.

One immediate question: when the PSU was replaced were only the cables that came with the replacement Corsair HX 1000 used?

 

[BrotherJay]

One immediate question: when the PSU was replaced were only the cables that came with the replacement Corsair HX 1000 used?

All cables in use with the HX 1000 came with the HX 1000. I don't ever mix my PSU cables.

I have some time off Thursday so I will give Reliability a go and see what language it translates my errors into Might get messy as Event viewer is showing that I had over 400 errors in the last 24 hours alone.

 

[ubuysa]

Firstly, we need memory dumps to be able to pin this down with any certainty. To write dumps all of the following MUST be true...

• The page file must be on the same drive as your operating system
• Set page file to "system managed"
• Set system crash/recovery options to "Automatic memory dump"
• Windows Error Reporting (WER) system service should be set to MANUAL
• User account control must be running

In addition, the following can also prevent you writing dumps...

• SSD drives with older firmware do not create dumps (update the drive firmware)
• Cleaner applications like Ccleaner delete dump files, so don't run them until you are fixed
• Bad RAM may prevent the data from being saved and written to a file on reboot, so if all else fails test your RAM

Secondly, the 0x133 bugcheck (DPC_WATCHDOG_VIOLATION) is driver or device related. It happens when either the ISR or DPC code (both of which are in the device driver) runs for longer than allowed. This is either due to a bad driver - so check that all device drivers are up to date - or because the device itself is bad - pop all PCIe cards out and re-seat them properly. Also disconnect all external devices (except mouse, keyboard, and monitor) and see whether it still BSODs.

 

[BrotherJay]

Firstly, we need memory dumps to be able to pin this down with any certainty. To write dumps all of the following MUST be true...

• The page file must be on the same drive as your operating system
• Set page file to "system managed"
• Set system crash/recovery options to "Automatic memory dump"
• Windows Error Reporting (WER) system service should be set to MANUAL
• User account control must be running

In addition, the following can also prevent you writing dumps...

• SSD drives with older firmware do not create dumps (update the drive firmware)
• Cleaner applications like Ccleaner delete dump files, so don't run them until you are fixed
• Bad RAM may prevent the data from being saved and written to a file on reboot, so if all else fails test your RAM

Secondly, the 0x133 bugcheck (DPC_WATCHDOG_VIOLATION) is driver or device related. It happens when either the ISR or DPC code (both of which are in the device driver) runs for longer than allowed. This is either due to a bad driver - so check that all device drivers are up to date - or because the device itself is bad - pop all PCIe cards out and re-seat them properly. Also disconnect all external devices (except mouse, keyboard, and monitor) and see whether it still BSODs.

- Discovered windows error reporting service was set to Manual, but was not running. It now is.
- User account control is set to it's default (1 notch below always notify ( is this set correctly ? )

 

[BrotherJay]

Seems I have lost the ability to just add this post as an edit to my last.

Waiting for my next BSOD at this time so we can move forward. Can take as little as a few minutes, or up to a month for it to happen, so let the waiting game begin.

Sorry if double posting is a violation of the rules here, I just didn't want anyone to think I had just vanished after getting the help I received thus far.

 

[ubuysa]

Don't worry, posts are not removed and we always respond no matter how long it's been.

 

[BrotherJay]

Good to know.

Update: Just got a BSOD DPC Watchdog...

Sadly, it seems turning the error reporting service on did not let windows create a dump. Just sat there on the blue screen at 0%

So... where do I go from here?

 

[ubuysa]

Is there a file called C:\Windows\Memory.dmo with a recent timestamp? Is so then upload it to a cloud service with a link to it here.

If that file doesn't exist then you really aren't writing dumps. If you checked all of the items in my post #4 then I would start to suspect RAM and/or your system drive...

Use Samsung Magician to test your system drive

Test your RAM by doing the following....

1. Download Memtest86 (free), use the imageUSB.exe tool extracted from the download to make a bootable USB drive containing Memtest86 (1GB is plenty big enough). Do this on a different PC if you can, because you can't fully trust yours at the moment.
2. Then boot that USB drive on your PC, Memtest86 will start running as soon as it boots.
3. If no errors have been found after the four iterations of the 13 different tests that the free version does, then restart Memtest86 and do another four iterations. Even a single bit error is a failure.

 

[BrotherJay]

Is there a file called C:\Windows\Memory.dmo with a recent timestamp? Is so then upload it to a cloud service with a link to it here.

If that file doesn't exist then you really aren't writing dumps. If you checked all of the items in my post #4 then I would start to suspect RAM and/or your system drive...

Use Samsung Magician to test your system drive

Test your RAM by doing the following....

1. Download Memtest86 (free), use the imageUSB.exe tool extracted from the download to make a bootable USB drive containing Memtest86 (1GB is plenty big enough). Do this on a different PC if you can, because you can't fully trust yours at the moment.
2. Then boot that USB drive on your PC, Memtest86 will start running as soon as it boots.
3. If no errors have been found after the four iterations of the 13 different tests that the free version does, then restart Memtest86 and do another four iterations. Even a single bit error is a failure.

Windows has not created any Memory.dmp files ever, so sadly there is nothing to upload.
Samsung Magician - Diagnostic Scan - Full Scan = No Errors

Will test the memory when I get home from work tonight. Unfortunately there is no other PC for me to test this memory on.

 

[BrotherJay]

Memtest86 (free) has been run 3 times for a total of 12 passes = no errors

 

[BrotherJay]

Could a UPS be causing all this? I am running an APC Back-UPS ES 750.

Just found the datasheet for it

Main Input Voltage 120 V
Main Output Voltage 120 V
Kw Rating 450 W
Rated Power In Va 750 VA

 

[ubuysa]

Well something is very wrong if you're not writing dumps, but lets look at some other troubleshooting data. Can you please download and run the SysnativeBSODCollectionApp and upload the resulting zip file to a cloud service with a link to it here. The SysnativeBSODCollectionApp collects all the troubleshooting data we're likely to need. It DOES NOT collect any personally identifying data. It's used by several highly respected Windows help forums (including this one). I'm a senior BSOD analyst on the Sysnative forum where this tool came from, so I know it to be safe.

You can of course look at what's in the zip file before you upload it, most of the files are txt files. Please don't change or delete anything though. If you want a description of what each file contains you'll find that here.

 

[BrotherJay]

It timed out while trying to collect services so it skipped that one and one other thing as well.

Here is the file it created.

https://www.dropbox.com/scl/fi/y8rl...ey=85ixx5temccipw1xueji3g8lu&st=hiz4i2jn&dl=0

 

[ubuysa]

Sadly the logs in that upload are only for two days. It's never wise to clear logs, they contain a lot of useful history. However, reading between the lines I now think you should look more closely at your system drive; the Samsung 970 Pro NVMe drive. A problem with this drive would aso explain why no dumps are being written.

We can see only one crash in these logs but the 'dump not written' error identifies HarddiskVolume2 as the problem drive. Dumps are written to the paging file initially and so this must be your system drive (I've already checked that your paging file is on your system drive)...

Log Name:      System
Source:        volmgr
Date:          26/04/2024 08:08:00
Event ID:      161
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      DESKTOP-911USV4
Description:
Dump file creation failed due to error during dump creation.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="volmgr" />
    <EventID Qualifiers="49156">161</EventID>
    <Version>0</Version>
    <Level>2</Level>
    <Task>0</Task>
    <Opcode>0</Opcode>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2024-04-26T05:08:00.3311831Z" />
    <EventRecordID>85398</EventRecordID>
    <Correlation />
    <Execution ProcessID="4" ThreadID="240" />
    <Channel>System</Channel>
    <Computer>DESKTOP-911USV4</Computer>
    <Security />
  </System>
  <EventData>
    <Data>\Device\HarddiskVolume2</Data>
    <Binary>000000000100000000000000A10004C042000400010000C000000000000000000000000000000000</Binary>
  </EventData>
</Event>

In addition, just prior to the crash, there is an informational message indicating a potential, though not serious, issue with the system drive...

Log Name:      System
Source:        secnvme
Date:          26/04/2024 08:07:58
Event ID:      11
Task Category: None
Level:         Information
Keywords:      Classic
User:          N/A
Computer:      DESKTOP-911USV4
Description:
The description for Event ID 11 from source secnvme cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.

If the event originated on another computer, the display information had to be saved with the event.

The following information was included with the event:

\Device\RaidPort2
144d
Samsung SSD 970 EVO Plus 1TB

The message resource is present but the message was not found in the message table

Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="secnvme" />
    <EventID Qualifiers="16385">11</EventID>
    <Version>0</Version>
    <Level>4</Level>
    <Task>0</Task>
    <Opcode>0</Opcode>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2024-04-26T05:07:58.4341807Z" />
    <EventRecordID>85394</EventRecordID>
    <Correlation />
    <Execution ProcessID="4" ThreadID="312" />
    <Channel>System</Channel>
    <Computer>DESKTOP-911USV4</Computer>
    <Security />
  </System>
  <EventData>
    <Data>\Device\RaidPort2</Data>
    <Data>144d</Data>
    <Data>Samsung SSD 970 EVO Plus 1TB</Data>
    <Binary>0F00200003004800000000000B00014000000000000000000000000000000000000000000000000001000000200000000B0001400000000000000000000000000000000000000000</Binary>
  </EventData>
</Event>

The 0x144d mentioned in there is the VEN identifier for Samsung and the 'provider name' of ssecnvme is the Windows secnvme.sys NVMe driver, so this is definitely a system drive issue because that's your only NVMe drive. I would download Samsung Magician and display the SMART data for that drive. Also run the maximal diagnostic you can, and check for firmware updates for the drive.

In addition to the above, a scan of your drivers shows that you have Avast! installed. Without a dump there's no way to know whether Avast! is involved, but these BSODs could very well be cause by Avast!. All third-party anti-malware products caused BSODs often across a range of PCs. As a test, even temporarily, please uninstall Avast! using the specialised tool at
https://www.avast.com/uninstall-utility#pc.

 

[BrotherJay]

Steps continue as per your suggestions.

- Avast! - Uninstalled using the uninstall app at the link you provided
- Re-ran all tests including S.M.A.R.T. from within Samsung Magician - all came back clean - S.M.A.R.T. logs provided at the link below

https://www.dropbox.com/scl/fi/fr2h...ey=7gliqhdqsy5ojsfjhbti636el&st=twkuhpwl&dl=0

Had a BSOD last night while I slept and my PC was doing nothing. Still stuck at 0% when I awoke to find it.

- Re-ran SysnativeBSODCollectionApp - it would not complete after a 30 minute run.
- Re-booted system and attempted SysnativeBSODCollectionApp again - completed this time, link below to it's latest results.

https://www.dropbox.com/scl/fi/t14h...ey=xrw9s2f7fiyca6lf46mkdu8or&st=fdwd1a98&dl=0

 

[ubuysa]

Having trawled through your logs, which only go back to 25th April for some reason, I know why you're not writing dumps. It's because you've had no BSODs. A BSOD always writes a log entry and there are none. That means that these crashes are almost certainly hardware related. When the hardware fails there often is no BSOD because Windows wasn't able to catch the error - the hardware just failed underneath it.

There are also two WHEA fatal hardware errors reported in the log, and they are different. One contains very little information that enables us to identify the hardware that failed...

Log Name:      System
Source:        Microsoft-Windows-WHEA-Logger
Date:          30/04/2024 07:38:28
Event ID:      1
Task Category: None
Level:         Error
Keywords:      WHEA Error Event Logs
User:          LOCAL SERVICE
Computer:      DESKTOP-911USV4
Description:
A fatal hardware error has occurred. A record describing the condition is contained in the data section of this event.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-WHEA-Logger" Guid="{c26c4f3c-3f66-4e99-8f8a-39405cfed220}" />
    <EventID>1</EventID>
    <Version>0</Version>
    <Level>2</Level>
    <Task>0</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8000000000000002</Keywords>
    <TimeCreated SystemTime="2024-04-30T04:38:28.0782985Z" />
    <EventRecordID>86002</EventRecordID>
    <Correlation ActivityID="{4a806e43-336d-4b18-a880-8ceca63beb93}" />
    <Execution ProcessID="4728" ThreadID="11088" />
    <Channel>System</Channel>
    <Computer>DESKTOP-911USV4</Computer>
    <Security UserID="S-1-5-19" />
  </System>
  <EventData>
    <Data Name="Length">462</Data>
    <Data Name="RawData">435045521002FFFFFFFF01000100000007000000CE0100001B2604001E0418143C60C1835215A74887D114D9467D7765000000000000000000000000000000008D7C2157665EFB4480339B74CACEDF5B03F83300702E884E992C6F26DAF3DB7A3709DD42C598DA01080000000000000000000000000000000000000000000000C8000000060100000003020001000000000000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000053544F52504F525401000601A4000000010003000B0000005D177E5E3847BF4317B7353B2D01DBD5730074006F00720061006800630069000000000000000000000000000000000057444320202020200057443430455A415A2D3139534633423000A4000000A40000007DE05002000000001600000000010000AD07000000000000000000000000000000000000640000000000000000000000000000000000000032000000FFFFFFFF0000000000000000000000000000200001000000000000000000000000000000010000000000000032000000000000006500000064000000000000000000000000000000000000003200000032000000000000000000000097000000</Data>
  </EventData>
</Event>

There really isn't anything there that we can interpret to identify the component.

The other WHEA fatal hardware error however is different...

Log Name:      System
Source:        Microsoft-Windows-WHEA-Logger
Date:          27/04/2024 09:40:33
Event ID:      18
Task Category: None
Level:         Error
Keywords:  
User:          LOCAL SERVICE
Computer:      DESKTOP-911USV4
Description:
A fatal hardware error has occurred.

Reported by component: Processor Core
Error Source: Machine Check Exception
Error Type: Cache Hierarchy Error
Processor APIC ID: 9

The details view of this entry contains further information.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-WHEA-Logger" Guid="{c26c4f3c-3f66-4e99-8f8a-39405cfed220}" />
    <EventID>18</EventID>
    <Version>0</Version>
    <Level>2</Level>
    <Task>0</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8000000000000000</Keywords>
    <TimeCreated SystemTime="2024-04-27T06:40:33.0966153Z" />
    <EventRecordID>85587</EventRecordID>
    <Correlation ActivityID="{ce50f968-1387-4651-bbec-f794fdaa4c6e}" />
    <Execution ProcessID="5424" ThreadID="6776" />
    <Channel>System</Channel>
    <Computer>DESKTOP-911USV4</Computer>
    <Security UserID="S-1-5-19" />
  </System>
  <EventData>
    <Data Name="ErrorSource">3</Data>
    <Data Name="ApicId">9</Data>
    <Data Name="MCABank">5</Data>
    <Data Name="MciStat">0xbea0000001000108</Data>
    <Data Name="MciAddr">0x7ff77953d6e7</Data>
    <Data Name="MciMisc">0xd01a0ffe00000000</Data>
    <Data Name="ErrorType">9</Data>
    <Data Name="TransactionType">2</Data>
    <Data Name="Participation">256</Data>
    <Data Name="RequestType">0</Data>
    <Data Name="MemorIO">256</Data>
    <Data Name="MemHierarchyLvl">0</Data>
    <Data Name="Timeout">256</Data>
    <Data Name="OperationType">256</Data>
    <Data Name="Channel">256</Data>
    <Data Name="Length">936</Data>
    <Data Name="RawData">435045521002FFFFFFFF03000100000002000000A80300000D2806001B0418140000000000000000000000000000000000000000000000000000000000000000BDC407CF89B7184EB3C41F732CB57131FE6FF5E89C91C54CBA8865ABE14913BB08F743BF6D98DA0102000000000000000000000000000000000000000000000058010000C00000000003000001000000ADCC7698B447DB4BB65E16F193C4F3DB0000000000000000000000000000000001000000000000000000000000000000000000000000000018020000800000000003000000000000B0A03EDC44A19747B95B53FA242B6E1D0000000000000000000000000000000001000000000000000000000000000000000000000000000098020000100100000003000000000000011D1E8AF94257459C33565E5CC3F7E8000000000000000000000000000000000100000000000000000000000000000000000000000000007F010000000000000002010000000000100FA2000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000900000000000000000000000000000000000000000000000000000000000000000000000000000007000000000000000900000000000000100FA200000818090B32F87EFFFB8B170000000000000000000000000000000000000000000000000000000000000000F50157A5EFE3DE43AC72249B573FAD2C03000000000000009F00020600000000E7D65379F77F0000000000000000000000000000000000000000000000000000020000000200000057C804C26D98DA01090000000000000000000000000000000000000005000000080100010000A0BEE7D65379F77F000000000000FE0F1AD0000000000900000000000000B00005000000004D00000000F9010000230000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003B00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000</Data>
  </EventData>
</Event>

You can see that this was a machine check exception detected by the processor and was for a Cache Hierarchy Error. This can refer both to the processor cache (meaning it was a CPU fault) or to the RAM feeding the processor cache (meaning it was a RAM fault). I'm not able to interpret the remaining event data, I suspect it requires access to Microsoft information that we can't get hold of.

That second WHEA error strongly suggests that this is a hardware issue related either to the CPU or RAM. I checked the QVL for your board and the RAM is on there, so it's compatible with the board and with the CPU. The RAM is in the correct slots according to the motherboard manual I trust?

I suggest that you now stress test the CPU with Prime95, but this will make the CPU run hot, so also run a temperature monitor (CoreTemp is good and pretty lightweight, but HWMonitor (free) would be better). Download Prime95 and run it. Run each of the three tests one after another, and run each test for a minimum of 1 hour, but if the temps are acceptable run each test for 2 hours.

The smallFFTs test stresses the CPU the most, so if you have a flaky CPU this is probably the test that will fail. The largeFFTs test stresses RAM the most, so if this test fails it's probably a RAM issue. The Blend tests stresses both roughly the same (it's a mixture of smallFFTs and largeFFTs).

If Prime95 generates error messages, if the system crashes or BSODs, or if the CPU temp gets close to 90°C (the max operating temp for your CPU) then stop Prime95 and let us know what happened.

 

[BrotherJay]

Confirmed that memory is in the correct slots = A2 & B2

- Ran Prime95 for 2 hours with smallFFT's = No errors = Max recorded CPU temp was 65c
- Ran Prime95 for 2 hours with largeFFT's = No errors
- Ran Prime95 for 2 hours with Blend = No errors

 

[ubuysa]

OK, then it's time to look for a rogue driver as the cause and that means running Driver Verifier...

Driver Verifier subjects selected drivers (typically all third-party drivers) to extra tests and checks every time they are called. These extra checks are designed to uncover drivers that are misbehaving. If any selected driver fails any of the Driver Verifier tests/checks then Driver Verifier will BSOD. The resulting minidump should contain enough information for us to identify the flaky driver. It's thus essential to keep all minidumps created whilst Driver Verifier is enabled.

To enable Driver Verifier do the following:

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 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. The Driver Verifier generated BSODs are these...

• 0xC1: SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION
• 0xC4: DRIVER_VERIFIER_DETECTED_VIOLATION
• 0xC6: DRIVER_CAUGHT_MODIFYING_FREED_POOL
• 0xC9: DRIVER_VERIFIER_IOMANAGER_VIOLATION
• 0xD6: DRIVER_PAGE_FAULT_BEYOND_END_OF_ALLOCATION
• 0xE6: DRIVER_VERIFIER_DMA_VIOLATION

If you see any of these BSOD types then you can disable Driver Verifier early because you'll have caught a misbehaving driver.

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).

 

[BrotherJay]

Planning on doing this on Thursday since it is my day off and will give me the chance to respond to whatever comes my way, but before this happens I do have a request.

Ever since I went looking for the answers to my systems problems 2 years ago I have stumbled onto countless threads about Driver Verifier and a great many of them have put the fear of god into me over the program. I know that a decent number of those are from people who did not have a recovery plan in place for a possible boot BSOD loop.

I have my Win 10 Installation media USB stick, freshly created so I know the USB stick is healthy.

I have created my system recovery point in case a BSOD loop should occur.

Are there any other last minute things I should be doing before I fire the verification cannon on Thursday? Verifier scares the crap outta me still.

 

[ubuysa]

Most people have little idea what Driver Verifier does or what it's for. The chances of a BSOD boot loop are quite low, but it's wise to be prepared just in case. Otherwise there is nothing to be concerned about. All Driver Verifier does is stress drivers by subjecting them to additional tests and checks. It won't break anything.

 

[BrotherJay]

I am not sure I can express in words how happy I was to not only get BSOD'd on the very first boot, but to also, for the first time in 2 years to see that number go from 0% to 100%.'

I know this is something one would typically say to their doctor - I present to you my dump

https://www.dropbox.com/scl/fi/w6zl...ey=pvplrso3mug192qrphdsdou7l&st=ebk9no00&dl=0

0xC4: DRIVER_VERIFIER_DETECTED_VIOLATION

 

[ubuysa]

I'm glad your heart rate didn't go too high! A Boot BSOD isn't the end of the world if you've prepared for it. Remember the five P's - Proper Planning Prevents Poor Performance.

The Driver Verifier dump does reveal the problem driver as expected, it's GUBootStartup.sys - a component of Glary Utilities....

FAILURE_BUCKET_ID:  0xc4_e1_VRF_GUBootStartup!unknown_function

The version of this driver that you have installed is old, dating from Aug 2022...

0: kd> lmvmGUBootStartup
Browse full module list
start             end                 module name
fffff804`92f00000 fffff804`92f09000   GUBootStartup T (no symbols)          
    Loaded symbol image file: GUBootStartup.sys
    Image path: \??\C:\Windows\System32\drivers\GUBootStartup.sys
    Image name: GUBootStartup.sys
    Browse all global symbols  functions  data
    Timestamp:        Fri Aug 19 10:05:41 2022 (62FF3645)
    CheckSum:         00019CB0
    ImageSize:        00009000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4
    Information from resource tables:

If you really need these tools then I suggest you look for an updated version. TBH I really dislike these kinds of tools and never recommend them, they often cause more problems than they're worth. The Windows Disk Cleanup tool does all the garbage cleaning you need. The Windows registry should never be cleaned. Many of the supposed performance improvements tools like this claim are marginal at best and generally not worth the effort. Tools like this are really just bloatware.

I would strongly recommend that you reverse any changes this tool has made and uninstall it. Your BSODs will stop for one thing....

 

[BrotherJay]

I actually have no idea when I would have installed that. Regardless, I have REVO uninstalled it from my system.

Should I run verifier again at this point or just wait to see what that fixed?

 

[ubuysa]

It depends on how much of a performance hit Driver Verifier gives you. If you can live with it then keep Driver Verifier running for another 24 hours, if no more BSODs happen then you can disable it.