Question Random BSOD 3-7 times a day - mini dumps - Help - Again!

[nigelfreeney]

Windows 10 21H1
Motherboard Z170-WS
32GB Ram Corsair Vengeance LPX DDR4 2666 C16 2x16GB
OS and program partitions on an Intel 750 series 1.2TB NVME drive
GPU Nvidia GTX 1060-6GB
Sandisk Ultra II 960GB
Toshiba X300 6TB
Corsair Force MP510 m.2 SSD 4TB
WD Red 4TB

I am getting multiple BSODs daily on an ASUS Z170-WS based system. I have tried using Whocrashed to pinpoint the issue but it is constantly throwing in the same generic error i.e.:

crash dump file: C:\WINDOWS\Minidump\080221-13750-01.dmp
uptime: 00:36:31
This was probably caused by the following module: ntkrnlmp.exe (nt!PspCatchCriticalBreak+0x10E)
Bugcheck code: 0xEF (0xFFFFB001D9A75140, 0x0, 0x0, 0x0)
Error: CRITICAL_PROCESS_DIED
Bug check description: This indicates that a critical system process died.
There is a possibility this problem was caused by a virus or other malware.
The crash took place in the Windows kernel. Possibly this problem is caused by another driver that cannot be identified at this time.

I have replaced the graphics card and the PSU. I have moved the graphics card to a different slot and reseated both memory modules. I have gone into the BIOS and set the CPU and memory to its default speed. I have used DDU to remove the Nvidia graphics drivers and have installed the latest non-dch drivers. I have used Driver Easy to check and install all the latest drivers. Device Manager shows no issues.

I back-up daily. At one point I had a stable system but every time I tried to update any of the drivers it would make the system unstable. I was able to put the system back to a stable backup as the system and program drives are separate from the data drives. This worked for a while but now even that doesn't work.

In a previous post I got some suggestions that seemed to work - specifically updating to the latest BIOS 3602. This lasted for about 10 days. However, I had to temporarily install a ThunderboltEX 3 for testing. This didn't work as expected. Then shortly after I removed the card and not the drivers I started getting frequent BSODs again - 3 today. I tried installing an image I had backed up prior to installing the ThunderboltEX 3, but this doesn't appear to have resolved the problem. I'm inclined to think I may have a hardware problem because restoring it back to an apparently stable state does not have any affect. Any advice would be welcome.

I have three mini dumps from today can anyone help?
https://drive.google.com/file/d/17N2GrrQekZSlufbGPxTnCoiukMELfNhg/view?usp=sharing
https://drive.google.com/file/d/1EZ6awPp5Ed3zmPnGniNGE3aowwvfGQ63/view?usp=sharing
https://drive.google.com/file/d/1MNqIde8Kxj-5rr0ol8SPJuhxDlPUdfUK/view?usp=sharing

 

[nigelfreeney]

Did you test with the modules seated in different slots? Right now it sounds like that slot may be causing problems.

It has been three days without a BSOD and four days since I installed the RAM into the first channel A1/B1. So, if I get to a week I will give you the points for the winning answer. 😀

I forgot to say,

Thanks for your time and help!

 

[white.a.drew]

I would like to believe you are correct but that doesn't really make sense...
If the primary channel is A2 then why not rename it to A1.
Why not say in a manual that you can use either A1/B1 or A2/B2.
The manuals from ASUS are very specific that you should always use the second slots when you are filling a single channel.
If after market coolers are a factored issue why not design a motherboard to allow for that and move components that don't require access into that space?
Clearly that is the best answer because it is the only one given but...

The issue with moving pirts around and expanding g the distance is more latency from the parts so slower response times.

 

[nigelfreeney]

The issue with moving parts around and expanding g the distance is more latency from the parts so slower response times.

Whilst I can't deny that may be a factor, there are only a few things that have to be in a specific fixed location on a mother board. These standard positions allow cases to be designed around a standard. Off the top of my head these would specifically be limited to the CPU and the IO ports. All motherboards are not laid out in identical ways. With Asus I look at their more basic motherboards and their workstation motherboards and their can be huge variations in layout depending on the configuration.

Even now, I am not arguing that you are definitely wrong. It has just always struck me that this is one of those peculiarities that has perhaps come about through a logical reason, but there is no way to easily tell what that is, or even if it is justified - perhaps it has edged into the "because we have always done it like that..." realm?

 

[white.a.drew]

Whilst I can't deny that may be a factor, there are only a few things that have to be in a specific fixed location on a mother board. These standard positions allow cases to be designed around a standard. Off the top of my head these would specifically be limited to the CPU and the IO ports. All motherboards are not laid out in identical ways. With Asus I look at their more basic motherboards and their workstation motherboards and their can be huge variations in layout depending on the configuration.

Even now, I am not arguing that you are definitely wrong. It has just always struck me that this is one of those peculiarities that has perhaps come about through a logical reason, but there is no way to easily tell what that is, or even if it is justified - perhaps it has edged into the "because we have always done it like that..." realm?

You also have to realize all these different motherboards all these different lay outs they all have they're own issues in latency or spacial awareness to certain parts look at all the videos out their of LIFE TIME builders that still run into mounting issues and dump things that cause issues whether they thought out preformance of a machine would be this on a system but is actually this because poor data communication between parts. Or they simply have to reduce a whole order because everyone thought parts would fit in a particular case but didn't. Or whatever it maybe.

 

[nigelfreeney]

Did you test with the modules seated in different slots? Right now it sounds like that slot may be causing problems.

Well, after changing the memory into the second channels, my PC behaved for 4 days. No BSODs, actively used and backing up without problems. The last 24hours I have had 6 BSODs. I have included the WhoCrashed report but that’s not at all helpful:
https://drive.google.com/file/d/1hrxZFyQtGnH-qShylDZXvAkdVo2bSs5K/view?usp=sharing

Latest SysNativeFileCollection output (20210818)
https://drive.google.com/file/d/1OAtfhPlyG1KcM5Ay0ucbjVvchQ_WjN6Y/view?usp=sharing

Zipped minidump files from last two days (6)
https://drive.google.com/file/d/12y19stAct6JZiUtQS0pVaukM3---De0W/view?usp=sharing

 

[axe0axe0]

Just an FYI, no need to upload minidumps separately when uploading Sysnative log files. The minidump files are included in the Sysnative log files.

You have done a chkdsk, but I would recommend doing it again if you haven't done so in the past few days.

   2021-08-13T16:32:57.8240000Z        Volume C: (\Device\HarddiskVolume3) requires an Online Scan.  An Online Scan will automatically run as part of the next scheduled maintenance task.  Alternatively you may run "CHKDSK /SCAN" locally via the command line, or run "REPAIR-VOLUME <drive:> -SCAN" locally or remotely via PowerShell.
   2021-08-13T16:32:57.8240000Z        A corruption was discovered in the file system structure on volume C:.
The exact nature of the corruption is unknown.  The file system structures need to be scanned online.
   2021-08-13T20:44:32.9070000Z        Volume C: (\Device\HarddiskVolume3) needs to be taken offline for a short time to perform a Spot Fix.  Please run "CHKDSK /SPOTFIX" locally via the command line, or run "REPAIR-VOLUME <drive:>" locally or remotely via PowerShell.
   2021-08-13T20:45:01.0930000Z        Volume C: (\Device\HarddiskVolume3) needs to be taken offline to perform a Full Chkdsk.  Please run "CHKDSK /F" locally via the command line, or run "REPAIR-VOLUME <drive:>" locally or remotely via PowerShell.
   2021-08-14T02:56:54.0520000Z        Volume ?? (\Device\HarddiskVolumeShadowCopy12) needs to be taken offline to perform a Full Chkdsk.  Please run "CHKDSK /F" locally via the command line, or run "REPAIR-VOLUME <drive:>" locally or remotely via PowerShell.
   2021-08-14T09:26:37.3100000Z        Volume ?? (\Device\HarddiskVolumeShadowCopy17) needs to be taken offline to perform a Full Chkdsk.  Please run "CHKDSK /F" locally via the command line, or run "REPAIR-VOLUME <drive:>" locally or remotely via PowerShell.

 

[nigelfreeney]

Just an FYI, no need to upload minidumps separately when uploading Sysnative log files. The minidump files are included in the Sysnative log files.

You have done a chkdsk, but I would recommend doing it again if you haven't done so in the past few days.

   2021-08-13T16:32:57.8240000Z        Volume C: (\Device\HarddiskVolume3) requires an Online Scan.  An Online Scan will automatically run as part of the next scheduled maintenance task.  Alternatively you may run "CHKDSK /SCAN" locally via the command line, or run "REPAIR-VOLUME <drive:> -SCAN" locally or remotely via PowerShell.
   2021-08-13T16:32:57.8240000Z        A corruption was discovered in the file system structure on volume C:.
The exact nature of the corruption is unknown.  The file system structures need to be scanned online.
   2021-08-13T20:44:32.9070000Z        Volume C: (\Device\HarddiskVolume3) needs to be taken offline for a short time to perform a Spot Fix.  Please run "CHKDSK /SPOTFIX" locally via the command line, or run "REPAIR-VOLUME <drive:>" locally or remotely via PowerShell.
   2021-08-13T20:45:01.0930000Z        Volume C: (\Device\HarddiskVolume3) needs to be taken offline to perform a Full Chkdsk.  Please run "CHKDSK /F" locally via the command line, or run "REPAIR-VOLUME <drive:>" locally or remotely via PowerShell.
   2021-08-14T02:56:54.0520000Z        Volume ?? (\Device\HarddiskVolumeShadowCopy12) needs to be taken offline to perform a Full Chkdsk.  Please run "CHKDSK /F" locally via the command line, or run "REPAIR-VOLUME <drive:>" locally or remotely via PowerShell.
   2021-08-14T09:26:37.3100000Z        Volume ?? (\Device\HarddiskVolumeShadowCopy17) needs to be taken offline to perform a Full Chkdsk.  Please run "CHKDSK /F" locally via the command line, or run "REPAIR-VOLUME <drive:>" locally or remotely via PowerShell.

I restored the OS C: and program F: drives back four days prior to the BSODs restarting. Before doing anything else I have run 'chkdsk /f /r' which required a restart - this completed without any errors showing. I generated an Acronis True Image system report to see if any of the drives are reporting errors - none were. It seems like the first port of call if the BSODs return.

Thanks,

 

[nigelfreeney]

Just an FYI, no need to upload minidumps separately when uploading Sysnative log files. The minidump files are included in the Sysnative log files.

You have done a chkdsk, but I would recommend doing it again if you haven't done so in the past few days.

   2021-08-13T16:32:57.8240000Z        Volume C: (\Device\HarddiskVolume3) requires an Online Scan.  An Online Scan will automatically run as part of the next scheduled maintenance task.  Alternatively you may run "CHKDSK /SCAN" locally via the command line, or run "REPAIR-VOLUME <drive:> -SCAN" locally or remotely via PowerShell.
   2021-08-13T16:32:57.8240000Z        A corruption was discovered in the file system structure on volume C:.
The exact nature of the corruption is unknown.  The file system structures need to be scanned online.
   2021-08-13T20:44:32.9070000Z        Volume C: (\Device\HarddiskVolume3) needs to be taken offline for a short time to perform a Spot Fix.  Please run "CHKDSK /SPOTFIX" locally via the command line, or run "REPAIR-VOLUME <drive:>" locally or remotely via PowerShell.
   2021-08-13T20:45:01.0930000Z        Volume C: (\Device\HarddiskVolume3) needs to be taken offline to perform a Full Chkdsk.  Please run "CHKDSK /F" locally via the command line, or run "REPAIR-VOLUME <drive:>" locally or remotely via PowerShell.
   2021-08-14T02:56:54.0520000Z        Volume ?? (\Device\HarddiskVolumeShadowCopy12) needs to be taken offline to perform a Full Chkdsk.  Please run "CHKDSK /F" locally via the command line, or run "REPAIR-VOLUME <drive:>" locally or remotely via PowerShell.
   2021-08-14T09:26:37.3100000Z        Volume ?? (\Device\HarddiskVolumeShadowCopy17) needs to be taken offline to perform a Full Chkdsk.  Please run "CHKDSK /F" locally via the command line, or run "REPAIR-VOLUME <drive:>" locally or remotely via PowerShell.

After restoring back to the 16th before the crashes started reoccurring, I have had three BSODs in two days. As requested I have checked for drive errors and none are reported. Having said that I don't know where in the report you found the corruption identified. If you could let me know, then I could check before posting and avoid wasting your time.
https://drive.google.com/file/d/1a5L70GQ2Oqp7SHg2VkWskzNlpkTPvgdd/view?usp=sharing

There was one obvious variation, vid.sys, but I'm not sure how relevant that it as I don't knowingly use virtualisation.

Thanks,

Nigel

 

[nigelfreeney]

Persevering through the BSODs. Had a couple of days with just one and now back to 5 in the last 12 hours two were within 20 minutes of the one before...
https://drive.google.com/file/d/1eF2oQ8VZ_g8P7UcOU8vK-qryCC6S5kuh/view?usp=sharing

 

[Colif]

I was letting Axe look after you but it seems he hasn't returned for a week now. He gets busy like that.

Conversion of last 8 - https://jsfiddle.net/gbrd3fpm/show

hmm, not often i see 8 crashes and all the victims are parts of windows.
csrss.exe - Client your user runs in
i saw vid.sys. Hyper V

Vid!VidTracepEtwCallback
Vid.sys - Microsoft Hyper-V Virtualization Infrastructure Driver
ETW = Event tracing for Windows - https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/event-tracing-for-windows--etw-

its not cause as such, its just part of the processes leading up to the crash

its not often I don't have anything to suggest to fix it. I am not 100% sure what the problem is.

 

[nigelfreeney]

its not often I don't have anything to suggest to fix it. I am not 100% sure what the problem is.

I often hear "I haven't seen that before..." which usually isn't actually a bad thing. Unfortunately in this case... not so great. Maybe Axe will come back with something. At this point I am thinking of either a complete reinstall from scratch. Or a motherboard and CPU upgrade, plus a reinstall from scratch.

Thanks for taking the time to look at the problem

 

[Colif]

clean install can't hurt, it makes windows get all new drivers and if the problem is software, you have to be really unlucky to get same drivers twice.

axe works at one of the websites I would suggest you also try on. You might get his attention there - https://www.sysnative.com/forums/

 

[nigelfreeney]

clean install can't hurt, it makes windows get all new drivers and if the problem is software, you have to be really unlucky to get same drivers twice.

axe works at one of the websites I would suggest you also try on. You might get his attention there - https://www.sysnative.com/forums/

I accidentally came across SysNative forums and posted a summary on there as it appeared to come to a natural end here...

Just like to say thanks to everyone that took a look and chipped in.

So far I have uninstalled Nortpn360 and System Mechanic and a couple of other possible issues.

I'm currently on my 4th BSOD this morning and seriously thinking I need to go for hardware update option ...

 

[Colif]

Maybe try booting from this and see if you get any problems running off it - https://itsfoss.com/create-live-usb-of-ubuntu-in-windows/
reason being if 2 OS have problems it probably is hardware

If linux works, it doesn't mean its windows though... linux is less stressing on PC than windows and often Windows won't work on PC that linux does, but its still worth running as a test.

might as well share any dumps you have, maybe we get lucky.

 

[nigelfreeney]

Quick update:

I swapped out the 2.5" U.2 drive for a PCIe version that wasn't displaying any issues. It's been running for 48 hours with one BSOD. When I swapped it I restored the back up from earlier in the day - up to then I had been getting 7-8 BSODs a day. ON restore I had a historic BSOD showing in Reliability History. At midnight (more than 36 hours later) I had an actual BSOD but no minidump. I added the faulting drive into the into the donor PC and restored the backup for that drive. Both PCs have the same motherboard. Despite a couple of tries, I couldn't get the drive to boot. I had already contacted Intel Customer support on the 3rd September. I let them know the updated information and they have agreed a replacement. Hopefully this is the main cause of the problems and I can get back to being productive.

Just wanted to say thanks to everyone that took an interest and offered assistance.

I'll let you know in a couple of weeks time if this has solved the issue.