Question Problems related to ntoskrnl.exe

[derwaffenbarnitzke]

Hello, it's been approximately a week or so since BSODs started to plague in and it became even more frustrating as days went by. I couldn't find any lead online apart from the fact that BlueScreenView highlights ntoskrnl.exe as a culprit. Decided to give Driver Verifier a go and my system BSOD with ntoskrnl.exe and Wdf01000.sys which might be because of Driver Verifier? since after enabling that my system became slow and sluggish but returned to normal once I decided to restore it but still no hope in finding what is causing issues with my PC.


SPECS: -
Ryzen 5900X
GTX 1080 (Founders Edition)
ASUS B550-E Running BIOS Ver. 2803
2x 16GB RAM Sticks rated for 3600Mhz overclock, from G.SKILL TridentZ RGB Series
Windows 10 Pro Version 10.0.19044 Build 19044

As for anyone pointing out it might be an overclocking issue, I've undervolted my GPU and applied a few settings in BIOS such as changing the RAM speed to 3600Mhz, disabling PBO limits for my CPU again for undervolting, enabling Global C states and selecting the option "Low current idle" in bios. I've been using this same setup for a year, it was as smooth as butter without any BSODs that might be around 2021-2022.

I suspect it might be because I've updated my GPU drivers? or my BIOS firmware? or could it be after installing a proxy app called Netch? or perhaps a Windows OS update...? These are so far all I could remember from the back of my head on what I've either recently downloaded or updated.

I've uploaded all the recent minidump files here. Please have a look since I've tried my best to search and figure out what could it possibly be but I still couldn't find it out after spending weeks of searching with no hope. Download Minidump files here.

 

[johnbl]

verifier.exe stays on after you reboot and your system will run slowly until you run the command
verifier.exe /reset

this will turn off all of the verifier.exe error checking and your machine will run better.
wdf01000.sys is part of the windows driver framework
the general solution for a bugcheck in this file would be to update your bios
then update the motherboard drivers.
I will take a quick look at the minidump to see if I can see any problems.

most current bugcheck:
stack corruption program called freepie.exe
vjoy.sys was calling wdf01000.sys
some unknown function in vjoy.sys was called because of the stack corruption.
verifier was turned on and found the bug.
--------------
second newest bugcheck>
nvidia share.exe running
looks like corruption in the page table c:\pagefile.sys

need a kernel memory dump to debug this.
you need to confirm that you know and want windivert64.sys
running out of a local directory.

ssdio64.sys running out of syswow64 subdirectory file date is 2005

overclock driver running, you should remove while debugging:
rtcore64.sys
you can run autoruns64 from here Autoruns for Windows - Windows Sysinternals | Microsoft Docs
find the menu item to hide microsoft entries and take a look at what is left. You can disable a driver for the next boot by unchecking the checkbox or remove a driver by deleting the entry.
not sure what netfilter2.sys driver is doing, looks like a driver from Iolo Technologies System Mechanic Free Versions

lots of suspect drivers but I have to go to a movie now, be back later.
note: i would uninstall nvidia share if not using it.

 

[derwaffenbarnitzke]

Hello, regarding the most current bugcheck I recollect trying to open a file or hitting run in vJoy (it's an application which converts mouse movements to gamepad in brief) and then my entire PC BSOD with SYSTEM_SERVICE_EXCEPTION.

Regarding the second newest bug check, I use Nvidia Shadowplay to sometimes record my gameplays but not always so I guess disabling it might help? Would prefer to leave it as it is since I had it like that for a while as well.


About windivert64.sys, at that time I was using Visual Studio Code to play around with packets with the help of windivert64.sys {Pydivert since I am using Python} so I doubt that could cause issues...? Unless the driver is unstable?
Anyway, I've just configured my system to write kernel memory debugging information so that if a BSOD occurs again I can share it down here.


I have no idea regarding ssdio64.sys, perhaps could this be the culprit? searching up on the internet as well pulls no result as to what this driver could be?


Also, rtcore64.sys seems to be Rivatuner, perhaps I have to disable this in case I get a BSOD again so that it'd be easier to isolate what is causing an issue...?


There's a program named Netch which I've just explained earlier it's a proxy app for Windows and I can either proxy certain apps/processes or the whole system with the help of Netch.
As of now, I am using Netch to only proxy certain processes (Discord & qBittorent) and it uses a driver called netfilter2.sys, it opens a socks5 port as well and I use another app called Proxifier which helps me proxy apps by connecting to my localhost socks5 proxy since there are some apps which don't really handle well when Netch proxies them but works fine with Proxifier.

Regarding netfilter2.sys I used to have a lot of BSOD with Netch 1.9.6, BlueScreenView pointed out that there was a problematic driver called netfilter2.sys which helped me identify this app was problematic, but as of now I am using Netch 1.9.7 which had been announced 13 days as of writing this post and so far I don't get any errors related to netfilter2.sys. I've asked someone regarding this in a telegram group and they pointed out to me that if a BSOD does occur again change the version back to 1.9.4 otherwise leave it as it is. So if I do experience another netfilter2.sys related BSODs then all I need to do is just downgrade the version.

After reading the post, all I did so far is disable the Broadcast Live option within Nvidia Overlay and head to my motherboard manufacturer's site to download the latest AMD chipset drivers as my BIOS version is up-to-date according to the ASUS website (Version 2803) but maybe because there's no way to check my AMD Chipset driver version I decided to install the chipset drivers again. Later I just changed my PC to only dump out kernel memory information that way it'd be useful if another BSOD occurs.

Anything else from my side I can do about now apart from waiting for a BSOD to trigger?

 

[johnbl]

use autoruns and remove ssdio64.sys
this is a 32 bit driver running out of a subsystem and it is really old.

I am guessing it corrupts your pagefile.sys then files that are loaded back into memory after the system wakes are corrupted and then cause the bugchecks.

you will also want to delete your hidden pagefile.sys and create a new one. You can do this by turning off the system virtual memory then rebooting and turning it back on.

 

[derwaffenbarnitzke]

Hello, regarding ssdio64.sys, was planning to remove it with autoruns but for some reason, there's no file named ssdio64.sys, perhaps you meant ssgdio64.sys? I've provided a screenshot below.

 

[johnbl]

Hello, regarding ssdio64.sys, was planning to remove it with autoruns but for some reason, there's no file named ssdio64.sys, perhaps you meant ssgdio64.sys? I've provided a screenshot below.

[/QUOTE
e]

 

[johnbl]

yep, looks like the correct driver to remove. Must have made a typo when I entered in the info.