Hi
I've discovered and appreciated this interesting forum, by google --

I've this HDD which has a curious defect: the drive is never recognized by the bios of any laptop, while it's perfectly working , by means of an external USB interface.
When I try to install an O.S. (XP or Windows7) the files of the System are copied to the HDD, but , being the HDD not recognized, there is no boot from the drive...

There are no bad clusters, so I think it's a firmware trouble, but ..what can I do, in order to fix it?
Thank you in advance

Regards
Donald

I doubt that, but there is not yet enough info to be sure IMHO. This could be similar to my hypothesis in this thread:

hitachi-5k320-160-with-model-hts543216l9a300-160-problem-t24045.html

i.e. the drive may be slow to come ready, and if so, this problem can be hidden when such a drive is attached via USB, due to the behaviour of typical USB-(S)ATA bridges.

IMHO it would not be sensible to rely on a drive with that behaviour, no matter what the cause is. Your choices depend on how much time you want to spend on investigation, compared to the cost of just replacing that flaky drive.

Thank you for the prompt reply
I've already replaced the hDD on the matter, hovever I'll try to fix it in my spare time.
I'll try to reveal the trouble , using MHDD or HDdat2 (contained in Hiren's boot cd) in order to attempt to 'kill' probably delays . In any case another external usb disk is always useful!
Regards
Donald

Thanks for the update.


FYI, those types of utilities cannot "kill" the type of delays which could cause a drive to be slow to come ready (assuming my hypothesis is correct in your case, which we don't yet know). They could only (try to) "kill" other types of delays. However it would be interesting circumstantial evidence of the type of problem which the drive has, if you did find any significant delays when reading normal user LBAs (e.g. using an MHDD scan)


Just remember to keep backups of any files which you cannot afford to lose! Good luck!

Take a look at master/slave jumper settings.

http://support.wdc.com/images/kb/scorpio_jumpers.jpg

Thanks
Jumper setting is ok (standalone master )

This very day I've checked the drive with Hiren's boot cd (last version) , and another strange fact has happened:
any hard disk dos program (contained in Hiren's) perfectly and immediately shows the drive , excluding BIOS,,,(obviously)
I've tested the hdd with MHDD , but, according to my opinion, the drive resulted OK (Only one 'W', after having checked the box 'erase delays'
I've tried to install the drive into three different laptops, with the same results....

Regards
Donald
P.S.
I use Acronis true image, for my backups, besides I always save Opera bookmarks , mail and router configurations and i keep my important documents in other disks and memory sticks..I've several Gb of essential electronic schematics (for job) and a great quantity of old tubes radio schematics ( Tubes circuits and restoring old radios are my passion!)

Can you post Smart Parameters of the drive?

@Hardisk,

Glad you've got backups, so this drive behaviour is not a serious issue for you.


Personally I don't find that strange at all. considering the delay before any of those programs starts.

The problem here is that you don't have the specialist equipment needed to directly test the hypothesis which I explained in the other thread. You can only attempt to check for circumstantial evidence elsewhere, and that is obviously an error-prone and inefficient method of diagnosis.

The SMART data (preferably including the raw attribute values) requested by pad15 will be interesting to review, so please do provide that, but again it is only circumstantial evidence (drives with some types of problems can have perfect SMART data!).


OK, no surprise there.

Finally: What is the history of this drive? Where was it originally in use? When & how did you first notice any kind of problem (e.g. did things start off as an intermittent failure of the drive to be recognised by the BIOS, and then progress to the drive being never recognised)? Did anything unusual happen, shortly before you first noticed any kind of abnormal behaviour?

Just for grins (because again, this is not the best test, but at least it's one you can do): Put this drive into the laptop; power-on the laptop; during the boot process, go into the BIOS disk setup screen; check that the drive is not shown there (as we expect); leave that screen showing and wait 5 mins (I would go and have a cup of coffee ); come back to the laptop which will still be showing the same screen and press ctrl+alt+del to restart it [do not power-cycle the laptop]; again, during the boot process, go into the BIOS disk setup screen - is the disk now being reported there?

Due to the BIOS likely resetting the drive, this isn't as good as a test done with better control of the drive, but the result might be interesting.

Thanks for the kind replies

Mine is only a curiosity, so I don't mind to waste your time for my stupid question.....!
As soon as possible i'll post a SMART report of my drive.
The history of the fault is very simple: the drive was installed in a Compaq Evo n620c
The first operating system has been XP pro, then I've installed successfully Windows7 Ultimate Edition and the laptop (I've several Compaq Evo n620c and 610c and I think that this old laptop is very versatile: it supports 2Gb Ram DDR1 , besides I've installed also..... MAC OS X 4.8... in another one and it is perfectly working and very fast) is OK (including graphic driver!)
I've left the laptop unused for about 1 month, but when I've switched the PC on, the HDD has disappeared from the system......(suddendly dead)
I've tested it in various laptop of different brands, without success. I've not yet checked it in a desktop PC, because order is not my peculiarity and I cannot find the suitable adapter.....My laboratory is the kingdom of chaos!
Tomorrow I'll try to switch the notebook on , then I'll go to drink a coffee, in order to allow the lazy disk to be configured..this is a ...'kostenlos Probe' (free test)
In any case i cannot understand for what reason the utility dos programs 'see' the drive immediately (also mini XP of Hiren's) , while the bios refuses to do so.
This is the second strange situation regarding HD drives: the first has been caused by a friend's new Emachines minidesktop PC which has destroyed 3 Sata HDD in three months...
After an incredible number of tests and hypothesis, I've discovered the cause: The Sata primary controller generates an auto-oscillation , infact I heard a slight whistle while the drive was working....So I've fixed the trouble, by inverting the drives dvd e HD.!!!
Now the PC is working, even if I've bought and installed a PCI-E Sata, Raid and Pata controller , to avoid future problems.

Grüße
Saluti

Thanks for the update.


Great! - suitable utils include HDDScan (Windows) or even taking a photo of the appropriate screen from MHDD (if it is booted from CD/DVD, so using F10 and collecting that file isn't easy).


Interesting... I don't have enough evidence to say that you have this problem, but I've seen a few drives with bearing problems, where this was first observed after a period without use.


Understood. Personally I don't see that as an important test. A desktop system may have a different timeout for detecting the disk, or other similar variations, but at this level, most BIOSs behave similarly e.g. wait a fixed maximum time (e.g. 30s) for the drive to become ready, then send the ATA Identify Device command, then display the drive's make, model & capacity on the screen from its response to that command.


Ja, genau

There is a risk of a misleading (or at least inconclusive) result in this test (specific to this type of drive and the test) but I don't see any easy way to avoid this possibility without extra equipment. As with many tests: one possible result does give a useful answer; the other possible results would be ambiguous and wouldn't prove or disprove the hypothesis.


My hypothesis is that this is successful because the disk has already had more time to come ready, by the time when DOS (or miniXP) boots, because whatever timeout which your BIOSs have (e.g. 30s) has already elapsed + whatever time was taken for DOS etc. to boot. In short - the drive has more time to become ready for these other programs, than it was allowed by the BIOS timeout.

Perhaps this hypothesis is wrong, but that is what I'm attempting to test with the procedure which I suggested before. The spin-up time attribute in the SMART data might give a hint of a problem in this area (good suggestion, pad15 ).

Anyway, good luck!

MfG...

Hi
Thank you again and again
Today, early in the morning, I've switched the laptop on and enter bios settings.
After abt. two hours I've found a bios message. I don't remember the exact words, but the 'juice' is the following:- Impossible to configure the drive-

I've again used MHHD for scanning the drive another time. After the new scan(no delays, no errors) , Mhhd began to erase the drive (I've not requested so) , then I've installed it into another USB interface and connected it to my usual PC. The reply of my pc has been'The unit F has to be formatted' ..Right...but I think ther's a Poltergeist or my drive is ...haunted.....After having connected the same drive, with the same interface to another laptop, the hdd resulted perfectly formatted (ex-fat) and with all the previous files!!! Now I'm at home and I've just formatted the drive again (fat 32) and it's clean. (checked also in my home laptop)
I'll take a photo of smart attributes, as I cannot save the log file. (i'll can try with F10...)
Hdd scan don't find any error, besides I've tested it with HDD Tune pro: all right.
Regards
Donald

..Updated news

I've just installed the drive in a desktop pc: bios recognized it immediately , but as RD4640BERE, 00UXT0 instead of
WD16 00BEVE 00UYT0 (wrong firmare or factory nick?).
, besides the drive is not present in boot list!!(I'm not sure, as I'd imposted boot from sata ...I'll check again, after MHHD analysis) Cluster delays seem disappeared. I've also made a snapshot of SMART , by my phone, but it's awful; later I'll
attempt to make it readable, before posting.
In this very moment MHHD is working (45%) without delays and slow clusters

Regards
Donald

In your last 2 postings, the intermittent request from Windows to format the drive, and your desktop BIOS reporting the slightly wrong model, would both make me concerned about the drive's PATA interface. I tried briefly checking the binary differences between the correct & incorrect model details, but the changes do not seem to be always the same bit within a byte (or within a word). An intermittent problem in this area could explain the "poltergeist" behaviour that you mentioned

I can't say much more without seeing the drive, and with just the current info. All I can say is that if it was my disk, and based on this latest news about the drive's behaviour, I would now be focussing my investigation on the interface.

Hi

Next December. in my town (I live in Italy and I am Austro-Italian) there is a very interesting electronic market (Called M.A.R.C.) where we can find anything (new or used)
There are many wrong HDD for spare. I've already compiled a list of several drives which need a PCB replace, therefore I'll add this drive in my list too.
I'll post the Smart Report another time, because I'm not at home and ther's no bluetooth here
Thank you
Regards
Donald

Hi

I think the Vulcan's hypothesis is right!
After having connected the drive to a desktop (as IDE Master) , Windows reveals it as 'UNFORMATTED' : the name is wrong and it's impossible formatting it, while, in an USB interface, the disk is right again .
The only thing successfully was the restoring of its original capacity of 160Gb, instead of 130, by means of the suitable command of MHHD. RHPA
Here I enclose the smart report (regarding the drive connected as master ide in desktop)
Thanks
Regards
Donald

My second hypothesis (interface problem), perhaps yes, the behaviour seems to fit that so far. It would be interesting if the interface signals are invalid or marginal (either voltage levels or rise/fall times) when the drive is transferring data to the PC via IDE. Personally, I would be checking those signals individually with an oscilloscope, if the diagnosis was worth that investment in time.


All that behaviour is expected with an interface problem e.g. the filesystem metadata cannot be read correctly directly using the IDE interface (in your case).


I can think of a couple of possible causes, but all are related to different interface problems.


Thanks for that info. Unfortunately, since you used the IDE interface to collect the SMART data, and you can see the interface problem was occurring (the drive make/model is wrong), then:
(a) the SMART data cannot be trusted (it is transferred using the same interface ); and
(b) the SMART data does not make sense, for some of those attributes - probably due to corruption caused by the interface problem, when the PC read the values from the drive.

If your external USB enclosure supports the passing of the commands for gathering SMART data (some old enclosures don't support that), you could try gathering the SMART data again with the drive in the USB enclosure. However with everything pointing towards an electrical interface problem IMHO, I don't now see collecting the SMART data as the next useful step. Perhaps pad15 still wants to see that...

Personally, if I accepted the risks of this action, I would carefully remove the PCB from the drive (observing ESD precautions at all times, of course), look at the PCB, and see if there is anything which appears unusual.

As I see it, your options (if you decide to go ahead, and if you accept the associated risks) include:
- just use the drive in an external USB enclosure from now onwards (but don't trust it!); or
- pay someone with the necessary skills, experience and access to donor PCBs, to replace the PCB on that drive and then re-test; or
- find a suitable donor PCB yourself; swap the ROM yourself from your existing PCB [*] and then re-test.

[*] On those drives, I'm assuming that the PCB does have an external ROM, but since I don't work much with WD drives, this is an important detail which you would need to invest time checking. If there is no external ROM, or if you don't have the equipment or confidence to do SMT rework, then the last option above is no longer available to you. Of course there are several risks in doing this type of work, including the risk (as we have seen reported by users on this forum before), where someone tries to swap a ROM between PCBs, and damages the ROM.

Since you don't need the data from this drive, I don't think it is sensible for me to offer further suggestions as I have only limited time and I have reached the end of what I can sensibly offer remotely. As always, things are much easier (and quicker and more efficient) when the drive is on the bench in front of the person doing the diagnosis Good luck!

Hi Thanks again
This drive is not at all important for me. There are no data to save, but I'm only curious, therefore my post is only a testimoniance that I've appreciated your help and your effort to explain me the cause of this trouble and no more. So I ,m not waiting for any reply to this post!
I'll try with another usb interface, able to support Smart attributes.
Regards
Donald
P.S.
Thank you very much of your kind consideration

Sorry for replying late, very busy week!

My interest in smart data was just a curiosity, I just wanted to see
if the drive was somehow degraded and so becoming slow to come ready.
Some of the data (ultra ATA CRC errors) points to a problem with ide interface,
as Vulcan suggested, and the wrong ID recognized by the BIOS could confirm this
supposition.
I suggest you to closely inspect for broken or bent pin in the ide interface
and to make a scan with MHDD and look for the actual read speed of the disk.
I had an old 40GB samsung with TWO ide pins broken that behaved in a similar
way. It was recognized by MHDD but was very slow and no OS would mount it.
I managed to make a ghost clone from DOS (it took hours) and only at the end
noticed the bent pins!

@Hardisk,

You're very welcome and good luck!

@pad15,

Thanks for explaining your thoughts, and I agree that the SMART data may have been interesting (before it became more likely that there was an interface problem).


The problem is that IMHO we cannot trust that SMART data (as it was also read over the same (defective?) IDE interface as the wrong ID!), so we do not know whether the drive is actually reporting any Ultra ATA CRC Errors or not.

Just as an example, for attribute #9 (power-on time), the "cooked" (normalised) current value says 96, and the worst says 100. That is invalid, since for that attribute (and many others which are counters) the worst value should be the lowest value ever reached, and therefore should be reporting 96 or lower, not 100. Therefore I was asking myself: So what is wrong - is the value "96" wrong? Or the value "100"? Or both? With invalid (corrupted?) "cooked" data, then can the "raw" values be trusted either?

How many of the other SMART values are invalid, due to corruption as they were transferred across the interface? Is that raw value for Ultra ATA CRC Errors actually what the drive sent, or is that also due to corruption? Again, since that attribute is also a counter, I would not expect its "current" value to be higher than its "worst" value - but that is what is shown. Therefore personally, I cannot trust the SMART values shown for Ultra ATA CRC Errors (attribute #199) either.

As you say, checking the IDE pins (that's part of what I meant, when I suggested earlier to check the PCB) is one sensible step. I tried doing a quick comparison between the correct ASCII expected for the drive make/model (allowing for the ATA byte-swapping in strings), and what is actually reported by the host (i.e. received from the drive), and I didn't find consistent bits to be in error. However I haven't spent much time on that (so perhaps I missed something in the data) since, as we agree, a visual inspection would be a good place to start.