I frequently get BSOD

[giraykoc]

I get BSOD and OS keeps crashing since I bought my pc in 2015. Now it's so frequent for 2-3 days. I did memtest and memories are ok. Today I did chdsk even during chdsk I get BSOD but I tried again and got results. I think my harddisk is ok too because there's no bad sector. Please check it out the results


Checking file system on C:
The type of the file system is NTFS.

A disk check has been scheduled.
Windows will now check the disk.

CHKDSK is verifying files (stage 1 of 5)...
221440 file records processed. File verification completed.
1022 large file records processed. 0 bad file records processed. 2 EA records processed. 52 reparse records processed. CHKDSK is verifying indexes (stage 2 of 5)...
290448 index entries processed. Index verification completed.
0 unindexed files scanned. 0 unindexed files recovered. CHKDSK is verifying security descriptors (stage 3 of 5)...
221440 file SDs/SIDs processed. Cleaning up 284 unused index entries from index $SII of file 0x9.
Cleaning up 284 unused index entries from index $SDH of file 0x9.
Cleaning up 284 unused security descriptors.
Security descriptor verification completed.
34505 data files processed. CHKDSK is verifying Usn Journal...
33847288 USN bytes processed. Usn Journal verification completed.
CHKDSK is verifying file data (stage 4 of 5)...
221424 files processed. File data verification completed.
CHKDSK is verifying free space (stage 5 of 5)...
29026058 free clusters processed. Free space verification is complete.
CHKDSK discovered free space marked as allocated in the volume bitmap.
Windows has made corrections to the file system.

234326015 KB total disk space.
117789572 KB in 167231 files.
102684 KB in 34506 indexes.
0 KB in bad sectors.
329523 KB in use by the system.
65536 KB occupied by the log file.
116104236 KB available on disk.

4096 bytes in each allocation unit.
58581503 total allocation units on disk.
29026059 allocation units available on disk.

Internal Info:
00 61 03 00 13 14 03 00 bd c7 05 00 00 00 00 00 .a..............
de 01 00 00 34 00 00 00 00 00 00 00 00 00 00 00 ....4...........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

Windows has finished checking your disk.
Please wait while your computer restarts.

What can cause this so much BSOD ? I installed BlueScreenView and mostly caused by ntoskernel.exe and ntfs.sys.

Here is the dump files
http://

 

[jsmithepa]

Then it's time to do a fresh OS reload.

 

[giraykoc]

Then it's time to do a fresh OS reload.

Thanks for your advice but this is not a solution for me. I need to find out root of the problem.

 

[johnbl]

well the bugcheck in a power state, basically I think a drive got disconnected and it power request was never completed. the system waited 258 second and called a bugcheck.

you should check your power and data cables to your storage devices.

for windows 7 most of these power states were turned off by default, but with windows 8.x and windows 10 they are turned on by default. So now, when people update drivers they sometimes get these functions turned on. generally, this is not a problem if you have updated the bios to the current version and also update the motherboard drivers.

I can not debug the problem with a minidump since it does not contain info for the hardware or the plug and play subsystem.

most of this is from the stack trace and this function Wdf01000!FxPkgFdo::_PnpSurpriseRemoval

check the cables to the drive, if they are ok, check the bios and see if there is a setting for hotswap for the sata port the drive is on. it should be enabled, so if the drive is disconnected then it can reconnect.
(it is not ideal but it prevents the bugcheck)

since you have windows 7 which does not do low level fixes to the drive like windows 8 and windows 10
you will want to download and run crystaldiskinfo.exe to see if your drive is having problems.

you might also update the sata driver (cpu chipset and external SATA chipset drivers from the motherboard vendor)

sometimes if you move the data cable onto a different sata port it can prevent the problem. the most reliable sata ports are going to be the ones supported by the cpu chipset (generally the slower one)

some machines have to have the bios match the sata drivers from the motherboard website.

you might be able to prevent the problem if you set your drives to never sleep. (but it does not explain the disconnection problem)

if you continue to have problems, you will want to change the memory dump type from minidump to a kernel memory dump. then provide the larger kernel dump file c:\windows\memory.dmp

this will contain the internal error logs and will show what was goin on with all of the cores as well as info on what plug and play was trying to do when the system crashed. It will name the actual device also, so we will not have to guess.

the debugger was unable to read the bios info, this might indicate a old bios installed.

 

[giraykoc]

well the bugcheck in a power state, basically I think a drive got disconnected and it power request was never completed. the system waited 258 second and called a bugcheck.

you should check your power and data cables to your storage devices.

for windows 7 most of these power states were turned off by default, but with windows 8.x and windows 10 they are turned on by default. So now, when people update drivers they sometimes get these functions turned on. generally, this is not a problem if you have updated the bios to the current version and also update the motherboard drivers.

I can not debug the problem with a minidump since it does not contain info for the hardware or the plug and play subsystem.

most of this is from the stack trace and this function Wdf01000!FxPkgFdo::_PnpSurpriseRemoval

check the cables to the drive, if they are ok, check the bios and see if there is a setting for hotswap for the sata port the drive is on. it should be enabled, so if the drive is disconnected then it can reconnect.
(it is not ideal but it prevents the bugcheck)

since you have windows 7 which does not do low level fixes to the drive like windows 8 and windows 10
you will want to download and run crystaldiskinfo.exe to see if your drive is having problems.

you might also update the sata driver (cpu chipset and external SATA chipset drivers from the motherboard vendor)

sometimes if you move the data cable onto a different sata port it can prevent the problem. the most reliable sata ports are going to be the ones supported by the cpu chipset (generally the slower one)

some machines have to have the bios match the sata drivers from the motherboard website.

you might be able to prevent the problem if you set your drives to never sleep. (but it does not explain the disconnection problem)

if you continue to have problems, you will want to change the memory dump type from minidump to a kernel memory dump. then provide the larger kernel dump file c:\windows\memory.dmp

this will contain the internal error logs and will show what was goin on with all of the cores as well as info on what plug and play was trying to do when the system crashed. It will name the actual device also, so we will not have to guess.

the debugger was unable to read the bios info, this might indicate a old bios installed.

Thanks man for your detailed answer. As you said I checked the cables and didn't see any disconnection or unsual thing. I moved the power cable to another sata port though. After that I checked the bios. There was no hotswap setting but there was hot plug setting that I don't know if these are the same thing nevertheless I enabled it. Today I didn't get any BSOD so far. I hope they don't appear again. Thanks again.

 

[johnbl]

hot plug should be the same as hot swap. it will allow a drive to reconnect if it gets disconnected for some reason.
if a drive gets errors or does not respond for 30 seconds windows will try to reset the drive, this will make it disconnect and normally it would just reconnect and all would be ok. (you still have to figure out why it disconnected)
sometimes cables are loose and jsut a fan vibration can make and break the connection.
sectors going bad can also cause the problem. bugs in data drivers also. it is hard to tell. run crystaldiskinfo.exe to read the smart data from the drive to get an idea of if it is having errors.

well the bugcheck in a power state, basically I think a drive got disconnected and it power request was never completed. the system waited 258 second and called a bugcheck.

you should check your power and data cables to your storage devices.

for windows 7 most of these power states were turned off by default, but with windows 8.x and windows 10 they are turned on by default. So now, when people update drivers they sometimes get these functions turned on. generally, this is not a problem if you have updated the bios to the current version and also update the motherboard drivers.

I can not debug the problem with a minidump since it does not contain info for the hardware or the plug and play subsystem.

most of this is from the stack trace and this function Wdf01000!FxPkgFdo::_PnpSurpriseRemoval

check the cables to the drive, if they are ok, check the bios and see if there is a setting for hotswap for the sata port the drive is on. it should be enabled, so if the drive is disconnected then it can reconnect.
(it is not ideal but it prevents the bugcheck)

since you have windows 7 which does not do low level fixes to the drive like windows 8 and windows 10
you will want to download and run crystaldiskinfo.exe to see if your drive is having problems.

you might also update the sata driver (cpu chipset and external SATA chipset drivers from the motherboard vendor)

sometimes if you move the data cable onto a different sata port it can prevent the problem. the most reliable sata ports are going to be the ones supported by the cpu chipset (generally the slower one)

some machines have to have the bios match the sata drivers from the motherboard website.

you might be able to prevent the problem if you set your drives to never sleep. (but it does not explain the disconnection problem)

if you continue to have problems, you will want to change the memory dump type from minidump to a kernel memory dump. then provide the larger kernel dump file c:\windows\memory.dmp

this will contain the internal error logs and will show what was goin on with all of the cores as well as info on what plug and play was trying to do when the system crashed. It will name the actual device also, so we will not have to guess.

the debugger was unable to read the bios info, this might indicate a old bios installed.

Thanks man for your detailed answer. As you said I checked the cables and didn't see any disconnection or unsual thing. I moved the power cable to another sata port though. After that I checked the bios. There was no hotswap setting but there was hot plug setting that I don't know if these are the same thing nevertheless I enabled it. Today I didn't get any BSOD so far. I hope they don't appear again. Thanks again.

 

[giraykoc]

hot plug should be the same as hot swap. it will allow a drive to reconnect if it gets disconnected for some reason.
if a drive gets errors or does not respond for 30 seconds windows will try to reset the drive, this will make it disconnect and normally it would just reconnect and all would be ok. (you still have to figure out why it disconnected)
sometimes cables are loose and jsut a fan vibration can make and break the connection.
sectors going bad can also cause the problem. bugs in data drivers also. it is hard to tell. run crystaldiskinfo.exe to read the smart data from the drive to get an idea of if it is having errors.

well the bugcheck in a power state, basically I think a drive got disconnected and it power request was never completed. the system waited 258 second and called a bugcheck.

you should check your power and data cables to your storage devices.

for windows 7 most of these power states were turned off by default, but with windows 8.x and windows 10 they are turned on by default. So now, when people update drivers they sometimes get these functions turned on. generally, this is not a problem if you have updated the bios to the current version and also update the motherboard drivers.

I can not debug the problem with a minidump since it does not contain info for the hardware or the plug and play subsystem.

most of this is from the stack trace and this function Wdf01000!FxPkgFdo::_PnpSurpriseRemoval

check the cables to the drive, if they are ok, check the bios and see if there is a setting for hotswap for the sata port the drive is on. it should be enabled, so if the drive is disconnected then it can reconnect.
(it is not ideal but it prevents the bugcheck)

since you have windows 7 which does not do low level fixes to the drive like windows 8 and windows 10
you will want to download and run crystaldiskinfo.exe to see if your drive is having problems.

you might also update the sata driver (cpu chipset and external SATA chipset drivers from the motherboard vendor)

sometimes if you move the data cable onto a different sata port it can prevent the problem. the most reliable sata ports are going to be the ones supported by the cpu chipset (generally the slower one)

some machines have to have the bios match the sata drivers from the motherboard website.

you might be able to prevent the problem if you set your drives to never sleep. (but it does not explain the disconnection problem)

if you continue to have problems, you will want to change the memory dump type from minidump to a kernel memory dump. then provide the larger kernel dump file c:\windows\memory.dmp

this will contain the internal error logs and will show what was goin on with all of the cores as well as info on what plug and play was trying to do when the system crashed. It will name the actual device also, so we will not have to guess.

the debugger was unable to read the bios info, this might indicate a old bios installed.

Thanks man for your detailed answer. As you said I checked the cables and didn't see any disconnection or unsual thing. I moved the power cable to another sata port though. After that I checked the bios. There was no hotswap setting but there was hot plug setting that I don't know if these are the same thing nevertheless I enabled it. Today I didn't get any BSOD so far. I hope they don't appear again. Thanks again.

I ran crystaldiskinfo and here are the results

 

[johnbl]

since the drive is a ssd, you should look at the firmware version and see if there is a update that you should install.
there are cases where firmware can get behind in its internal clean up routines (garbage collection) and cause a delay, if the delay last longer than 30 seconds then window tries to reset the device and you would have gotten the bughcek because of the hot swap setting in bios.

generally a ssd gets behind if it runs out of space or if the device sleeps all of the time. these functions kick in when the drive is idle for 5 minutes and will run until the device sleeps. Many are set to sleep after 5 or 10 minutes.
often if you just go into bios and leave the machine on it gives the drive time to do its internal repairs. some drives have firmware updates for bugs that delayed the cleanup.

hot plug should be the same as hot swap. it will allow a drive to reconnect if it gets disconnected for some reason.
if a drive gets errors or does not respond for 30 seconds windows will try to reset the drive, this will make it disconnect and normally it would just reconnect and all would be ok. (you still have to figure out why it disconnected)
sometimes cables are loose and jsut a fan vibration can make and break the connection.
sectors going bad can also cause the problem. bugs in data drivers also. it is hard to tell. run crystaldiskinfo.exe to read the smart data from the drive to get an idea of if it is having errors.

well the bugcheck in a power state, basically I think a drive got disconnected and it power request was never completed. the system waited 258 second and called a bugcheck.

you should check your power and data cables to your storage devices.

for windows 7 most of these power states were turned off by default, but with windows 8.x and windows 10 they are turned on by default. So now, when people update drivers they sometimes get these functions turned on. generally, this is not a problem if you have updated the bios to the current version and also update the motherboard drivers.

I can not debug the problem with a minidump since it does not contain info for the hardware or the plug and play subsystem.

most of this is from the stack trace and this function Wdf01000!FxPkgFdo::_PnpSurpriseRemoval

check the cables to the drive, if they are ok, check the bios and see if there is a setting for hotswap for the sata port the drive is on. it should be enabled, so if the drive is disconnected then it can reconnect.
(it is not ideal but it prevents the bugcheck)

since you have windows 7 which does not do low level fixes to the drive like windows 8 and windows 10
you will want to download and run crystaldiskinfo.exe to see if your drive is having problems.

you might also update the sata driver (cpu chipset and external SATA chipset drivers from the motherboard vendor)

sometimes if you move the data cable onto a different sata port it can prevent the problem. the most reliable sata ports are going to be the ones supported by the cpu chipset (generally the slower one)

some machines have to have the bios match the sata drivers from the motherboard website.

you might be able to prevent the problem if you set your drives to never sleep. (but it does not explain the disconnection problem)

if you continue to have problems, you will want to change the memory dump type from minidump to a kernel memory dump. then provide the larger kernel dump file c:\windows\memory.dmp

this will contain the internal error logs and will show what was goin on with all of the cores as well as info on what plug and play was trying to do when the system crashed. It will name the actual device also, so we will not have to guess.

the debugger was unable to read the bios info, this might indicate a old bios installed.

Thanks man for your detailed answer. As you said I checked the cables and didn't see any disconnection or unsual thing. I moved the power cable to another sata port though. After that I checked the bios. There was no hotswap setting but there was hot plug setting that I don't know if these are the same thing nevertheless I enabled it. Today I didn't get any BSOD so far. I hope they don't appear again. Thanks again.

I ran crystaldiskinfo and here are the results

 

[giraykoc]

since the drive is a ssd, you should look at the firmware version and see if there is a update that you should install.
there are cases where firmware can get behind in its internal clean up routines (garbage collection) and cause a delay, if the delay last longer than 30 seconds then window tries to reset the device and you would have gotten the bughcek because of the hot swap setting in bios.

generally a ssd gets behind if it runs out of space or if the device sleeps all of the time. these functions kick in when the drive is idle for 5 minutes and will run until the device sleeps. Many are set to sleep after 5 or 10 minutes.
often if you just go into bios and leave the machine on it gives the drive time to do its internal repairs. some drives have firmware updates for bugs that delayed the cleanup.

hot plug should be the same as hot swap. it will allow a drive to reconnect if it gets disconnected for some reason.
if a drive gets errors or does not respond for 30 seconds windows will try to reset the drive, this will make it disconnect and normally it would just reconnect and all would be ok. (you still have to figure out why it disconnected)
sometimes cables are loose and jsut a fan vibration can make and break the connection.
sectors going bad can also cause the problem. bugs in data drivers also. it is hard to tell. run crystaldiskinfo.exe to read the smart data from the drive to get an idea of if it is having errors.

well the bugcheck in a power state, basically I think a drive got disconnected and it power request was never completed. the system waited 258 second and called a bugcheck.

you should check your power and data cables to your storage devices.

for windows 7 most of these power states were turned off by default, but with windows 8.x and windows 10 they are turned on by default. So now, when people update drivers they sometimes get these functions turned on. generally, this is not a problem if you have updated the bios to the current version and also update the motherboard drivers.

I can not debug the problem with a minidump since it does not contain info for the hardware or the plug and play subsystem.

most of this is from the stack trace and this function Wdf01000!FxPkgFdo::_PnpSurpriseRemoval

check the cables to the drive, if they are ok, check the bios and see if there is a setting for hotswap for the sata port the drive is on. it should be enabled, so if the drive is disconnected then it can reconnect.
(it is not ideal but it prevents the bugcheck)

since you have windows 7 which does not do low level fixes to the drive like windows 8 and windows 10
you will want to download and run crystaldiskinfo.exe to see if your drive is having problems.

you might also update the sata driver (cpu chipset and external SATA chipset drivers from the motherboard vendor)

sometimes if you move the data cable onto a different sata port it can prevent the problem. the most reliable sata ports are going to be the ones supported by the cpu chipset (generally the slower one)

some machines have to have the bios match the sata drivers from the motherboard website.

you might be able to prevent the problem if you set your drives to never sleep. (but it does not explain the disconnection problem)

if you continue to have problems, you will want to change the memory dump type from minidump to a kernel memory dump. then provide the larger kernel dump file c:\windows\memory.dmp

this will contain the internal error logs and will show what was goin on with all of the cores as well as info on what plug and play was trying to do when the system crashed. It will name the actual device also, so we will not have to guess.

the debugger was unable to read the bios info, this might indicate a old bios installed.

Thanks man for your detailed answer. As you said I checked the cables and didn't see any disconnection or unsual thing. I moved the power cable to another sata port though. After that I checked the bios. There was no hotswap setting but there was hot plug setting that I don't know if these are the same thing nevertheless I enabled it. Today I didn't get any BSOD so far. I hope they don't appear again. Thanks again.

I ran crystaldiskinfo and here are the results

Nothing has changed, today I got a new BSOD. This is really frustrating. I updated firmware let's see if it will be ok.

 

[giraykoc]

well the bugcheck in a power state, basically I think a drive got disconnected and it power request was never completed. the system waited 258 second and called a bugcheck.

you should check your power and data cables to your storage devices.

for windows 7 most of these power states were turned off by default, but with windows 8.x and windows 10 they are turned on by default. So now, when people update drivers they sometimes get these functions turned on. generally, this is not a problem if you have updated the bios to the current version and also update the motherboard drivers.

I can not debug the problem with a minidump since it does not contain info for the hardware or the plug and play subsystem.

most of this is from the stack trace and this function Wdf01000!FxPkgFdo::_PnpSurpriseRemoval

check the cables to the drive, if they are ok, check the bios and see if there is a setting for hotswap for the sata port the drive is on. it should be enabled, so if the drive is disconnected then it can reconnect.
(it is not ideal but it prevents the bugcheck)

since you have windows 7 which does not do low level fixes to the drive like windows 8 and windows 10
you will want to download and run crystaldiskinfo.exe to see if your drive is having problems.

you might also update the sata driver (cpu chipset and external SATA chipset drivers from the motherboard vendor)

sometimes if you move the data cable onto a different sata port it can prevent the problem. the most reliable sata ports are going to be the ones supported by the cpu chipset (generally the slower one)

some machines have to have the bios match the sata drivers from the motherboard website.

you might be able to prevent the problem if you set your drives to never sleep. (but it does not explain the disconnection problem)

if you continue to have problems, you will want to change the memory dump type from minidump to a kernel memory dump. then provide the larger kernel dump file c:\windows\memory.dmp

this will contain the internal error logs and will show what was goin on with all of the cores as well as info on what plug and play was trying to do when the system crashed. It will name the actual device also, so we will not have to guess.

the debugger was unable to read the bios info, this might indicate a old bios installed.

I'm not sure but I think it's solved. I haven't had any BSOD for more than one week. I was about to change the psu. I removed all cables and I realized that power cable of the SSD was under pressure and bented. So I changed that power cable of SSD with another. For now it seems problem is solved. Thank you man for guiding.