[How to solve] Unable to lock the disk for exclusive use

[kamcm]

Background:
When I try to do a surface write test with V5 pro version on my WIN7 desktop. I always got the " failed to lock the disk for exclusive use" Error, no matter the interface is eSata or USB3.0. However if I close the V5 and reopen the V4 immediately. I can do a surface write test. I knew after the surface write test is initial, those HDD partition will completely erased and I think nothing will occupied (locked) the disk anymore because there is no partition, no drive letter. I switch back to the V5 again and do a surface write test again with no partition existed. But the result is very interesting, I got the " failed to lock the disk for exclusive use" AGAIN. At first I think it's a bug in v5 and I just switch back to V4.


Finding:
Today, I put a brand new HDD on my eSata Docking and try to do a surface write test in v5 again. It showed up " failed to lock the disk for exclusive use" Error. The HDD is brand new, has no data in it, I just did a quick format and assigned an drive letter. I make an educated guess and decided to use safely remove to verify if the HDD is really occupied (Locked) by other application. The safely remove failed and I knew something lockup the HDD and make it unable to safely removed. I opened the Resource Monitor in task manager and try to find out if there is something interact with that HDD but I found Nothing. I switch back to V4 again and do a surface write test and it can run without any problem. I try the safely remove again while the partition is already deleted but the safely remove has failed. I think V4 has the capacity to do a surface write test when the drive is somehow occupied by other process while V5 cannot???


Solution:

Finally, I found a way to safely remove that drive and I can use the same method to solve the surface write test error in v5.
ALL I have to do is to create a new partition, assign a drive letter -> change a drive letter -> remove a drive letter -> assign a drive letter again. By doing this, I am able to safely remove that drive and do a surface write test error in v5 as well.
Anyway, I still cannot located the root of the problems. It's really odd, because when there is no partition , I can't understand what process will occupied (locked) the drive and I can't find any clue in Resource Monitor. I still had no idea why the "assign / change a drive letter" and "remove a drive letter" will finally able to unlock the drive but it worked for me.



Suggestion:
It would be great if hdsentinel can show up which process has locked the hdd when the surface write test has failed.

[kamcm]

Today I just having another " failed to lock the disk for exclusive use" Error.
I decided to use the Winternals Process Explorer to see if I can find any clue with it.

Unfortunately, it didn't found anything. Nothing is hooking to that drive letter.
[screenshot]
http://kamserver.com/upload/2017-9/pe.jpg

I immediately change the drive letter -> remove that drive letter -> assign a drive letter again", the error has gone and surface write test can go through.

IMHO, It's really interesting. If anyone know the possible root cause of this problem,

please let me know,

Thanks!

[hdsentinel]

Please use Report menu -> Send test report to developer option in the latest version of Hard Disk Sentinel Pro (5.01.7 if possible) when you experience such situation.

This way it would be possible to examine the actual situation, verify if something (maybe the disk controller, its driver or something else) is related and can cause such issue.

Tried to reproduce in the previous weeks, but found no cause. I would be happy to try, reproduce the issue and improve the situation in all possible ways.

You mentioned you found such with different drives, so the issue is not really related to one particular drive. Am I correct?
If so, did you see any pattern about which drives affected, what is common between them? For example, their model, firmware, capacity may be same and so?
If I'm correct, you found drives (connected similarly) where there were no such issues - so if I'm correct, the issue may be related to some combination (OS + disk controller + driver + hard disk drive). This is what would be nice to investigate, reproduce.

[hdsentinel]

Suggestion:
It would be great if hdsentinel can show up which process has locked the hdd when the surface write test has failed.

I completely agree - would be excellent.
Did lots of researching but as you could see ("I decided to use the Winternals Process Explorer to see if I can find any clue with it.") sometimes it is not really possible to determine what is in the background, even for applications designed exactly for this purpose
Personally (and as technical person) I agree that this is weird, personally I'd expect to see WHO is locking (if this is the case), but until now, found no 100% sure way for this. Still researching of course, hopefully in a later version, this area will be also improved.

[djlman]

Hi all - I had the same problem of "failed to lock the disk for exclusive use" with a brand new drive I wanted to test. I tried the remove/change. remove/change/, remove/change sequence but it did not work. What did work was removing the drive letter,leaving it removed and then running the destructive write/read test. Clearly one should not have to do this but it did work.

The drive is a 6TB Seagate USB 3.0 and I'm running HD Sentinel Pro 5.01

Hope this helps - djlman

[hdsentinel]

Sorry to say, but not really....
I also had a same problem: somebody reports some weird issue - but never sends developer report with the latest possible version, which can be used to examine what may happened.

As I wrote previously

Please try the latest version (5.01.9b now). Generally updated beta versions always designed with some minor changes which MAY make things better when there is an unknown, weird issue happens which could not be reproduced. When such issues reported, I always try to add extra protection, changing some behaviour and so.

Please use Report menu -> Send test report to developer option in the latest version of Hard Disk Sentinel Pro (5.01.9b if possible) when you experience such situation.

(this is what I recommended previously - just since that, 5.01.9b is the latest, not 5.01.7).

Generally your brand new drive surely had partition(s) (even hidden partitions) which could not be unmounted / locked before the test because of some file(s) or folder(s) open on them. Maybe an antivirus software you have immediately performed scan and/or lock the partition (?) not sure.
Otherwise (if there is no used file/folder) then there is absolutely no problem in locking - and then the test would start without problems.

As I could not reproduce the issue, all I can do is to ask to PLEASE send developer report - as that may hopefully give ideas why your device can't be locked and the write test can't be performed immediately.
To be honest personally I'm sure the change/remove is not a solution.

There can be solution to prevent this and forcing the test - just I worry that in this case there may be lots of complaints that (despite of the warnings) the users can overwrite/delete their storage drive(s) if they accidentaly select a wrong disk to perform write test. The current design at least prevents that.

[sg_user]

I've been a long-time user of Hard Disk Sentinel, coming up to 6 years or so.

Mostly it's been easy to use, had no problems with HDDs or SSDs. The only ever problem was with SD cards, when I tried the surface test (Re-Initialising and other Write tests). It would sometimes display - "Unable to lock the disk for exclusive use". It seems to be a version 5 problem. There were some earlier versions of Hard Disk Sentinel (for example - version 4.71) where it was usually possible to run this Destructive test for my SD cards.

At other times, in addition, I also had to remove the Drive letter. Like some other guy said to - "assign the Drive letter, then remove it and leave blank, then run the Destructive test".

Don't know why this is so. Hope this problem can be eventually fixed by Hard Disk Sentinel programmers.

[hdsentinel]

Thanks for your message and excuse me for the possible issue.

Sounds so interesting.
Generally there were lots of changes (improvements) since 4.71 in this field: both the 5.01 and also especially the latest 5.20 version has changes to prevent and generally minimise the amount of such "access denied" errors.

I say minimise because it is not really problem of Hard Disk Sentinel (any version) and generally it can (and will) happen with any version: when there are opened file(s) or folder(s) which may prevent dismount, then it is completely normal and expected that Windows prevents the write testing. This may result the "access denied" error.

Even if you did not have open file/folder, the SD card may contain a hidden file (saved by the camera if used there) or if just inserted, it is possible that antivirus software may examine it and so. There can be lots of causes which results that a file/folder is used and this results the "access denied" error.

> It seems to be a version 5 problem.

From this, I do not know which version you use: version 5.00, 5.01 or 5.20

In both versions (and especially in 5.20) there are lots of changes which attempt to prevent the above and uses other methods to dismount and perform the write test without the need to manually erase the drive letter or using other tricks.
So version 5.20 surely performs the write test better than 4.71

Please check version 5.20. I do not say that "access denied" will surely not occur with it - as the above (if any file / folder is in use) is true, then it will be also blocked. But it will be less likely blocked than 4.71

And we did not mention changes in Windows in these years: for example recent changes in Windows Defender can block write access completely. Also other installed applications / software may use the card (for example software provided for cameras to import images).

Please check with version 5.20 and if you encounter "access denied", please try to
- close all files/folders on the device
- verify if no antivirus performs scan or similar background activity on the card
and use Report menu -> Send test report to developer option. Such developer reports always help to check what may happened - and how things can be further improved.

I just started write / reinitialize disk surface test on several SD, CF cards in different capacities (2-64 GBytes) without problems: access denied never displayed, the write test started without problems.

Ideally we'd need a way where I can surely reproduce the issue. Then I can check how/what happens.
So if you have step-by-step instructions about how to reproduce (for example with xy card, reader, format / file system etc.) I'd be happy to check.

Also on the bottom of the Download page, you can any time download older versions if you prefer to compare the operation.
So if we can surely find a situation where the write test can be started with 4.71 but not with 5.20 version, I'd be happy to check and improve in all possible ways.

[Cauhauna]

Hello,

I just ran into this same issue, and I did submit a report as instructed. My email is similar to my username.

I was able to resolve this issue by going to disk manager in windows and completely deleting the disk.

Antivirus: Nod32 + MBAM - both paid/pro version with active filesystem protection.

[hdsentinel]

Thanks for your message and the report and excuse me for the troubles.

Yes, by this old version, it is possible. You have version 5.01 (displayed on the top and in the Help -> About box)
and since that, the write test improved (especially to address some recent changes in Windows which caused the troubles).

So please use the automatic update from File menu to get the latest 5.30 version, by that, there
should be no such issues. The update keeps all settings, statistics, logs, license - just updates the program itself.

[hdsentinel]

See the revision of updated version:
( https://www.hdsentinel.com/revision520.php )
improved WRITE testing (Surface test -> Write test, Write+Read, Reinitialise disk surface) to prevent "access denied" error