Hey guys! Please, help! Got a strange thing with WD2500BEVT. Bios doesn't see it, however it is detected in Windows as SCSI disk drive, but no information in disk management about it, as well, as no detection in MHDD or Victoria. The drive used to be working in a laptop, the owner was using it while having a flight, then the plane started to land, she turned it off, and when she switched it back on, the drive failed detection. Is there a DIY method, the data is very important?

DIY recovery seems unlikely IMHO, but I find it very hard to believe that Windows is detecting something, which MHDD isn't detecting.

Are you sure that the necessary (slightly unusual) BIOS config is being used, when MHDD is being run?

What is shown by the BIOS disk setup screen (disk model & capacity) for this drive?

Well, nothing supernatural, just the default settings:)

I shows blank fields, as if it was detected, but instead of numbers and letters, blank fileds with no information.

How have you connected the drive?

SATA or USB?

_________________
PC Image Data Recovery
http://www.pcimage.co.uk

New!! HDD-PCB.COM for all your PCB and donor HDD requirements!

SATA

If you don't know the exact details, then this might explain why MHDD isn't detecting the drive at all. Modern PC BIOS often default to AHCI SATA controller functionality - which is not compatible with MHDD (see the online help for MHDD compatibility).

If I was in your situation, I would look for a BIOS SATA controller setting of "compatible" or "IDE", select that (and not AHCI), then boot MHDD from its bootable CD, with the "problem" disk drive attached via SATA. Note that not all BIOS types allow you to change that SATA controller setting and hence not all BIOS are compatible with using MHDD. Do you have that BIOS setting, and if so, what does it show?

I expect that the drive won't ID properly, based on your description of the BIOS showing "blank" for the drive, but it is probably becoming ready, which is how Windows (and MHDD, when the BIOS is configured properly), would allow the drive's presence to be detected.

This all sounds like DIY is not a possibility in your case, and you'll need professional help.

It's IDE, not AHCI. My Windows was installed under IDE mode

OK - of course I couldn't know this info, from you saying "default settings" earlier.

We could go through a deeper investigation using MHDD, as I bet we could explain why the drive could be detected (but not ID) by Windows. However it'll be a waste of time, as the result is the same - DIY not possible IMHO, as I said at the beginning.

Ok, I just got to MHDD once again, and found that the software sees it, but with no ID is present, only "0" where the size of LBA should be. I chose that port, tried to get SMART attributes, it says "the device cannot work in LBA mode. I typed eid and it showed that it has Size:0, no firmware info, no LBA info, only Bios information.

Yes - exactly what I expected, MHDD does detect the drive. We knew that EID in MHDD wouldn't work, since that MHDD option sends exactly the same (S)ATA command as the BIOS sends to display the drive info, and you said that was blank in the BIOS...

IMHO not DIY.

Can we investigate it deeper?:) I understand it might be a waste of time, but I'm very curious, though.

I bet this drive has a problem.

Take a USB to SATA adapter and try this drive on a USB port.
I would suggest to do that even on another PC to be sure
if (the PC) "behaves" differently.....

If the drive will not be recognised either, then its defect and
you can think about the value of the data - for a data recovery
without DIY.

+++

@Reptilewing:

Not with me, no.


It's my time which would also be wasted, so I won't be doing that.

You have now corrected your earlier comment, saying that MHDD didn't detect the drive (but actually it does) - that was what I was going to investigate, to understand how Windows was able to detect the presence of the drive. As I said at the beginning, I couldn't believe that Windows detected a drive (although obviously in an incomplete way), that MHDD didn't detect. Now that the original erroneous statement has been corrected, the behaviour you report from MHDD confims that the situation is not DIY IMHO.