Question Mysterious randomly appearing BSOD (NTFS.sys PAGE_FAULT_IN_NONPAGED_AREA)

[AngryComputerBuilder111]

Hi all,

I am writing to plead for your assistance in resolving a persistent issue with my computer. The first time I encountered a Blue Screen of Death (BSOD), I was using a Samsung 980 Pro 2TB SSD with the latest firmware. I did not have full memory dumps enabled at the time, but I quickly researched the issue and enabled the setting.

Despite my efforts, I continue to experience BSODs, particularly when restarting or shutting down my computer. The error message is always the same: "PAGE_FAULT_IN_NONPAGED_AREA" and it always points to the NTFS.sys file. I have scoured multiple forums and tried various troubleshooting steps, such as running memtest86, analyzing memory dumps with WinDbg and WhoCrashed (HOME EDITION), and checking the CHKDSK results. All of these tests have come back clean.

I have also tried swapping out RAM, re-seating the SSD, re-seating the CPU, replacing the PSU from 850 Watt to 1000 Watt, disabling GPU overclocking, re-seating the GPU, reseating the tower air cooler above the CPU, and re-connecting cables. Despite all of these efforts, the issue persists.

It has been over a year since I first encountered this issue and I am becoming increasingly desperate for a solution. I would greatly appreciate any assistance or advice you can offer in resolving this problem and achieving a 100% clean, BSOD-free startup rate.

Thank you in advance for your help.

Sincerely,
AngryComputerBuilder111

(If you're wondering, I did ask ChatGPT to make my text more readable, though I fact-checked the text after and it still preserved the components of my original text.)

 

[johnbl]

provide some memory dumps of the problem. I might see something useful.

 

[AngryComputerBuilder111]

provide some memory dumps of the problem. I might see something useful.

I have 2 related memory dumps available, they're available with the following link:
https://drive.google.com/drive/folders/1ZW_-n5gWNEOezdKjizLCKzjXVR2FBkSZ?usp=sharing
Thanks in advance

 

[johnbl]

most current bugcheck
bugcheck in file system cache management.
the system was only running for 7 seconds

second bugcheck was the same but the system was running 7.9 seconds.

well, here is my guess: you have a power problem, the motherboard detected the problem and reset the cpu. Then it immediately restarted with out waiting for the power_ok signal (some power supplies fake power_ok)
the system booted (hence the timer indicating the system was running 7 seconds) I think the file system was working with the drive cache thru the drive firmware during the reboot and by the time it finished the rebooted windows was up. Maybe a drive firmware bug but I would ignore it and look to find out why the system rebooted
(up for only 7 seconds)
most common reason for a reboot like this would be a gpu pulling too much power from a PCI/e bus.
this happens when playing games, overclocking a gpu, overheating a gpu or when the gpu supplemental power connectors are not connected. (or power supplies not providing proper power)

I guess, the key question would be did you think the system was running longer than 7 seconds? if so what were you doing at the time?

 

[johnbl]

as a side note unrelated to this bugcheck you have this driver installed:
\SystemRoot\System32\drivers\ScpVBus.sys Sun May 5 14:31:26 2013

this version has a bug which corrupts kernel memory and will not pass verifier tests.
you need a version from 2016 that was fixed.
you can download and run microsoft auto runs to remove the driver. (i think the uninstaller does not remove the driver)Autoruns for Windows - Sysinternals | Microsoft Learn

the code for the driver is public and was fixed in 2016 but i could never find anyone who compiled it and released it. just the old 2013 version.

 

[AngryComputerBuilder111]

most current bugcheck
bugcheck in file system cache management.
the system was only running for 7 seconds

second bugcheck was the same but the system was running 7.9 seconds.

well, here is my guess: you have a power problem, the motherboard detected the problem and reset the cpu. Then it immediately restarted with out waiting for the power_ok signal (some power supplies fake power_ok)
the system booted (hence the timer indicating the system was running 7 seconds) I think the file system was working with the drive cache thru the drive firmware during the reboot and by the time it finished the rebooted windows was up. Maybe a drive firmware bug but I would ignore it and look to find out why the system rebooted
(up for only 7 seconds)
most common reason for a reboot like this would be a gpu pulling too much power from a PCI/e bus.
this happens when playing games, overclocking a gpu, overheating a gpu or when the gpu supplemental power connectors are not connected. (or power supplies not providing proper power)

I guess, the key question would be did you think the system was running longer than 7 seconds? if so what were you doing at the time?

Thank you for your advice and knowledge, I'm going to review and check it out.

Currently my windows boot time is ~22 seconds, I think that's both because I disabled fast startup mode, and that I have 13 apps starting at startup (most are bloatware like steelseries gg, razer synapse etc.).
I'm currently using a Corsair HX1000 power supply on multi-rail mode. I checked it out whether the cables were melting and/or not inserted properly, however most seem to have a good fit and are difficult to pull out. I also checked if the ssd were still properly reseated, to which they were.
What I have done now is disable over provisioning for the samsung ssd, although I don't really think there would be a difference.
I think the last resort for me is to check if the power supply is functional.
As for the gpu, I followed some guides online and used two seperate cables to power the gpu, should it be rather one? Otherwise I suppose it's an issue with the fan curve.

Thanks again

 

[AngryComputerBuilder111]

as a side note unrelated to this bugcheck you have this driver installed:
\SystemRoot\System32\drivers\ScpVBus.sys Sun May 5 14:31:26 2013

this version has a bug which corrupts kernel memory and will not pass verifier tests.
you need a version from 2016 that was fixed.
you can download and run microsoft auto runs to remove the driver. (i think the uninstaller does not remove the driver)Autoruns for Windows - Sysinternals | Microsoft Learn

the code for the driver is public and was fixed in 2016 but i could never find anyone who compiled it and released it. just the old 2013 version.

I have found the updated ScpVBus.sys driver located under the following ScpToolkit release (it's from the Xbox 360 emulator driver)
https://github.com/nefarius/ScpToolkit/releases/tag/v1.7.276.16101-BETA

Also, I just experienced another crash, it happened right after when I re-installed the amd software adrenalin program and was required to restart, it BSOD looped my pc with the same ntfs.sys errors. Could it be something that breaks whenever it requires kernel level access to install? (I had some of the previous BSODs happen because uninstalling programs with kernel level access)
I'd be happy to re-supply the new memory dumps.

Kind regards,

 

[johnbl]

oh, if this happens when you are booting then I would boot off of another windows image then do a chkdsk /r /f on the drive that is failing the ntfs cache
you can schedule it if you can get the system to actually boot.
How to Schedule Chkdsk to Run on Restart in Windows 10 (windowsloop.com)

 

[johnbl]

I have found the updated ScpVBus.sys driver located under the following ScpToolkit release (it's from the Xbox 360 emulator driver)
https://github.com/nefarius/ScpToolkit/releases/tag/v1.7.276.16101-BETA

Also, I just experienced another crash, it happened right after when I re-installed the amd software adrenalin program and was required to restart, it BSOD looped my pc with the same ntfs.sys errors. Could it be something that breaks whenever it requires kernel level access to install? (I had some of the previous BSODs happen because uninstalling programs with kernel level access)
I'd be happy to re-supply the new memory dumps.

Kind regards,

if the system is running ok, then you reboot and get the ntfs file system bugcheck
then most likely the system is not properly flushing the cache during the shutdown. This can happen with bugs in drive firmware, it can happen with drives that are set to lazy write and have some reason that there is a delay.

generally you would get the system not actually finishing the shutdown and it would appear to hang. (then people hit the reset button, when the system boots up the filesystem must be repaired)

google something like how to turn off lazy writes and change the setting for your disk and see if it has an effect.
setting should be in windows control panel-> device manager then find the drive and right mouse click for properties and look for something about lazy writes or disk caching.
main point is the data is flushed to disk before the system is reset.
windows should refuse to complete the shutdown/restart if it is going to lose data that is not confirmed to be flushed from cache. if it does not then the file system can become corrupted and chkdsk should automattically run on the next boot up (disk file system dirty bit should be set)
sometimes the standard chkdsk that is run can not fix the problem and you have to use some of the other chkdsk options.

 

[AngryComputerBuilder111]

if the system is running ok, then you reboot and get the ntfs file system bugcheck
then most likely the system is not properly flushing the cache during the shutdown. This can happen with bugs in drive firmware, it can happen with drives that are set to lazy write and have some reason that there is a delay.

generally you would get the system not actually finishing the shutdown and it would appear to hang. (then people hit the reset button, when the system boots up the filesystem must be repaired)

google something like how to turn off lazy writes and change the setting for your disk and see if it has an effect.
setting should be in windows control panel-> device manager then find the drive and right mouse click for properties and look for something about lazy writes or disk caching.
main point is the data is flushed to disk before the system is reset.
windows should refuse to complete the shutdown/restart if it is going to lose data that is not confirmed to be flushed from cache. if it does not then the file system can become corrupted and chkdsk should automattically run on the next boot up (disk file system dirty bit should be set)
sometimes the standard chkdsk that is run can not fix the problem and you have to use some of the other chkdsk options.

I tried diskcheck /r /f, it didn't detect any errors, neither did a dism online /scanhealth, I disabled both write caching and over provisioning, now I'm checking if I still receive a BSOD, but none at the moment.

Thanks for the suggestion