Question Three System BSODs ?

Page 3 - Seeking answers? Join the Tom's Hardware community: where nearly two million members share solutions and discuss the latest tech.
Toggle sidebar Toggle sidebar
johnbl said:
just looked at your most current minidump. Looked like windows was compressing some memory and got an access violation. tried to compress a invalid address (0)

You have some old drivers installed that would not know about memory compression and might modify compressed memory.
I would consider removing some of your old drivers.

might look at:
ovpn-dco.sys (invalid timestamp and build number)
PxHlpa64.sys Tue Apr 24 10:26:29 2012 old sonic solution driver
vbaudio_cable64_win7.sys Wed Aug 13 23:15:25 2014

-------
maybe the other bugchecks will show a direct corruption and name a driver. Will take a few minutes to check.

second bugcheck was also wof.sys trying to compress a invalid address. (0 and -1)
wof.sys is windows overlay filter driver used to run compress files directly.
------
third bugcheck also in wof.sys compression
--------------
the oldest bugcheck was the most interesting
0xc0000409 - The system detected an overrun of a stack-based buffer
some driver is corrupting your memory data structures. I would suspect just a bug where they free a memory address twice.
looks like some usb human interface device using intrl usb interface extensions

mindumps do not show hid devices, you would have to provide a kernel memory dump. I would be looking for old usb devices and update firmware of usb devices like mice, also any special usb device drivers related to your usb devices. for example usb drives sometimes have old drivers that get loaded from the drive and cause corruption.

change your memory dump to kernel and the memory.dmp will have the proper debug info included.

you could also enable verifier testing and your system will bugcheck when a driver does something wrong. it will force the system to bugcheck much faster at the time of corruption rather than later when corrupted data is cleaned up or deleted at system idle time. Be sure you know how to turn off verifier via going into safe mode and running
verifier /reset
sometimes with old driver you get a bugcheck during the boot process.
I would assume this is the root cause of all of the bugchecks.

note: looks like you have Microsoft generic usb drivers installed. Some system might require your custom mother board cpu chipset drivers to be installed. you might install
AMD Chipset Driver from your motherboard vendor to see if it helps.
you might remove HidGuardian. I use a usb splitter that has a on/off button for each device I want to use.
Click to expand...
Here's the Kernel memory dump file. https://mega.nz/file/57NUwRJL#-aoHFiPVr4MROmLphvg75_ACz3QE0L5l8PfDf41WibQ
 
DevanDrake99 said:
Here's the Kernel memory dump file. https://mega.nz/file/57NUwRJL#-aoHFiPVr4MROmLphvg75_ACz3QE0L5l8PfDf41WibQ
Click to expand...
looking at the dump now, looks like the same problem
all active cores were trying to compress memory. one core attempted to compress a invalid location (zero) and called the bugcheck. will look at the dump to see if I can figure out why.
most likely some old driver doing something wrong.

very large number of packets going thru your USB subsystem.
(3.7 million packets, 7 indicators that the controller might have lost some)

usb 3 logs show some problem with hub1, looks like registry keys are not configured so all of the port numbers are invalid
ports 19- 22
Multiple USB 2.0 ports mapped to the same connector!
device connected

11: kd> !storunit
STORPORT Units:
==================
Product SCSI ID Object Extension Pnd Out Ct State
--------------------------------------------------------------------------------------
Seagate Portable 0 0 0 ffffae8779a84050 ffffae8779a841a0 0 0 0 Working
ST2000DM00 4 0 0 ffffae8775446050 ffffae87754461a0 0 0 0 Working
WDC WD10EZEX-0 5 0 0 ffffae877545c050 ffffae877545c1a0 0 0 0 Working

USB\VID_0BC2&PID_2344&REV_0712
looks like some Seagate 2.0 usb device.

Seagate list this as a vintage device with now support and recommend you remove it and its software.
I would do that, then go into windows control panel, find the option to show hidden devices and delete every greyed out entry and reboot. (if there are any entries) this will prevent drivers from removed devices messing up your system.

generally i would expect the bugcheck to be caused by a driver freeing up a memory object twice. generally, I would run verifier.exe tests on my system and the system should bugcheck when the driver makes the second free of the device driver memory. Then you reboot, turn off verifier.exe by running verifier.exe /reset and then look at the memory dump. verifier should bugcheck the system when the second free call is made rather than later when the system is cleaning up the free list at system idle time. with verifier on the bad driver will be on the stack. Note, your system might bugcheck at boot due to all of the third party drivers you have installed. So make sure you know how to get into safe mode so you can turn off verifier.
otherwise you get into a boot bugcheck loop.
(note, after the third loop, the system should go into safe mode, then you run the command shell and run verifier.exe.)
some people panic and wipe the system.
 
Last edited:
Note: i guess if you do not run verifier to find a bad driver you might just turn off the windows memory compression.
ie google "how to disable windows MemCompression.exe"

https://superuser.com/questions/1000485/how-to-disable-windows-10-memory-compression
it would tell you to run something like:
run a power shell script as an admin
Disable-MMAgent -mc

old drivers can modify areas of memory and not realize that now the data in memory has been compressed. Ie it writes uncompressed data on top of the compressed data structures.
Later the corruption crashes when compress/decompress procedures are correctly called. you have identify and stop using the driver or turn off the memory compression in windows
 
johnbl said:
Note: i guess if you do not run verifier to find a bad driver you might just turn off the windows memory compression.
ie google "how to disable windows MemCompression.exe"

https://superuser.com/questions/1000485/how-to-disable-windows-10-memory-compression
it would tell you to run something like:
run a power shell script as an admin
Disable-MMAgent -mc

old drivers can modify areas of memory and not realize that now the data in memory has been compressed. Ie it writes uncompressed data on top of the compressed data structures.
Later the corruption crashes when compress/decompress procedures are correctly called. you have identify and stop using the driver or turn off the memory compression in windows
Click to expand...
I'm still getting blue screens even with memory compression disabled.
 
DevanDrake99 said:
I'm still getting blue screens even with memory compression disabled.
Click to expand...
looking at dump now
looks like you were booting into safe mode and 3 drivers were blocked from loading.

system did not bugcheck in compression code.
the system was idle.
looks like it was in safe mode
all cores were idle but then cpu core 8 called
nt!KiIpiInterrupt
looked like it went to some error handling table and called a bugcheck because it was a privileged instruction.

I would be checking the voltages to the cpu, (from the power supply) I would also run cpu diagnostics.

if you are running in safe mode, you might want to disable the hardware for your audio system,
ServiceName is "VirtualAudioCable_83ed7f0e-2028-4956-b0b4-39c76fdaef1d"
ServiceName is "AtiHDAudioService"

strange that they system up timer was
System Uptime: 1 days 19:06:34.336
was the system actually in safe mode?

I see old third party drivers being loaded that should not be loaded in safe mode. if you were not in safe mode, I would just remove all of these old drivers/tools. reboot and test the cpu.
then add these tools back one by one if you really need them.
otherwise run verifier to force a bugcheck on any driver that is making a mistake.

note: assumed safe mode because of this error code:
8: kd> !error 0xc000035f
Error code: (NTSTATUS) 0xc000035f (3221226335) - The driver was not loaded because the system is booting into safe mode.

note: part of the error was related to a invalid Tss
https://en.wikipedia.org/wiki/Task_state_segment
some sort of corruption. looks like the hardware made some interrupt and windows determined Tss was invalid and bugchecked since it can not trust the CPU states.

you should fix your disabled hardware drivers or actually disable the hardware in bios and reboot. then retest.
I would remove all of the old software, get the system clean and see if the system is stable. 1 day 19 hours is a long time to wait for a bugcheck. I would run verifier and try to find a driver that is corrupting kernel data structures. Otherwise you are looking at the victim of a corruption rather than the cause of the corruption.

note: cpu speed was being throttled
(Flags: 0x00000013 Throttling Initialized)
from 3600MHz to 3593MHz
8: kd> !sysinfo cpumicrocode
Initial Microcode Version: 00000000:08701030
Cached Microcode Version: 00000000:00000000
Processor Family: 17
Processor Model: 71
Processor Stepping: 00
Note: Cached Microcode Version is not detected!

no cpu microcode patch installed. I would also look for known bugs in your cpu.
Identifier = REG_SZ AMD64 Family 23 Model 113 Stepping 0
ProcessorNameString = REG_SZ AMD Ryzen 5 3600 6-Core Processor
 
Last edited:
johnbl said:
looking at dump now
looks like you were booting into safe mode and 3 drivers were blocked from loading.

system did not bugcheck in compression code.
the system was idle.
looks like it was in safe mode
all cores were idle but then cpu core 8 called
nt!KiIpiInterrupt
looked like it went to some error handling table and called a bugcheck because it was a privileged instruction.

I would be checking the voltages to the cpu, (from the power supply) I would also run cpu diagnostics.

if you are running in safe mode, you might want to disable the hardware for your audio system,
ServiceName is "VirtualAudioCable_83ed7f0e-2028-4956-b0b4-39c76fdaef1d"
ServiceName is "AtiHDAudioService"

strange that they system up timer was
System Uptime: 1 days 19:06:34.336
was the system actually in safe mode?

I see old third party drivers being loaded that should not be loaded in safe mode. if you were not in safe mode, I would just remove all of these old drivers/tools. reboot and test the cpu.
then add these tools back one by one if you really need them.
otherwise run verifier to force a bugcheck on any driver that is making a mistake.

note: assumed safe mode because of this error code:
8: kd> !error 0xc000035f
Error code: (NTSTATUS) 0xc000035f (3221226335) - The driver was not loaded because the system is booting into safe mode.

note: part of the error was related to a invalid Tss
https://en.wikipedia.org/wiki/Task_state_segment
some sort of corruption. looks like the hardware made some interrupt and windows determined Tss was invalid and bugchecked since it can not trust the CPU states.

you should fix your disabled hardware drivers or actually disable the hardware in bios and reboot. then retest.
I would remove all of the old software, get the system clean and see if the system is stable. 1 day 19 hours is a long time to wait for a bugcheck. I would run verifier and try to find a driver that is corrupting kernel data structures. Otherwise you are looking at the victim of a corruption rather than the cause of the corruption.

note: cpu speed was being throttled
(Flags: 0x00000013 Throttling Initialized)
from 3600MHz to 3593MHz
8: kd> !sysinfo cpumicrocode
Initial Microcode Version: 00000000:08701030
Cached Microcode Version: 00000000:00000000
Processor Family: 17
Processor Model: 71
Processor Stepping: 00
Note: Cached Microcode Version is not detected!

no cpu microcode patch installed. I would also look for known bugs in your cpu.
Identifier = REG_SZ AMD64 Family 23 Model 113 Stepping 0
ProcessorNameString = REG_SZ AMD Ryzen 5 3600 6-Core Processor
Click to expand...
Yes. It was running in safe mode. But even then. It's still blue screening. I would decrease the speeds of the CPU.
 
ok first verifier bugcheck was called because of HidGuardian.sys
you will want to tell verifier to exclude checking of hidguardian.sys
or remove it from your system.

bugcheck was because HidGuardian.sys requested a memory block that can be used to run code in. (makes it a target for malware)

to exclude a driver from testing you add a command line option to the verifier.exe command. I will see if i can look it up for you.

so, exclude hidgauardian.sys then reboot and get the next bugcheck.



the switch for verifier.exe is
/driver.exclude DriverList Specifies one or more drivers that will be excluded from verification. This parameter is applicable only if all drivers are selected for verification. DriverList is a list of drivers by binary name, such as Driver.sys. Use a space to separate each driver name. Wildcard values, such as n*.sys, are not supported.
https://learn.microsoft.com/en-us/windows-hardware/drivers/devtest/verifier-command-line

so you would run
verifier.exe /driver.exclude HidGuardian.sys
then reboot.
note: you might consider adding this switch also:
/bootmode oneboot
this will do one boot with verifier on, then turn it off for the next boot. Saves you from having to go into safe mode and running verifier.exe /reset and rebooting.

you should not have to restore or repair windows if your turn off verifier with this command

note: cpu microcode update not installed. CPU bugs exposed
 
Last edited:
johnbl said:
ok first verifier bugcheck was called because of HidGuardian.sys
you will want to tell verifier to exclude checking of hidguardian.sys
or remove it from your system.

bugcheck was because HidGuardian.sys requested a memory block that can be used to run code in. (makes it a target for malware)

to exclude a driver from testing you add a command line option to the verifier.exe command. I will see if i can look it up for you.

so, exclude hidgauardian.sys then reboot and get the next bugcheck.



the switch for verifier.exe is
/driver.exclude DriverList Specifies one or more drivers that will be excluded from verification. This parameter is applicable only if all drivers are selected for verification. DriverList is a list of drivers by binary name, such as Driver.sys. Use a space to separate each driver name. Wildcard values, such as n*.sys, are not supported.
https://learn.microsoft.com/en-us/windows-hardware/drivers/devtest/verifier-command-line

so you would run
verifier.exe /driver.exclude HidGuardian.sys
then reboot.
note: you might consider adding this switch also:
/bootmode oneboot
this will do one boot with verifier on, then turn it off for the next boot. Saves you from having to go into safe mode and running verifier.exe /reset and rebooting.

you should not have to restore or repair windows if your turn off verifier with this command

note: cpu microcode update not installed. CPU bugs exposed
Click to expand...
I also just updated my BIOS.
 
johnbl said:
same bugcheck in HidGuardian.sys
you have to remove the driver or make verifier.exe exclude it.
I guess you could also download Microsoft autoruns64.exe and unselect the driver so it does not load. Then verifier will not bugcheck on it.
Click to expand...
I can't find a way to exclude HidGuardian. I decided to remove it from the Drivers folder and it disables all of the inputs on my PC after reboot.
 
HidGuardian isn't even listed in the drivers list on the verifier. I already tried the "verifier.exe /driver.exclude HidGuardian.sys" run command, and it still detects the HidGuardian driver.
 
I already did a system restore, which recovers the HidGuardian driver. When I went to the list of drivers settings on verifier, I manually added HidGuardian and ticked the box off.

I did a reboot, and now it detected a new BSOD error during bootup (SYSTEM_THREAD_EXCEPTION_NOT_HANDLED) instead of DRIVER_VERIFIER_DETECTED_VIOLATION.

So expect a new memory dump soon.
 
ok, the bugcheck shows a unexpected breakpoint
it happened early in the boot process.
there are errors in two logs
prm.sys which is a interface that lets you run programs directly from BIOS. I might go into bios and make sure you do not have some automatic overclocking set to run. Or a program that wants to tune your memory speed.

the second log with a bunch of errors was TPM.sys
trusted plateform module, most of the errors were related to not being able to find registry keys. You might see if you can update your tpm firmware or reset it to defaults.
check security processor troubleshooting, on my machine there is a option to clear the TPM. you can also update it but it will depend on the actual chip you have.

IntelPMT.sys was running. listed as
Intel Platform Monitoring Driver.
intelpep.sys
FileDescription: Intel Power Engine Plugin
did not expect it to be loaded.

there was error log from plug and play indicating not enough interrupt objects.
you might go into windows control panel, device manager then find the menu item to show hidden devices. then delete any greyed out entries that show up in the list.
I would also go into bios and change any setting then change it back and save. This was a old way of forcing a BIOS to rebuild the list of hardware/settings database that it sends to windows.
(maybe it will still work) If it does it should free up some resources that the bios thought it was using.
you might unplug devices you do not need.
ALSO: this could just be an artifact due to the fact that verifier is running.

note: debugger was not able to read standard bios info from dump
 
Last edited:
johnbl said:
ok, the bugcheck shows a unexpected breakpoint
it happened early in the boot process.
there are errors in two logs
prm.sys which is a interface that lets you run programs directly from BIOS. I might go into bios and make sure you do not have some automatic overclocking set to run. Or a program that wants to tune your memory speed.

the second log with a bunch of errors was TPM.sys
trusted plateform module, most of the errors were related to not being able to find registry keys. You might see if you can update your tpm firmware or reset it to defaults.
check security processor troubleshooting, on my machine there is a option to clear the TPM. you can also update it but it will depend on the actual chip you have.

IntelPMT.sys was running. listed as
Intel Platform Monitoring Driver.
intelpep.sys
FileDescription: Intel Power Engine Plugin
did not expect it to be loaded.

there was error log from plug and play indicating not enough interrupt objects.
you might go into windows control panel, device manager then find the menu item to show hidden devices. then delete any greyed out entries that show up in the list.
I would also go into bios and change any setting then change it back and save. This was a old way of forcing a BIOS to rebuild the list of hardware/settings database that it sends to windows.
(maybe it will still work) If it does it should free up some resources that the bios thought it was using.
you might unplug devices you do not need.
ALSO: this could just be an artifact due to the fact that verifier is running.

note: debugger was not able to read standard bios info from dump
Click to expand...
I simply cleared the TPM, and that actually fixed the problem. My PC was running normally for three days straight. However, when I decided to reboot for updates, during the restart screen, I got a REFERENCE_BY_POINTER BSOD.

I sometimes get that BSOD when I reboot or shutdown my PC.
 
You must log in or register to reply here.

TRENDING THREADS

Latest posts

Moderators online

Share this page

COMPANY
RESOURCES
FOLLOW
Top Bottom