HDS not opening when drive busy

[VGER]

Hi,

sometimes HD-Sentinel, which is running on the system while "minimized to tray", won't open by clicking on the tray icon. Not even the context menu of the tray icon will come up. This is apparently the case when the hard drive is busy at the time. Usually, HDS (or the context menu) will come up by itself at some later time, but it may be minutes.

I suppose HDS is checking something about the drive which only works when the drive is idle. If it isn't for a while, then the query doesn't complete, and HDS doesn't come up.

Is there a way to avoid this? HDS should always come up immidiatly, even if the drives can't be checked right now. Often I only want to take a look at e.g. the temperature graph and don't care if the latest reading that should have been taken right now is not yet included.

Regards,
VGER

[hdsentinel]

Hi,

I completely agree that there should be no such delays (especially so long). I suspect it may be caused by a minor compatibility issue.

If possible, please use the Report menu Send test report to developer option. This way I can examine the detected information (hard disks, controllers, detection times) so I can check what is causing this slowness.

Thanks!

[VGER]

Hi,

I've neglected this problem for a while because I saw it on different machines, and not only with HD-Sentinel, but also with other tools that were trying to access lower level HDD data. For example, the GUI of a defrag program has the same problem - if the disk is busy, the GUI will start, but not show any drives and after some time display a timeout error before aborting.

Still, the problem is more difficult with HD-Sentinel: Usually I want to invoke HDS at exactly that time there is something non-nominal. For example, if the system is getting sluggish, I want to check whether that disk has been developing bad data over the last few minutes, or how busy it had been up until now. It's not good if the program doesn't even start in that case.

Is there any way the data-retrieve tasks could be seperated from the GUI-tasks, so that at least recent data could be displayed, even if requests for current data are timing out or are delayed?

Regards,
VGER

[hdsentinel]

The issue is more complex.
I suspect the problem may be that the hard disk head was moving to one or more sectors which are not perfect and need to be examined or even re-allocated. During this procedure the whole disk subsystem may seem to be frozen and software wants to access any data on the disk may seem to be stuck.
As you could see, this may be related to any software (eg. defrag program) or even any software which may want to read back a temporary file or get some information back from the swapfile - as these both require disk

Yes, it is possible to separate the detection from the GUI functions (it is done of course) but if the software just wants to perform any disk operation (which may not be the disk information detection) it may become unresponsible on a such hard disk with some problems.

It's not good if the program doesn't even start in that case.

I completely agree. But if the whole disk subsystem is stopped for some reason, no activity (eg. reading previous configuration. loading its GUI) is possible so the software can't open at all, regardless of the disk status information detection.

Sometimes this is caused by older drivers for the disk controller, especially with some eSATA controllers after plugging disks to the system. Installing newer drivers for such disk controllers may improve the situation.