"Critical_Process_Died" bsod when starting Hwinfo64

VictorVG said:
Balancewolf said:
If it helps, Hwinfo64 BSODs when it's detecting THE S.M.A.R.T sensors.
For test, please, download, unzip and run latest CrystalDiskInfo (portable, zip) - if this tool also can't recognize S.M.A.R.T. then is SSD driver is have bug or don't support this hardware.

Notes:

CrystalDiskInfo don't have built-in drivers and use only exists in to Your OS drivers eliminating the occurrence of the prerequisites for the emergence of critical kernel bugs (BSOD == kernel panic), and therefore can help to diagnose the cause.
Okay I'll give that a shot. Now I just have to start it up crystaldiskinfo, I don't have to necessarily use the program right?
 
VictorVG said:
Balancewolf said:
If it helps, Hwinfo64 BSODs when it's detecting THE S.M.A.R.T sensors.
For test, please, download, unzip and run latest CrystalDiskInfo (portable, zip) - if this tool also can't recognize S.M.A.R.T. then is SSD driver is have bug or don't support this hardware.

Notes:

CrystalDiskInfo don't have built-in drivers and use only exists in to Your OS drivers eliminating the occurrence of the prerequisites for the emergence of critical kernel bugs (BSOD == kernel panic), and therefore can help to diagnose the cause.
Okay so I just installed crystaldiskinfo and I was able to run it. I just had to start up the program right? Not use a particular feature of the program?

Here is a pic showing the results of my test running crystaldiskinfo: http://imgur.com/Lihwddi

Also, I checked Samsung Magician and it said I have the latest firmware for my 850 pro ssd.
 
In fact, this program and does not require installation - all settings are stored in DiskInfo.ini, and read data S.M.A.R.T. in ./Smart/<model>/<attrib>.csv - that is, in an easily readable form.

In your screenshot - just CristalDiskInfo could read data S.M.A.R.T. the problem is not in the SSD driver, rather it can cause the utilities if they put their drivers.

According to the resource device - as long as you choose a little more than 0,6% TWB (TWB for this drive 300 TB, recorded a little more than 2 TB) and the device still has a rewriting resource, but I would have suffered the same swap file in the initial section of fast HDD - there too intense recording capable of rapidly deplete resus record any SSD.
 
VictorVG said:
In fact, this program and does not require installation - all settings are stored in DiskInfo.ini, and read data S.M.A.R.T. in ./Smart/<model>/<attrib>.csv - that is, in an easily readable form.

In your screenshot - just CristalDiskInfo could read data S.M.A.R.T. the problem is not in the SSD driver, rather it can cause the utilities if they put their drivers.

According to the resource device - as long as you choose a little more than 0,6% TWB (TWB for this drive 300 TB, recorded a little more than 2 TB) and the device still has a rewriting resource, but I would have suffered the same swap file in the initial section of fast HDD - there too intense recording capable of rapidly deplete resus record any SSD.

So how does all that relate to my drive scan issue with Hwinfo64? I'm a little confused.
 
I'm afraid, this problem is quite difficult to track when the issue doesn't occur with Debug Mode enabled.
You might try to enable Drive Scan and disable the CSMI SAS Support option, but I'm not sure whether this will resolve the problem.
 
VictorVG said:
In fact, this program and does not require installation - all settings are stored in DiskInfo.ini, and read data S.M.A.R.T. in ./Smart/<model>/<attrib>.csv - that is, in an easily readable form.

In your screenshot - just CristalDiskInfo could read data S.M.A.R.T. the problem is not in the SSD driver, rather it can cause the utilities if they put their drivers.

According to the resource device - as long as you choose a little more than 0,6% TWB (TWB for this drive 300 TB, recorded a little more than 2 TB) and the device still has a rewriting resource, but I would have suffered the same swap file in the initial section of fast HDD - there too intense recording capable of rapidly deplete resus record any SSD.
Could it be possible that my Samsung ssd driver can only be read by the Samsung magician program and that's why Hwinfo64 is bsod'ing when it tries to read said driver? (if Hwinfo64 is truly trying to read my Samsung ssd driver that is). Also, can Hwinfo64 only handle a certain storage size when it comes to ssds?
 
Martin said:
I'm afraid, this problem is quite difficult to track when the issue doesn't occur with Debug Mode enabled.
You might try to enable Drive Scan and disable the CSMI SAS Support option, but I'm not sure whether this will resolve the problem.

Okay I'll give that a try. Is it better to have driver scan on and csmi sas support off? Or vice versa?
 
CSMI SAS is a subset of the Drive Scan. So if Driver Scan is disabled, that option has no meaning.
 
Martin said:
CSMI SAS is a subset of the Drive Scan. So if Driver Scan is disabled, that option has no meaning.

Okay, but is it alright to have just drive scan on and not csmi sas? Would I loose a great feature of Hwinfo64 by doing so?
 
It would be no problem if your drive is properly recognized and monitored.
CSMI-SAS is just one of the methods used to detect and access a drive.
 
Martin said:
It would be no problem if your drive is properly recognized and monitored.
CSMI-SAS is just one of the methods used to detect and access a drive.

Unfortunately, enabling drive scan in safe mode with csmi-sas disabled still got me the bsod when running Hwinfo64.
 
Back
Top