Author
Topic: Hard Disk Sentinel PRO - Mini-Review (Read 42581 times)

One thing that becomes clear reading thro' the above is that most of you have avery good technical grasp of your computers & associated hardware etc.My objection TO HDSPro is that the process of setting the configuration for your own application is a very significant task & I became weary of all the tech stuff I had to consider just to do a half pie job of configuring.For example you can arrange an eamail warning to yourself - not a bad idea - but how many of us can quickly do that - not me, it would take me some time to find the relevent info.I could go on but in truth I have no degree of certainty that what I have done will be effective or at least as effctive as possible - this is not good.I think a set of default configuration options should be inbuilt to cater for lesser mortals.Also the above identifies a bug - what's the response from the authors?

Oops, I don't think we had identified a bug in HDS.There were only two things I can think of that you might be referring to:

Case studies: The developer (Janos) at Hard Disk Sentinel sent me a link to some cases of problems discovered using HDS (that means examples/logs of hard drive problems which HDS has discovered on users' computers):They are under Support -> Knowledge base -> Hard disk cases, here: http://www.hdsentine.../hard_disk_cases.php

Real-time performance monitoring: Registry settings necessary to enable this are not set by HDS, the user has to set them. When I set them, they were not sticking, so real-time performance monitoring in HDS was not enabled, or kept being disabled. I gave a quick ad hoc registry fix for it - documented in the opening post. Something - and I don't see how it could be HDS - is occasionally clearing the registry settings that enable this - they are not "sticky" at any rate. I suspect (but have no proof) that it might be CCleaner as that also seems to be responsible for occasionally knocking out the registry settings affecting xplorer² on my laptop. (I have a quick ad hoc registry fix for that too.)

It looks as though the real-time performance monitoring registry settings, necessary for enabling HDS Pro's disk performance monitoring, appear to be getting deleted under these specific circumstances:

the laptop disk powers-down (part of battery power conservation scheme);

the laptop goes into "sleep" or other inactive mode;

the laptop is rebooted.

CCleaner does not so far appear to be implicated.

I suspect that this may be a laptop-only issue and that PCs (as opposed to laptops with battery power conservation settings) would not suffer from these effects.

Hooray! This seems to be an effective fix to the episodic real-time performance monitoring issue:(for more info., refer HDS FAQ page http://www.hdsentinel.com/faq.php)

The real time performance monitoring worked per the Registry settings workaround (see earlier edit below), but after some time (for example after connecting/removing external hard disk, pendrive or similar storage device) it stopped working and I periodically had to reset the Registry settings - i.e., the Registry settings change did not "stick". This was apparently caused by a function in HDS which provides for performance monitoring when a new device - e.g., an external hard disk - is connected/detected. When this happens, Hard Disk Sentinel has a function that clears the performance object cache and re-detects the performance objects. On some systems (regardless of hardware configuration) this function apparently causes the Windows performance monitoring settings in the Registry to be disabled.

If this happens, you can disable this HDS function as follows:

1. click "start" (Windows) button and to the search field enter REGEDIT

2. open REGEDIT

3. navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\HD Sentinel (or HKEY_LOCAL_MACHINE\SOFTWARE\HD Sentinel under 32 bit Windows), where you will see a lot of keys.

4. create a new STRING key named DisablePerfCacheClear and specify a value of 1 for that.

Then restart HDS, which now will not issue this special function to clear the performance object cache when it detects the change of configuration, so the performance counters will continue working normally - once reset in the Registry. Those Registry settings should now "stick" and not need to be reset again.

Just to make a note that the new registry fix (DisablePerfCacheClear) to enable real-time performance monitoring to persist, as described in the EDIT 2012-09-17:, in the opening post, has worked fine. It does persist, and is stable and is still working effectively a few months on.It has not been undone even after having gone through several critical Microsoft Windows Updates (Win7-64 Home Premium), so I guess the fix is as good as permanent. The previous registry fixes to enable the real-time performance monitoring did not persist - they kept getting cleared in an ad hoc manner by the Disk Performance Cache being cleared by HDS, often after Microsoft Windows Updates and/or the registry being cleaned by CCleaner runs.

I distinctly recall at some stage banging the laptop accidentally against a door-jamb whilst moving it when it was still switched on. (Thus breaking one of my own rules about not carrying about an active laptop.) I also recall knocking it on my lap and nearly dropping it (whilst moving out of the baby's way.)The analysis shows that a G-Sense event occurred around the date of the non-critical but unrepairable event #197 (Current pending sector count) appearing in the log. So, it looks like I did could have done this one myself. Sheesh.

Update 2015-01-17 0614hrs: Hard Drive Sentinel is now up to version 4.60 (7377). I forgot to post about this when it updated a short while back.In the OP, I have made minor updates to version number and supported OSes.

I wondered whether any of the wise denizens of DC might be able to offer some advice.I am trying to figure out the best method and thermometer to use to recalibrate the temperature sensor on a hard drive. My drives are all 2.5" format drives, either housed in a laptop or in a USB-connected device enclosure, and some of the latter are sealed plastic enclosures and thus difficult to gain access to without risking breaking the enclosure.

I have come to the conclusion that the reported temps on some of the drives I use are inaccurate. Some feel hotter to the touch than others that HDS says are running at a higher temp.

The HDS Temperature report tab says:

It is recommended to calibrate the temperature and set the temperature offset on the S.M.A.R.T. page. This way later the correct temperature value will be displayed.____________________________________

The HDS Help document says:

Temperature calibrationThe temperature sensor built in most modern hard disks may give improper results. The difference between the measured and the actual temperature can be 7-9 Celsius degress or even more.

To fix this problem, it is possible (and recommended) to measure the actual temperature of the hard disk by using an external infrared thermometer or a front panel with temperature sensor and set the difference between the measured temperature and the temperature displayed by Hard Disk Sentinel (reported by the drive itself) as temperature offset. This is called calibration.

After the real temperature has measured (by the thermometer or other external temperature sensor), the offset can be calculated by subtracting the value reported by the software from the measured value. This offset can be positive (the software reports smaller temperature than the real) or negative (the software reports higher temperature than the real).

This offset can be specified on the S.M.A.R.T. page of the hard disk, after selecting attribute #194 (hard disk temperature) and using the + / - buttons (by clicking on the number between the icons, the offset value can be entered directly in Celsius units).

(Diagram: S.M.A.R.T. attributes, details and trends)

Hard Disk Sentinel will automatically increase (or decrease) all hard disk reported temperatures by the configured offset value. This way the correct (real) temperature will be displayed and used in all cases (for example, when checking hard disk temperature against a threshold and when saving reports etc.)

It is recommended to perform the temperature calibration on all installed hard disks if possible. Same type of hard disks may require different temperature offsets.

Note: if the calibration is not possible (the computer chassis cannot be opened), an estimated offset value can be determined by checking the first displayed temperature immediately after starting the computer and comparing the value with the environment (room, office) temperature. At this time, the CPU, video card or other components are not too warm and they do not affect the temperature of the hard disk. Of course this is true only if the computer had enough time to cool down to the environment temperature (it was not powered off for at least 8 hours).

For example, if the hard disk temperature is displayed as 17 Celsius degrees (immediately after starting the computer) and the room temperature is 22 Celsius degrees, +5 can be configured as offset value (because the hard disk cannot be cooler than its temperature). This offset is better than nothing but of course an external thermometer is needed to determine the proper temperature offset value.

Note: the temperature offset should be specified in Celsius units, regardless of the selected temperature unit (Celsius or Fahrenheit).

Note: the unregistered version automatically resets all offset values to 0 when the user restarts Hard Disk Sentinel.

Not much to suggest other than to say S.M.A.R.T. isn't a tool that gets relied on for absolute accuracy since it's less a real-time monitor and more a "heads-up" warning system that may help you predict immanent disk failure or help diagnose oddball conditions that suggest you're heading towards one.

In practice, I've generally found SMART is not all that useful on the user level. Because by the time the OS becomes concerned enough to forward a SMART-based alert to the user, it's pretty much too late anyway. I'm guessing the drive manufacturers probably make better use it for QC purposes and as a 'failure validation' tool when customers make warranty claims.

I'm not sure what your goal is by recalibrating the temperature sensor. If it's for intellectual curiosity or a learning experience, that's fine. If it's to get longer drive life, you might want to consider that some recent studies seem to have concluded thermal fatigue and high operating temperatures are nowhere near as much a contributing factor to drive failure as we once suspected. The bulk of the failures seem to occur for mechanical and electrical reasons unrelated to heat.

The excess heat generated by a hot drive can however potentially damage surrounding components, so it's probably not correct to simply dismiss hot running drives as "not a problem" in every circumstance.

I don't know if HDS is definitely "on" to an unaddressed problem - or if it's more something they're recommending simply because their product can do it. You'll get a lot of that with some utilities out there. But I don't have sufficient experience with HDS to make a call ...and I've never once heard of anybody manually recalibrating a drive's temperature sensor like that...sooo I guess I'll have to wait to hear how you made out if you decide to go ahead.

I'm puzzled by this: this is for a Seagate USB 2.0 external hard drive (1TB).HDS says the disk is in perfect condition, but these SMART Raw Read and Seek Error Rates from HDS look confusing to me.What is going on with this drive?

I'm not sure it's worth looking at the RRER unless you find that the HDD is repeatedly taking to long to serve some data.

I have 1 x WD, 2 x Samsung, 1 x Seagate HDDs, and 1 x Sandisk SSD in my machine - only the Seagate and Sandisk report anything other than zero for RRER and they are the youngest of the HDDs.

The Samsung's and the WD are each 5+y.o., the Seagate ~3 y.o., and the SSD ~3y.o.

Maybe it's better to just use the same metrics that BackBlaze use unless you notice there is a problem with data communication for the HDD.

SMART stats are inconsistent from hard drive to hard drive.

Addendum: On another machine I've got a Seagate 500LT012 (2.5" HDD) that is less than a month old, it reports 34024025 for RRER. It also has a Sandisk SSD that is about 2y.o. which doesn't report RRER at all.

I think the comment above from the BackBlaze blog is pretty much spot on.

@4wd: Yes, I had come to the same conclusions as you seem to have done. There are some notes on the HDS site that indicate (in rather tortured English) more or less what the BackBlaze comment says (which I had not seen, so thanks for the link).

I think I may have deduced what those two SMART charts mean:

The SER (Seek Error Rate): the chart seems to be a graph over time showing when a Seek Error occurred and what the accumulated seek counter stood at, at that point.

The RRER (Raw Read Error Rate): the chart seems to be a graph over time showing when a Raw Read Error occurred and what the incremental read counter (reads since last error) stood at, at that point.

Explanation: Thus, we have, after an extended period of apparently improving stability/reliability (reducing frequency of errors), a second Seek/Raw Read error occurring on 2015-03-20 relatively soon after the last/preceding error, and then a third occurring relatively soon after the second.

We probably won't be able to establish what caused the errors, but I shall examine the Windows Events logs to see if anything shows there. However, we can see from the CHKDSK output (run after the SMART S/RR errors were charted) that CHKDSK:

corrected orphaned file errors, and found some unindexed files, in Stage 2.

corrected free space marked as allocated in the MFT, in Stage 3.

corrected free space marked as allocated in the volume bitmap, in Stage 3.

I don't know much about these things, but I would suppose that, if further S/RR errors occur within a short period, then there may be a problem causing reducing stability/reliability (i.e., increasing frequency of errors). Otherwise, the errors may be an improbable statistical coincidence, or the CHKDSK operation may have fixed something that could have been a causal problem of the errors, in (say) the file structure.So, it's probably a case of "wait and see".

Yesterday I downloaded, installed and ran Seagate's proprietary SeaTools software to check this (Seagate) disk, and it checked out with no problems on an "extended test" run - and Seagate's own instructions are that if it passes that test then there is unlikely to be anything wrong with the disk.I wouldn't have known about any of this at all if I had not had the HDS information charts showing the disk health status and the SE/RRE counters' data from that particular disk.

AOMEI Backupper seems to work very well. Made light work of my disk clone/backup - as described in the OP, "...a bombproof backup utility" - and this was in a situation where the failing hard drive was in a dynamically and progressively deteriorating state, even actually moving down 1% to 54% "health" status during the cloning process. It was so impressively good and trouble-free at what it does that I was inspired to write the mini-review in the OP. Disk cloning was "new territory" for me as I had never been in this position with a failing drive before, nor needed to make a disk clone before and was thus unfamiliar with the necessary process. AOMEI Backupper saved me from a potential major headache with that failing drive.Of course, I should not omit to mention the huge value in having HDS (Hard Disk Sentinel), which was what had first alerted me to the problem of the disk's deteriorating state and was monitoring and reporting on its declining health.Refer: Hard Disk Sentinel PRO - Mini-Review