Note: I did not have a new BSOD since post #67.
I was under the impression the (old) DM_log_collector deletes logs that it has already collected.
Anyhow, here are the requested screenshots:
Attachment 172731
Attachment 172732
Attachment 172733
Attachment 172734
Attachment 172735
With my new graphics card, I did not have any issues, BSOD or freezes while using my computer.
Then, after a week I started with verifier again. When I used the settings below, I got a BSOD during booting.
Attachment 174302
I added the bottom 3 checkboxes in the last step.
After disabling verifier, I tried to run the "new" collector you provided, but it does not seem to work correctly. I clicked on the shortcut, and I briefly see a command prompt window opening up with some tekst, but then it is gone. Am I doing something wrong?
Then I ran DM_Collector (see attached), but there is no dump file. I do not know why the dump file is missing.
Since I have nog BSOD when I use my computer normally, or is it safe to say I am "bug free" now?
The last BSOD was on 1/13.
The last unexpected reboot was on 1/18.
For windows driver verifier testing please uncheck DDI compliance checking (additional)
If there is a crash the window for the BSOD should remain open since there is no automatically restart.
Is should display a bugcheck. Sometimes it may display a misbehaving driver in the form *.sys
If there is a BSOD record this information and post it into the thread.
The image for the windows driver verifier was cut off. Please make sure that randomized low resource stimulation is unchecked
The beta log collector is in testing. Some computers may have a flash of the administrative command prompt box and no run of the collector. It may take some time to iron out the quirks but when it works it has additional useful information.
The log collectors should not delete files.
The windows disk cleanup and Ccleaner are the most common causes of lost dump files.
Again, a BSOD during booting, just after I turned on verifier with these settings:
Attachment 174420Attachment 174421
I just added the "code integrity checks". The others were already activated.
I took a photo of the monitor before pressing the reset button:
Attachment 174423
Attachment 174424
Driver verifier detected violation
AMDXATA.SYS
And then I ran DM collector. No minidump file present
Hi zbook,
I see that you haven't responded yet.
I have had no BSOD in weeks, and no freezing games since my new graphics card.
Only when I run verifier with all checkboxes on, I get a BSOD on AMDXATA.SYS. Since windows doesn't leave a dumpfile, and I have no problem running in normal mode, it seems like the time has come to close this case and mark it solved.
Is that OK with you? :)
Then I would like to thank you very much for your great help!
I am really very thankful for your help, patience and effort you gave to help me solve my problem!
Very much appreciated! :)
regards, Smurfmans
The latest log collector did not display any BSOD mini dump files.
The last dump with a bugcheck was on January 13, 2018.
There were no recent crash dump failed in the logs.
There was an unexpected reboot on January 18,2018
Windows drivers are usually fixed with windows updates.
Non-windows drivers when they crash are fixed by updates, uninstall and reinstall, or rollbacks.
If there is a new problem with problematic information in the logs that can be troubleshooted.
If you want to doublecheck the dump formation then please post images of:
1) in the left lower corner type system > open system control panel > on the left pane click advanced system settings > under startup and recovery click settings > make sure that automatically restart is unchecked and for write debugging information that automatic memory dump with memory.dmp is displayed.
2) under performance click settings > on performance options click the advanced tab > under virtual memory click change > make sure that the box for automatically manage paging file size for all drives is checked and the selected drive is C:
The AMDXATA is an AMD storage controller driver and is normally fixed by Windows updates.
You are very welcome.
Code:Event[22597]: Log Name: System Source: Microsoft-Windows-WER-SystemErrorReporting Date: 2018-01-13T20:29:32.173 Event ID: 1001 Task: N/A Level: Error Opcode: N/A Keyword: Classic User: N/A User Name: N/A Computer: Antec Description: The computer has rebooted from a bugcheck. The bugcheck was: 0x000000c9 (0x000000000000024d, 0xfffff8036703deca, 0xffffbc8ca2101060, 0x0000000000000000). A dump was saved in: C:\WINDOWS\MEMORY.DMP. Report Id: f84ddd92-de28-4ebb-97d0-4fc763c1166b.
See also post #71, but I checked it again:
Attachment 175607
Attachment 175608
I again turned on verifier with all (but the three) checkboxes on.
I rebooted and a BSOD appeared. Responsible driver was AMDXATA.SYS
I filmed it; see attached 7z file.
After turning off verifier, I ran DM_collector, but no minidump file.
1) Turn off windows driver verifier
2) open file explorer > this PC > C: > in the right upper corner search for: C:\windows\memory.dmp > post a zip file into the thread
3) run this version of the log collector and post a zip into this thread:
log collector v2-beta08.zip
here are the search results..
Attachment 175737
Attachment 175739
no dump files found.
the new log collector zip is attached.
Every tool that is used has the following 5 parameters:
True positives..................................................................................A positive test result when there is a problem
True negatives................................................................................A negative test result when there is no problem
False positives.................................................................................A positive test result when there is no problem
False negatives...............................................................................A negative test result when there is a problem
Accuracy...........................................................................................A mathematical result using the above 4 values
Rarely is any test 100 % accurate...........there are almost always false positives and false negatives.
People rely on tests without understanding the how the tests work and without knowing the accuracy.
The expectations are often 100% accuracy. This happens in all fields of life.
For Windows driver verifier these are the test settings suggested by Ten Forums:
Enable and Disable Driver Verifier in Windows 10 Performance Maintenance Tutorials
Notice that only 3 customized tests are recommended when using Windows driver verifier.
In contrast these are test settings recommended by a support group at Microsoft:
Driver Verifier-- tracking down a mis-behaving driver. - Microsoft Community
Notice that 19 customized test settings are recommended.
So the term windows driver verifier is used as though the customized settings are identical.
Once the test settings are identical, for example 10,000 computers are tested using the same 10 customized tests there will be results as noted in the beginning of the post. Some of the computers will have false positives and false negatives. There is rarely 100 % accuracy.
We use a large data base of drivers. On the list it displays whether it is fixed by windows updates or by a component manufacturer. The driver that was displayed on the computer is listed as a driver that is fixed by Windows updates. So we do not manually fix that driver and allow windows updates to fix it . If it is not causing any problems there is no incentive to meddle.
When we troubleshoot mini and memory dumps there are typically a large number of Microsoft drivers that appear in the debugging results. And again we allow Windows updates to fix them and manually fix all of the 3rd party drivers.
So when using windows driver verifier you may get false positive and false negatives. There is no 100 % accuracy. We apply the end users reports with the objective findings and fix drivers as needed. In crashes there are some bugchecks in which a driver is implicated and it is not the misbehaving driver. The misbehaving driver may remain hidden. There are other crashes where the driver that caused the crash impacted many other drivers. If you are able to determine the misbehaving driver all of the other drivers that were impacted by the crash do not need to be replaced. Overtime you get to see how different bugchecks occur and have an idea which drivers would be responsible even without finding a definitive result. With more dumps the assessments often gets easier.
So for the current driver that you see using Windows driver verifier you can approach it academically: For example you could start with the Ten forums method of 3 customized tests. Are there any misbehaving drivers? And then you could increase number of customized tests to the Microsoft link method and see which customized test cause the driver to BSOD. For example you keep adding 2 or 3 customized tests (from 3 to 19). Again this would be an academic undertaking as there is no real change in the management of the drivers.
The latest files reviewed were dated 2/5/2018. In the files the last BSOD related crash was bugcheck c9 on 1/13/2018.
The last crash was on 1/18/2018 and that could be related to a power off with an unexpected restart.
Have no crashes for 18 days is a sign of a stable computer environment.
Quote
