Hello, all.

While I'm not in danger of losing critical data, I would like to see if anything is recoverable, or at least read the Event Viewer for a clue to what happened. After my WD800JB started rebooting immediately after Memory Test, we changed harddrives to get back 'up and running' and put the WD800JB into a Nextstar 3 IDE/USB enclosure. When powered up, it generates the 'Found New Hardware' balloon and is recognized correctly, but forces a restart a few seconds later without appearing in 'My Computer' or receiving an assigned Drive letter.

Is there a way to override this so I can see what might still be usable? Thank you;

GSG

Hi,

if there is a way, use MHDD, and _after_ it is loaded, plug in your drive directly (not in USB), and switch off MBR.
After this, you can use your OS (depending on the problem) and use data recovery softwares to see your files again. (it will be hidden in windows.)

This works if your FS is corrupted.

Good luck
Janos

Do you mean that the PC containing that disk, started rebooting immediately after the POST memory test, or something else?

Had anything changed, or anything unusual happened, immediately before this behaviour started? (Unclean shutdown / power loss / PC was dropped / something else?)


What leads you to believe that its the disk drive which "forces a restart" - do you see a specific error message (e.g. something mentioning NTFS, perhaps) which leads to that conclusion?

Are you confident that the enclosure works OK with another disk drive inside - just to rule-out that this is introducing another problem?


If something on this disk drive (filesystem?) is crashing Windows e.g. when Windows tries to mount the filesystem (which may fit with what you are saying, but some more details would be helpful, hence my questions above), then I'd think about booting a different OS e.g. bootable LiveCD version of Linux, in order to get better error descriptions and more control.

Note that if the filesystem is corrupted then any attempt, by any OS (Windows or Linux) to make the filesystem metadata consistent again (e.g. chkdsk etc.), will write to that disk - which is a bad idea, if you don't like the results of that change, since you can't revert back to try something else.

Therefore I'd recommend cloning the disk to another disk or disk image, before you make any changes to that disk (e.g. before trying to correct its filesystem), so that you have a copy of its state now. Again, that can be done within Linux, for example.

Thank you for replying, Janos. Do you mean, plug it back in as C:\? Or as a slave.


What actually happened was, I came back from a pause in a game to find a box, "McAfee agent.dll (or something like that) ....needs to close." Since I wasn't on the Internet at the time, I didn't think I needed McAfee, so I clicked Okay. Instead of just closing McAfee, however, the computer immediately rebooted; I reloaded the game, then another (different) box came up and was followed shortly by another---before I could 'Okay" anything, the computer rebooted again, with no input from me.

I'll try to shorten the story; the only way to stop the 'loop' was to shut off the PSU, and when I turned it back 'ON', the cycle resumed even though the front-panel switch hadn't been pushed. Eventually, the computer ran CheckDisk---again, no input from me---and recovered two or three files, then rebooted before I had a chance to read what they were. After a few more 'CheckDisk' cycles, with the list of 'recovered' files getting longer each time, things settled into their final routine; two black BIOS screens, then a "We're sorry for the inconvenience, but Windows failed to start.....etc."

I was told, 'bad HDD', defective memory (I had upgraded to 2 x 1GB a couple of weeks earlier; right now I'm back on the old 2 x 256MB just in case), and 'bad motherboard' (obviously it's still good). The harddrive is barely three years old (mfd. Jan. '08)---I thought they'd last a lot longer than that.

Oh---and nothing's been dropped, smacked, spilled upon or anything like that, and the USB enclosure is brand new.

Thanks, Vulcan; sorry it's so long.

OK do this one. Sounds like you have some issue with maybe virus or your OS. You can try this one first. Get a new HDD and put it on another computer and clone this one to the new HDD. After with the new HDD you have cloned to you can run some recovery programs on it and get off your data. Then you can after all this one and you have your data try and find the virus in your disk that is causing this problem, try to fix your OS, or just start over again with a fresh install and get a better virus program next time on this one.

_________________
Iorana Haraharaini

@GSGregg: Thanks for your reply and the extra info.


No worries - better to have more info than too little. The new info was certainly helpful to better understand what was happening.

I should point out that my approach would be different to that from N.C. (Janos). Therefore in order to avoid wasting my time explaining too many details, if you decide to follow his approach instead, I'll just make some comments explaining a few thoughts. To give full disclosure, I'm not a DR pro - I'm an electronics engineer, with many years experience working in a different part of the disk storage industry. So while I am happy with the risk-analysis of what I would do in your situation, I'm not the person who would be doing it, and in any case, it's your data not mine. Therefore it's got to be your decision what you do.


I see that poehere has suggested that there might be a virus. IMHO the error message doesn't definitely prove or disprove that possibility. In my experience, since virus scanners are doing reads from the disk, they sometimes find other problems (unreadable blocks, corrupt filesystems etc.), and not only find viruses. But, as I said, poehere could indeed be right, so remember this is a possibility.

In any case, the fact that attaching that disk drive via an IDE converter (i.e. not booting from it) still causes the PC to reboot (after chkdsk messages), makes me believe that even if there is a virus involved, something else is involved too - probably a corrupt filesystem, perhaps initially triggered by unreadable filesystem metadata.

I'm not surprised that this disk is no longer bootable - the more that chkdsk runs, then if it renames or moves a critical system file (due to perceived filesystem corruption - although that could really have been caused by memory corruption), then Windows can easily become unbootable from that disk.


That's normal behaviour with some PSUs - they treat removing the power via the rear panel switch as a power failure, and automatically power-on even without you pressing the front-panel switch.


This behaviour could be caused by unreadable blocks on the disk - and as I mentioned above, the more that chkdsk runs, the greater the chance that something vital will get recovered as a "lost" filename and then Windows won't boot.


Good idea to go back to the original RAM, in case the new RAM did introduce a new problem - due to filesystem caching, memory problems can corrupt a filesystem. You could try booting from a memtest+ CD and see if you can provoke a fault with the new RAM, if you want to.


I guess you're saying this, because a replacement disk (and new Windows installation on that) is running OK? If so, then while I agree that this suggests the motherboard is OK, if the problem is actually a very intermittent fault, which only occurs (and corrupts filesystems) rarely, then you may not have tested the motherboard enough to make a conclusion that it is OK. The fault might be very subtle and/or intermittent. Again, I'd just suggest you to be aware that you're making an assumption - which might indeed be true, but an assumption nevertheless.


They can last both shorter & longer times than that.

One thing you haven't mentioned is the PSU - a marginal or intermittent PSU can cause incorrect disk behaviour, leading to corrupt filesystems (we've seen a likely example of that recently on this board). I don't see lots of clues pointing in that direction here, but again, I suggest to just bear this in mind.

So having replied to your extra info, I should point out that you have to decide whether you'll attempt DIY recovery of this or not. There is a chance (which is impossible to quantify at the moment, given that we don't yet know if there is a hardware fault with the disk), that the disk could deteriorate, or even catastrophically fail, while you're attempting DIY. Do you feel lucky?

If you go ahead with DIY, my suggestion would involve something similar to what poehere suggested - clone that disk (either to another disk, or to a file), which will perform 2 functions: (a) the cloning process will find if the original disk is fully readable, and (b) you get a copy of the "problem" disk, before chkdsk does any more mangling of the filesystem.

If you find the disk is not fully readable, then that explains the likely original problem - and all the consequences are probably due to chkdsk being unable to make a consistent filesystem on a flaky disk (as well as Windows being unable to cope with such a corrupt filesystem, even when not booting from it).

If the disk is fully readable, then the cause is less obvious - bad memory, other hardware fault, virus, etc. etc. all remain possibilities.

I would do the cloning using ddrescue on Linux (e.g. bootable LiveCD). You don't need to (and shouldn't) mount the filesystem on the "problem" disk to do the cloning (and so Linux shouldn't behave as badly as Windows does). Cloning results are generally better with the "problem" disk direct-attached (via IDE in your case), and not through a USB converter/bridge. The target for the clone can be USB-attached (if desired), since we don't expect there to be a need for good error handling, to that target disk. However, controlling ddrescue for best results, is not a "one-click" operation - it depends on what errors are actually found.

You could also use the opportunity after booting Linux, & doing the cloning, to grab copies of the .evt files (event log files) e.g. sysevent.evt from either the clone or the original disk. Then use an event log viewer (I no longer use Windows, but I'm sure I found a standalone event log viewer ages ago) to see what they show of the original problem (if the logs aren't corrupt or wrapped due to new entries), as you originally suggested.

As you can imagine, such an plan needs lots of preparation, some extra storage, some Linux skills, and a careful approach - and, as I said, any DIY process is not risk-free. Human error or hardware failure could occur and make the data either harder to recover (even for a pro) or totally unrecoverable (e.g. if you get the direction of the cloning wrong and overwrite the "problem" disk). I don't promise to have enough time to hand-hold through the whole process, but I hope the suggestions & comments above are helpful. Good luck!

Well, Vulcan, you've already spent no small amount of time on that very thorough response, and I really appreciate it.
That was my first thought; McAfee was hacked, or infected (aren't they pretty much the same thing?), a few months back and if memory serves, a lot of their commercial customers took it on the chin. I haven't seen anything about a recent attack, though. Anyway, I remember reading about a multi-pronged virus/malware-eradicating procedure a few months ago but, now that I may need it, do you think I can recall where I saw it?

I have a lot of reading to do before I DIY this; one concern is protecting the good components of my computer from potential damage from the bad, whether it be the HDD or the RAM sticks---or even the motherboard. I wonder if Safe Mode, or another such process, makes it safe to have good and bad plugged in together. Maybe that stuff's incorporated in MHDD and memtest86 and whatever.....like I said---a lot of reading to do.

Does this mean that cloning can't take place with just one computer? Again---a lot of reading to do. (Check that---just reread your paragraph about Linux, ddrescue, etc.; looks like a single comp can handle it.)

As far as the power supply is concerned, I got this rig with an Austin DR-B300 that was suspect because the CD-ROM was acting up; replacing the Austin with a Corsair CMPSU400CX about a year ago certainly didn't hurt, but the problem was erratic reading/detecting of disks, and not physical operation of the drive. I installed MBM5 with the Corsair, and voltages have always been fine (temps and fan speeds too).

I guess I'll clear some bandwidth.....thanks again for all the input.

GSG

You're very welcome. Replies below...


I'm not quite sure what damage you're thinking of here - see if the following helps... If the RAM is faulty, that could corrupt the filesystem or other data on the disk, but would not cause hardware damage to the hard disk itself, and could not cause unreadable sectors. A motherboard fault is also very unlikely to cause electrical damage to the hard disk, but could corrupt data being read from, or written to, the disk.

Although you mention that the PSU is not likely to be a suspect, that is one of the few bits of a PC which could cause electrical damage to the disk drive (and can cause sectors to be written which are subsequently unreadable). Of course unreadable sectors can have other possible causes (e.g. normal hard disk fault), so that symptom on its own, is inconclusive.

Until you've checked whether the whole disk is readable (e.g. by cloning it), then you may not know whether having unreadable sectors is part of your situation or not.


Again, this depends what you mean by "makes it safe", but Windows Safe Mode doesn't prevent any interaction between different hardware - it just launches a smaller subset of Windows features & drivers in the hope that they will get the system to at least start.

My suggestion for memtest is to see if you can provoke any RAM errors e.g. with the new RAM installed, since you seemed to have some concerns about that. If you don't provoke any errors, that doesn't mean to say there isn't a fault - but if you do provoke a fault, that gives extra evidence for a possible cause of the problems you've seen.


You'd need to ask poehere about the reasons behind that specific recommendation. I might have guessed the reason in my comments below - but I might not.

I must say that my suggested use of Linux on your existing machine, is based on the expectation that with the old RAM installed, any problem (filesystem or hardware), is likely to be confined to the disk drive. But that is an assumption by me. At least the "reboot cycle" shouldn't occur after booting Linux. With your knowledge of the history of this situation and the recent (successful?) use of the system with a new hard disk, if you aren't confident using your existing PC to do the cloning, then you need to re-think how to do that.

DR companies often have "data extraction" systems e.g. known good PCs, perhaps with additional dedicated disk imaging hardware, to perform this function. The important part of that comment for this discussion, is that they are "known good" (at least as much as anything can be) e.g. not connected to the internet, no viruses, good hardware, lots of cooling etc.

If you have access to another PC which you have more confidence in, to use for doing the cloning, then that would certainly be something for you to consider. However since, ideally you would want to connect the "problem" disk drive direct to an IDE interface (and not via a USB-IDE bridge) while doing the cloning, then that may exclude using modern PCs - unless you buy a PCI IDE card to put into a modern PC, which doesn't otherwise have native IDE ports. See what I meant about needing planning?

If you're not feeling comfortable with what is involved, and if the data has value to you, then perhaps reconsider whether you want to use the services of a DR company?

Anyway, good luck!

Reason behind cloning a HDD is as follows.

1. No mater what the problem logical, virus, file structure which falls under logical or physical the first things to do is clone the HDD. Now if it is physical this one can not be possible becasue you have to repair before you can clone it.

2. After cloning your HDD you can do what you want to it. Does not cause more damage to the original HDD and the data in it. Exact copy of your original HDD. So if you make a mistake and try something you do not lose data on your original HDD.

3. If this is a virus or windows problem to clone your HDD can halp you a lot. You can try to run virus clean up on it, run any DR program on it, or even try and repair the MBR on this one. You are free to do this becasue your data is still safe in the original HDD and can be cloned again if necessary.

You do not have phsical problems I am guessing on this one would have to see if you have bad sectors in the HDD or not but that would be to test this one. So for now from what you are saying guessing it is not really physical this problem but more logical. So in order to fix logical you should clone it and then work from clone. The more you mount it and run test disk on it the more problems you will have on this one.

All practice and best practice clone it first then work on it. That is safe way to make sure your data is safe and will remain safe. But it is your disk and your data so you have to do what you chose is best for you on this one.

_________________
Iorana Haraharaini

@poehere: You and I are both recommending to clone the disk - I don't see anywhere that the OP is disagreeing with this recommendation.

As far as I understood the question, GSGregg was wondering why you specifically said to clone the disk on another computer. That's why he asked: "Does this mean that cloning can't take place with just one computer?"

In my earlier comment above, I have guessed about one possible reason why you said that, but it may help the OP if you confirm your thoughts behind that specific recommendation.

Reason I said this one was becasue it sounded like his main system drive on his computer. If he moved this drive and a new one to a working computer he could clone it from there. If now he could still use this computer and use a linux boot disk and use the linux dd_resuce to clone his drive to another one. He does not have to use another system if he does not want to just thought it would make it easier. In other answer he was indicating he was not sure if system he was using has some problems ie mother board or memory or power supply or what ever. If he used another system this could verify this one for him too.

_________________
Iorana Haraharaini

Thanks - that is what I thought you meant, and hopefully that has now answered the OP's earlier question.

To pohere: I think I get it; you recommended another computer in case there is still a problem with, or lack of trust in, my existing comp. Indeed, there was suspicion of bad RAM and motherboard; I reinstalled the old known-good DIMMs and the mobo is working well with the replacement HDD, so I don't have any qualms about using my PC for the cloning.


I guess the word 'damage' implies physical or mechanical, while read- and write-errors fall under 'corruption' or some other term? I just don't want what's compromised the 'problem' HDD to reach out and do the same to the good, working one (which, by the way, is a Maxtor that's about seven years old, confirming your statement:Will booting from the Linux CD allow me to remove the good HDD from the system during the cloning? That would definitely 'keep it safe'.

GSG

Why not just disable autorun or autoplay or autoinsert notification, or whatever Microsoft calls it in your version of Windows?

This will take care of the case where malware is being launched by the AUTORUN.INF file, assuming that is the problem.

_________________
A backup a day keeps DR away.

@GSGregg:


That use of the word "during" could be interpreted in 2 ways: I'm not suggesting making any changes while the cloning is in progress (if you meant "during" in that way). But yes, you certainly could remove the "good HDD" before the cloning is started (indeed, before booting Linux at all), leaving just the "problem HDD" and whatever target storage you'll be using to hold the clone, attached to that PC and then start the cloning.