How do I get my files off my dying laptop?

September 17, 2006 8:24 AM

My laptop appears to be giving up the ghost... how the hell do I get at my files?

My (brand-new, under warranty, so I can get it fixed/replaced - that's not the issue) laptop is chain-bluescreening on me. I was using it as normal (playing a game, actually - Starcraft) when it bluescreened on me, and after that, it wouldn't load into Windows (XP Home SP2) in any way (normally, last known working config, safe mode) - would just bluescreen, restart, rinse and repeat.

Reinstalling WinXP on a different partition helped me for about a day - then it started doing the same thing again.

Reinstalling WinXP again is an impossibility, tried several times and it'll bluescreen out of the process at random. Also tried with a Win2K CD, same thing.

The best I can do is get at the recovery console from the WinXP bootable CD - once there, though, nothing much makes a difference.

I'm certain this needs fixed by somebody with more experience than me or replaced altogether, now. The issue is...

When I get into the recovery console, I can see my files with the usual DIR commands, etc. A lot of them are files I can't recover from anywhere else, so I'm rather eager to get them off the laptop before I send it to the techies, as they have a tendency to wipe things clean.

I have a 20GB iPod (and a 1GB USB key for that matter), and from the recovery console I can see it as an external drive. My bright idea was to rescue my files by using the COPY command to move them to the iPod, a bit at a time, and from there moving them to another computer I have access to, rinse and repeat.

Unfortunately, the recovery console won't let me do that (says "access denied", and the helpfile for the command says I cannot copy things onto removable media).

This is obviously terribly frustrating... I can see my files, just can't get at them. Is there any way at all I can pry them off the laptop with the tools I have?

The laptop in question has a CD drive but no floppy drive (so no booting from floppies), if it makes any difference. I'm pretty certain the laptop has an embedded (not removable) HD, and either way opening up the laptop to pry the HD out and hook it up to another computer would void warranty (which I would really rather not do, since this thing was rather expensive).

Help?

posted by sailoreagle to computers & internet (22 comments total)

If you have access to another computer, try burning a CD/DVD with Bart's Preinstalled Environment (BartPE) bootable live windows CD/DVD. Your extra-geeky friends may already have one for this sort of thing.

Of course, if the blue screens are the result of a hardware issue (such as bad memory, which is likely given your description of the problem), Bart's PE might not run, either.

Speaking of memory, if you can access the memory (usually it's under a screwed-on panel on the bottom of the laptop, and you're allowed to go in there), there's a possibility that removing the memory that's there might get you bootable. Some laptops have on-board memory AND a second, user-accessible memory module, and if that's the case with your laptop, and that secondary module is bad, removing it will get your machine to boot.
posted by Merdryn at 8:33 AM on September 17, 2006

Try a Linux live CD - Knoppix is the traditional choice, but the current release of Ubuntu is also a good full-featured live CD with a very polished desktop interface; even with no Linux experience, you should be able to use it to copy everything you need from your (probably failing) hard disk to your iPod.

If you balk at downloading a full-sized CD-ROM image, try Puppy. It's about a tenth of the size, but should still let you recover everything you need from an NTFS partition with minimal fuss - provided it recognizes enough of your laptop's hardware to run; Puppy's hardware detection is still a little short of the full-sized distros (Knoppix is legendary for being able to run on just about anything).

The Ubuntu live CD also lets you boot into Memtest86, which will let you see whether you need to mess about with memory modules (good point, Merdryn).

Best of luck!
posted by flabdablet at 8:43 AM on September 17, 2006

Get a 2.5" (laptop) to IDE adapter and mount the laptop's drive in your other computer.
posted by misterbrandt at 8:57 AM on September 17, 2006

The laptop in question has a CD drive but no floppy drive (so no booting from floppies), if it makes any difference. I'm pretty certain the laptop has an embedded (not removable) HD, and either way opening up the laptop to pry the HD out and hook it up to another computer would void warranty (which I would really rather not do, since this thing was rather expensive).

Why do you believe opening the laptop would void your warranty? I think the last time I saw a hard drive soldered into a motherboard was in 1981, with an IBM XT desktop PC.

I would open the laptop, remove the hard drive, plug it into a USB laptop hard drive enclosure (example) and connect the drive to a second computer to do the backup work.

Put the hard drive back in the laptop and then get the logic board looked at under warranty.
posted by Blazecock Pileon at 8:58 AM on September 17, 2006

I'm pretty certain the laptop has an embedded (not removable) HD

Sorry, don't know how I missed that bit. But if it is really "brand-new" I have trouble believing that it is a non-removable HD. What make+model?
posted by misterbrandt at 9:30 AM on September 17, 2006

Did you try to CHKDSK in the recovery console? That has solved quite a lot of bluescreenish problems in WinXP, for me.
posted by Memo at 10:07 AM on September 17, 2006

If you have anouther PC and happen to be on a home network you could start the Laptop in "Safemode with Networking" and map a network drive from the Laptop to the other networked computer and copy your files over that way.
posted by slowtree at 11:08 AM on September 17, 2006

Let's see...

Tried BartPE, it gets to the loading screen (the black screen with the Windows logo and a progress bar, for lack of a better description) and bluescreens.

I'm downloading a Linux live CD now to try that, but at this point my strong suspicion is that it's the memory that's hosed (if it was the HD, it wouldn't freak out when loading off CD only, unless I badly misremember what little tech knowledge I have).

So if the Linux CD doesn't work (or hell, even if it does work and I can get my files) I'm checking if I can access the memory like Merdryn suggested.

As for the HD - the non-removable is just a guess based on my experience with laptops, but I might be wrong; I'll check in the process of poking at it to check the memory.

It's an Asus A6VM; what leads me to believe that opening it up equals voiding the warranty is that it's what the store I bought it from told me - that if it breaks, to just take it back to them, and that me opening the laptop, even just to look at the innards without touching anything, would void the warranty.

But at this point, if I can get it open, get the HD out safely to plug it into the other computer, and replace it, I'm doing so anyway. Meh. Just want my data back.

Oh and Memo, yes, CHKDSK was the first thing I tried - didn't solve anything.

Thanks for the help so far!
posted by sailoreagle at 11:16 AM on September 17, 2006

Slowtree: was one of the first things I tried (as I am indeed on a home network), but the computer won't even start in safe mode (as mentioned in my original post) - just bluescreens out mid-load.
posted by sailoreagle at 11:18 AM on September 17, 2006

given that the PE CD crashed, I'll guess that the Linux LiveCD will coredump, and it'll be traced to the memory.

As others said, any late model laptop has a removable hard drive. You can pick up a USB enclosure for these drives at your local Fry's/Best Buy (some of them)/Tiger Direct warehouse. I'll bet that your data is fine, so if there's nothing on the drive that you need right away, take your time in getting the data off.

My money's on bad memory.
posted by Merdryn at 11:33 AM on September 17, 2006

sailoreagle writes "As for the HD - the non-removable is just a guess based on my experience with laptops, but I might be wrong; I'll check in the process of poking at it to check the memory.

"It's an Asus A6VM; what leads me to believe that opening it up equals voiding the warranty is that it's what the store I bought it from told me - that if it breaks, to just take it back to them, and that me opening the laptop, even just to look at the innards without touching anything, would void the warranty."

In 99.99% of the laptops out there removing the hard drive doesn't involve opening the laptop case. There is either a access panel on the bottom or access is by removing the keyboard.
posted by Mitheral at 1:33 PM on September 17, 2006

Further updates:

Opened a panel at the bottom of the laptop, found the HD, it looks very removable, so at least for that, I'm going to see about rescuing my data via hooking it to the other computer I have access to.

Tried the Ubuntu Live CD: Ubuntu itself wouldn't start (obviously enough) - and Memtest86 froze entirely after a bit.

Opened up another panel at the bottom of the laptop, found the memory sticks... very carefully removed first one, then the other, to see if it made any difference - which it didn't... booting up with only one of the sticks, whichever of the two it is, leads to the bluescreen again.

Booting without any sticks doesn't work (no inbuilt memory to speak of, I'm guessing).

What are the chances it's both the sticks fried? What else can it be that is fried, leading to an issue like this?

Should I just take the laptop to a local computer store place and see if they can borrow me a memory stick or two for a few minutes - just to see if it boots? (Or are they just going to tell me to either leave it with them for them to fix it [no, thanks] / suck it up and buy a memory stick [always good to have a spare one on hand, but the stuff's expensive]?)
posted by sailoreagle at 2:08 PM on September 17, 2006

Fairly unlikely to be both memory sticks, a motherboard is the better bet. The thing is under warranty, I wouldn't buy anything for it just take it in to be serviced after securing your data.
posted by Mitheral at 2:22 PM on September 17, 2006

Yeah. Memtest86 freezing = badness, and if Memtest86 still won't run with either half of the RAM removed, it's more likely to be a CPU, mobo or power supply fault than two bad RAM cards. So whip the hard disk out and back it up, then get the thing fixed under warranty.

I take it that it was Memtest86 you attempted to start again after each RAMectomy? A Windows bluescreen is not really diagnostic, since Windows itself may well have been damaged by bad RAM before you started swapping stuff around.
posted by flabdablet at 12:36 AM on September 18, 2006

Windows couldn't have been damaged by bad memory if setup completed (and, chances are, the manufacturer just imaged the drive with it anyway).

Take out the drive, put it in an enclosure, and back it up.
posted by Merdryn at 4:27 PM on September 18, 2006

Bad memory can damage anything. Bad memory can turn read commands into write commands and/or corrupt blocknumbers so stuff ends up being written back to the wrong places and/or cause random execution of disk-write code in places it shouldn't normally happen.

Any OS booted from writable media (e.g. a hard disk drive) could potentially be corrupt if it's been run at some time on a machine with bad memory, even if the bad memory is subsequently fixed. That's why I pointed out that a failed Windows boot is not necessarily diagnostic. Windows reads a hell of a lot of disk blocks on the way up, and corruption in any one of them could potentially kill the boot.

The Memtest86 that comes with Ubuntu, on the other hand, is a small program that boots from a non-writable CD-ROM. So if that doesn't run, there's definitely a problem right now, as opposed to the possibility of the muddy footprints of an old problem still hanging about.
posted by flabdablet at 10:06 PM on September 18, 2006

All of which aside, Merdryn's plan is the right plan. Grab copies of the files you care about before taking that sucker back for warranty repair.

And ask the shop to do their best to preserve your data, regardless; don't volunteer any information about what panels you may or may not have unscrewed and what components you may or may not have removed and replaced. That's an argument absolutely not worth getting into.
posted by flabdablet at 10:14 PM on September 18, 2006

flabdablet: Please quote your source that bad memory can somehow turn a read operation into a write operation. I have never heard of such a thing.
posted by Merdryn at 7:15 PM on September 19, 2006

Source: me (20+ years of embedded systems programming experience).

It works like this: the code that the CPU executes is ultimately just a bunch of bits in RAM. If the RAM is bad, and code gets loaded into a faulty section of it, some of those bits will have unintended values, and the CPU will end up executing code that no programmer ever wrote.

The effect of making changes to random bits in the RAM image of a program can vary; some bits make no difference at all, others are critical. In general, there's no way to predict the behaviour of randomly corrupted software. It could do literally anything the machine is capable of doing, including writing disk blocks to strange places, or it could lock up entirely, or it could bluescreen, or it could run for years with no detectable misbehaviour. You just can't tell what a RAM fault will do.

Some kinds of corruption-induced misbehaviour can be surprisingly orderly. An OS is essentially a huge collection of subroutines for application programs to call. It's entirely possible for an app (or system component) running in a bad section of RAM to make perfectly valid system calls to unintended system routines. There is nothing sacred about the Windows file-read, file-write, registry-read, registry-write, disk-read or disk-write routines that would protect them from this.

My point was simply that software stored on permanently-attached writable media can't be guaranteed to work properly after the machine has spent any time running with bad RAM. You might get away with it; you might not. Until you've made the hardware trustworthy, you're much better off using diagnostic tools loaded from non-writable media.
posted by flabdablet at 11:33 PM on September 19, 2006

Sorry, I'm not buying it. Embedded systems are far less complex than a laptop computer with numerous subsystems that speak to each other to ensure the safety and integrity of data as it moves from subsystem to subsystem.

Bad memory in today's computer hardware just wouldn't allow that to happen; if the read or write operation to memory failed a CRC check (at the least) or a more robust parity check (more common), the memory controller simply wouldn't allow those instructions to be executed. A flipped bit doesn't turn a read operation into a write operation (since, in Windows for example, that operation is parsed by the HAL before it even gets to the drive controller). A corrupted memory block, I suppose, is theoretically able to contain an instruction to write to the hard drive, but the memory controller (which is outboard from the memory) would detect the bad read, and would (in many cases) simply cause the OS to blue screen.

A BSOD, after all, is a "panic" stop because the OS, in cooperation with BIOS and the chipset of the PC, detected a hardware fault or an illegal operation.
posted by Merdryn at 8:09 PM on September 20, 2006

Embedded systems are far less complex than a laptop computer with numerous subsystems that speak to each other to ensure the safety and integrity of data as it moves from subsystem to subsystem.

Complexity and reliability are not even close to being the same thing. The numerous subsystems that exist inside a modern Windows-capable box are there for performance reasons, not to guarantee bombproof data integrity.

Such data integrity mechanisms as do exist - such as CRC's on transfers of data blocks across assorted buses - are there to detect transient error conditions caused by cable noise etc., not to compensate for gross RAM, CPU or motherboard faults.

Sometimes a CRC on a data block transfer might pick up a RAM fault; typically this would require that (a) the CRC is calculated by software that makes a second pass over the block in question (b) the RAM is faulty in a way that makes different values appear in the same location on multiple reads. In fact most CRC's are done on-the-fly by controller chips that make only one pass through the data, and will not catch changes that occur between the time the data block was written and the time it's next moved.

Bad memory in today's computer hardware just wouldn't allow that to happen;

This strikes me as the kind of opinion often held by people without much low-level experience with real PC-class hardware.

if the read or write operation to memory failed a CRC check (at the least) or a more robust parity check (more common), the memory controller simply wouldn't allow those instructions to be executed.

For starters, I don't see how you could reasonably describe a parity check as "more robust" than a CRC, which is in any case a block-level check code and not used per memory word or even per cache line. Perhaps you're talking about the ECC check built into server-grade RAM.

In fact the RAM in most of today's consumer-grade computers doesn't have ECC. ECC memory costs more, and most people don't fit it.

In any case, ECC won't fix every conceivable kind of RAM fault. Some kinds of RAM fault - notably those involving shorted or stuck address lines - can cause two RAM locations to be written (complete with perfectly valid ECC check bits if ECC is present) when only one was supposed to change.

A flipped bit doesn't turn a read operation into a write operation (since, in Windows for example, that operation is parsed by the HAL before it even gets to the drive controller).

And the HAL is just code running in RAM, no less subject to corruption-induced misbehaviour than any other software component.

the memory controller (which is outboard from the memory) would detect the bad read, and would (in many cases) simply cause the OS to blue screen.

And in many other cases - or all cases, if non-ECC memory is in use - the memory controller would just blindly load whatever crap turns up on the memory data bus into the CPU instruction or data cache; with results, as I noted before, that are essentially unpredictable.

Yes, the code might be damaged enough to perform an illegal operation and trigger a BSOD. Or it might just have a corrupted bit in a system call number that makes it quietly scribble crap on the disk.

My point is that you really cannot predict what effect RAM corruption is going to have on a running system, and that there is a small but non-negligible chance that such a system could in turn corrupt one of its own boot-time executables or registry entries if those are stored on writable media, as is typical for Windows boxes.

This has all turned into a bit of a derail, so if you still reckon I'm full of it, that's fine by me; I can happily agree to disagree with you on this minor point. We agree on the main thing, which is that sailoreagle's best course is to back up the hard disk before returning the machine for a warranty repair.
posted by flabdablet at 10:43 PM on September 20, 2006

I never said you were full of it (though you implied that I might be) -- I simply said that the implication that bad memory can cause a read operation to turn into a write operation is wildly unlikely.

Though you're right, crossed my own wires and said parity when I meant ECC.

And, yes, I do have considerable experience with PC and server-class hardware. Never, in my 14 years of experience with numerous and sundry platforms with numerous and sundry chipsets and architectures have I ever experienced a memory-induced corruption of a hard drive, with the only exception of corrupted page files or documents when a computer dies while writing a file (which, in reality, is more of a data stream loss due to unexpected termination of a write process).

Is it statistically possible? Certainly. We are all where we are due to statistical anomalies. You responded with your experience, and here's mine: The risk of a memory fault causing a read operation to somehow switch to a write operation is so statistically unlikely as to be insignificant.

So, I guess yes, we're agreeing to disagree. ;)
posted by Merdryn at 6:39 PM on September 21, 2006