Broken PC repair

Nil wrote:
On 11 Dec 2016, Paul wrote in
alt.comp.hardware.pc-homebuilt:

For a job like this, at least two spare drives
are recommended. So you can always have a
"best effort" copy of the data fresh to use
for restoration attempts. No matter what method
you use.

I haven't added any more info for procedures, as I
don't know where Nil is headed with this. Scavenge ?
Or toss ? Or... what ?

Where I'm headed for now is this...

I have acquired 1 free 2-TB drive (you have a good point about having
2, and I may get another one - I can always use it for something
later.) I would like to clone the bad disk to the new disk, but skip
the large main damaged Windows partition. Then I'd like to use the
restore partition to re-install Windows 8 fresh. Then I'll make a set
of Windows restore discs. Then I'll address the task of recovering the
damaged partition from the bad disk.

I've looked a bit at ddrescue. It's complicated - I have to read the
documentation closer. Can I use it to clone the bad GPT drive,
recreating the partition scheme exactly?

It doesn't particularly care about the partition
scheme.

"Disk Dump" utilities are partition based after
a sense.

One "partition" is viewed as the entire disk.
This is the mode you'd use it in to capture
the disk drive.

/dev/sda --- whole disk
/dev/sda1
/dev/sda2 --- second partition,
starting at second partition offset

But you can also enumerate the partitions
individually. Which on a GPT disk, may make sense,
or might not.

There is an area of the disk with the partition
table. You could capture that, if you were a rocket
scientist and could use the parameters in there to
regenerate the same structure on a new disk.

But it's just easier to copy the whole disk and
hope for the best.

If you've booted Linux, you can use the package manager
(Synaptic, on my VM here), to install "gddrescue", which
is the GNU version.

Then, the advice here, is a two-pass copy. When the package
manager installs the binary, it'll be in the path already.
The -n option prevents it from attempting to split bad
spots into pieces. The second pass will concentrate on
the bad spots.

http://www.cgsecurity.org/wiki/Damaged_Hard_Disk

man ddrescue

# first, grab most of the error-free areas in a hurry:
sudo ddrescue -n /dev/old_disk /dev/new_disk rescued.log
# then try to recover as much of the dicy areas as possible:
sudo ddrescue -r 1 /dev/old_disk /dev/new_disk rescued.log

In Linux, the identifier /dev/old_disk will be something
like /dev/sda. While /dev/new_disk might be /dev/sdb. Those
are pointers to whole disks starting at LBA zero.

The rescued.log keeps track of what sectors were successfully
copied. When I tried copying a 2TB drive to an image file,
the log file was very short (because all sectors could be read).
You may be able to examine the logfile by hand, to figure out
where the bad areas are.

I recommend taking your new 2TB drive, and using DiskPart
command line utility in Windows on it first. Select the
disk, then use the "Clean all" command. This zeros the
new disk.

When the ddrescue command is run, any sector on the source
which cannot be read, will not copy anything to the corresponding
sector on the destination drive. By zeroing the drive first,
we're ensuring a known pattern in the bad spots. If the new
drive, you examined it with the Hxd hex editor and there was
already a uniform pattern on the disk, you might be able to
avoid spending the time erasing it. But I'd probably erase
it before making the copy.

If, after the first pass, you happened to get the entire
disk, you wouldn't need a second pass.

If the disk is really bad, subsequent passes might not be
adding anything to the recovered areas. In which case you'd
stop, and now you have your "best effort" copy.

You can now make other copies of that disk, like to your
second spare disk. Then you can carry out your plan.

Chances are, the 128MB GPT partition will come along nicely,
so the partition scheme will be preserved. But if any
individual partition is damaged (most likely C: from
usage wear), then you could select that partition
in Disk Management, format it to NTFS, and reinstall
an OS as you wish. (Because we're working on a good
disk now, that would work.)

*******

For scavenging, there are a number of commercial programs
in the $39.95 range. If you need a freebie, you can try this.

driverescue19d

http://web.archive.org/web/200701010...rescue19d.html

Now, since that pre-dates GPT, that's unlikely to work.
Only if it happened to use partition identifiers in a
portable way, could it work. You'd have to
put a busted partition onto an MBR disk. And
that's a bunch of manual work.

+------+---------------+------------------------+
| MBR | GPT partition | Busted NTFS partition | --- GPT disk with protective MBR.
+------+---------------+------------------------+ Don't let driverescue see this.

+------+-------------+------------------------+
| MBR | Unallocated | Busted NTFS partition | --- MSDOS partitions, one partition in table
+------+-------------+------------------------+ Driverescue should be happy with this.

Driverescue will attempt to copy files to some other recovery
volume you have available.

To prepare the MSDOS example, would take some "math".
You can use Disk Management to make a "prototype" of the
disk, where the dimensions of the last partition will likely
be wrong. You could edit the partition table with PTEDIT32.exe,
and adjust it for "exact fit". Then, you'll need to use
the "dd" of your choice, to copy the partition from one
of your healthy disks, to this prototype. Then
run driverescue on it. Driverescue, the developer
finished NTFS support before that version was released.
It's possible the source was sold off after that.

The interface on this site, looks suspiciously similar.
But the description doesn't indicate it's been altered
for GPT either. So this probably isn't any better.

http://www.pcinspector.de/?language=1

"File Recovery 4.X"
http://www.pcinspector.de/FileRecove...0&modal=tr ue

I've never done scavenging with driverescue19d, but someone
in the WinXP group years ago, managed to get their
files off a bad disk. That's the only instance I know
of someone trying it.

As far as I know, the $MFT has the pointers to the files.
While $BITMAP keeps track of "used sectors". If $BITMAP
is damaged, maybe that stops writing from happening ?

To transfer the "Busted NTFS Partition" from one disk
to the other, you could use this on at least the
destination. But I don't know if it understands
GPT well enough to work with the source.

http://www.chrysocome.net/dd

http://www.chrysocome.net/downloads/dd-0.6beta3.zip

So the GPT aspect is adding a lot of variables
to the exercise. I suppose I should have thought
a lot harder about that, before getting your
hopes up.

Paul

Nil wrote:
On 11 Dec 2016, Paul wrote in
alt.comp.hardware.pc-homebuilt:

For a job like this, at least two spare drives
are recommended. So you can always have a
"best effort" copy of the data fresh to use
for restoration attempts. No matter what method
you use.

I haven't added any more info for procedures, as I
don't know where Nil is headed with this. Scavenge ?
Or toss ? Or... what ?

Where I'm headed for now is this...

I have acquired 1 free 2-TB drive (you have a good point about having
2, and I may get another one - I can always use it for something
later.) I would like to clone the bad disk to the new disk, but skip
the large main damaged Windows partition. Then I'd like to use the
restore partition to re-install Windows 8 fresh. Then I'll make a set
of Windows restore discs. Then I'll address the task of recovering the
damaged partition from the bad disk.

I've looked a bit at ddrescue. It's complicated - I have to read the
documentation closer. Can I use it to clone the bad GPT drive,
recreating the partition scheme exactly?

A quick datapoint.

https://support.microsoft.com/en-us/kb/315688

"NTFS File System Corruption

In very rare circumstances, the NTFS $MFT or $BITMAP
metafiles may become corrupted and result in lost disk space.

To identify and fix this issue, run the chkdsk /F command
against the volume in question. Toward the end of chkdsk
process, you receive the following message if the $BITMAP
metafile needs to be adjusted:

Correcting errors in the master file table's (MFT)
BITMAP attribute. CHKDSK discovered free space marked
as allocated in the volume bitmap. Windows has made
corrections to the file system.
"

Once you've used ddrescue to make a couple copies of the
hard drive, in may be possible to do an in-place CHKDSK
and fix it (using the known-good disk, not the broken disk).
If the problem is the broken disk cannot write reliably,
perhaps that's why it is jammed up.

So make two copies, one with ddrescue, the second
copy made with regular dd or even an Exact Copy
backup software, then run CHKDSK /f and see
what happens. If it fouls up the drive, you
have the second drive with a good bitmap copy
of the victim.

Paul

On 12 Dec 2016, Paul wrote in
alt.comp.hardware.pc-homebuilt:

There is an area of the disk with the partition
table. You could capture that, if you were a rocket
scientist and could use the parameters in there to
regenerate the same structure on a new disk.

But it's just easier to copy the whole disk and
hope for the best.

This is my plan.

I recommend taking your new 2TB drive, and using DiskPart
command line utility in Windows on it first. Select the
disk, then use the "Clean all" command. This zeros the
new disk.

I took your advice... and 17 hours later it's still cranking away! (The
disk is connected to a *very slow* Win10 netbook, so I'm not
surprised.)

So the GPT aspect is adding a lot of variables
to the exercise. I suppose I should have thought
a lot harder about that, before getting your
hopes up.

I understand the need for technology newer than MBR to accommodate very
large hard disks, but GPT makes most of my old methods and tools pretty
much useless. This is a learning experience. It had to happen
eventually.

On 15 Dec 2016, Nil wrote in
alt.comp.hardware.pc-homebuilt:

On 12 Dec 2016, Paul wrote in
alt.comp.hardware.pc-homebuilt:
I recommend taking your new 2TB drive, and using DiskPart
command line utility in Windows on it first. Select the
disk, then use the "Clean all" command. This zeros the
new disk.

I took your advice... and 17 hours later it's still cranking away!
(The disk is connected to a *very slow* Win10 netbook, so I'm not
surprised.)

The first disk eventually finished its DISKPART clean operation after
about 30 hours. I'm now doing a second disk - it's connected to a
faster computer, which might make some difference, though it's been
cranking away for about 15 hours now.

I'm doing a ddrescue on the first disk now, and it's been at it for 1.2
days. I didn't realize it makes multiple passes. I guess it first
copies the block with no problems, then it goes back and works on the
problem areas. It's now on its 3rd pass, and so far reports 3107 errors
and 293 MB errsize (which I assume is the total size of the bad blocks.
I think those statistics are decreasing, which hopefully means it's
recovering some of that stuff with a little effort.

Good thing I'm not in a hurry to finish this!

It still may be that I'm not able to restore the disk to factory state
even after all this agony. If so, I found mention that the Windows 8
OEM product key may be embedded in the UEFI and if I install any Win8
install media, it will automatically accept that key.

Nil wrote:
On 15 Dec 2016, Nil wrote in
alt.comp.hardware.pc-homebuilt:

On 12 Dec 2016, Paul wrote in
alt.comp.hardware.pc-homebuilt:
I recommend taking your new 2TB drive, and using DiskPart
command line utility in Windows on it first. Select the
disk, then use the "Clean all" command. This zeros the
new disk.
I took your advice... and 17 hours later it's still cranking away!
(The disk is connected to a *very slow* Win10 netbook, so I'm not
surprised.)

The first disk eventually finished its DISKPART clean operation after
about 30 hours. I'm now doing a second disk - it's connected to a
faster computer, which might make some difference, though it's been
cranking away for about 15 hours now.

I'm doing a ddrescue on the first disk now, and it's been at it for 1.2
days. I didn't realize it makes multiple passes. I guess it first
copies the block with no problems, then it goes back and works on the
problem areas. It's now on its 3rd pass, and so far reports 3107 errors
and 293 MB errsize (which I assume is the total size of the bad blocks.
I think those statistics are decreasing, which hopefully means it's
recovering some of that stuff with a little effort.

Good thing I'm not in a hurry to finish this!

It still may be that I'm not able to restore the disk to factory state
even after all this agony. If so, I found mention that the Windows 8
OEM product key may be embedded in the UEFI and if I install any Win8
install media, it will automatically accept that key.

The reason for using DISKPART "clean all" is to get the speed.
If I try doing that on Linux, I don't usually get the speed
out of it. It might take me five to six hours or so on Windows.

You can use perfmon.msc to check how things are going, for
stuff on Windows that actually registers. There are some
operations on Windows you can't get metrics from them.

If a drive takes 30 hours, I would review the SMART
on that drive before using it. Maybe it if was a
12TB helium drive, it might actually take that long.

The ddrescue has a retry count, which you could set on
your second pass. The disk drive itself will do a hell of
a lot of retries, for one retry count at the ddrescue level.
So it may take 15 seconds to reject a sector and move on.
A retry count of 1 is probably sufficient for a "democratic"
retry. Giving each not-yet-captured sector their chance.
Cranking the retry count too high, makes the second pass
depressingly slow.

Linux has "iotop" (bandwidth measure), but if you're on a
LiveCD, you might have to enable "universe" and/or "multiverse"
when trying to fetch the package. A right PITA when the program
should be included on the DVD by default. Same goes for
Synaptic not being right on the disc, and requiring the
same command line recipe, over and over and over again...

If they pulled LibreOffice off the DVD and made that a download,
think how many puny utilities they could include instead.
They could even throw in a copy of "disktype".

Paul

On 08 Dec 2016, Nil wrote in
alt.comp.hardware.pc-homebuilt:

I've agreed to try to fix a friend's computer (HP ENVY Phoenix
h9-1335 Desktop running Windows 8.1 64-bit) and I find myself
confronted with a bunch of newer technology things I've been
avoiding.

You can read the below to catch up if you want. The state of things
now:

The old disk was failing. I cloned it to a new 2 TB hard disk (thanks
so much Paul for the guidance.) The main OS partition was too corrupt
to boot, but I managed to backup most of the files elsewhere. I ran the
restore routine to reinstall Windows 8 as it came from the HP factory,
and then upgraded it to Win 8.1. I recovered the Media Center and
Office 2007 keys from the old registry, so they are now installed. My
friend's music and other data files are recovered as best as possible.
Thanks to everybody for their valuable thoughts during this difficult
re-birth.

This PC came with a 16 GB solid state drive. That drive is dead - it
doesn't respond to power and is not detected in the several computers I
hooked it up to. The drive was apparently used for disk caching, using
a program called ExpressCache. I'm wondering if I should bother
replacing it. Will it really make much of a difference? From what I've
read, ExpressCache may not work with some SSDs, and it looks like 16-GB
drives are scarce these days. I can find some NOS ones, but 32-GB SSDs
can be had cheaper. But maybe they won't work on this system. Dunno.

What do you think? Is it worthwhile pursuing the SSD cache drive, or
should I just let it go?


======= history ========

- The computer has UEFI. Never had to deal with it before.

- The hard disk is 2 TB, partitioned as GPT. Don't know about GPT.

- I think it has an additional small solid state drive - don't
know what for yet.

- There's no VGA port, so I have to scrounge up an adapter to plug
my spare monitor into its DVI port.

One day he turned it on and and got an error message about "no
boot disk found". I have to buy a new USB keyboard and mouse
before I can really check it out, but with the broken USB keyboard
I have, I've managed to get it to boot to a point where Windows
starts to go into a "Recovery" process, but that seems to bomb out
after 5 or 10 minutes. This happens about 1 out of 5 attempts -
the other times I get the "boot disk" error.

I took the HD out and put it in my USB caddy and connected it to
my Win7-64 laptop. The disk shows up in Disk Manager, but I can't
seem to read the files on the main partition (though I can read
the Recovery partition.)

Some questions before I really get into it, which won't happen
until this weekend...

- Can I boot the computer with an optical disk such as Hiram's and
use its diagnostic utilities that I'm used to using on MBR disks?

- If I can't get the computer to boot, how best to access the
files on the disk to back it up or copy stuff off it?

- Any guesses as to what the real problem is? I'm assuming a
failing disk, failing RAM, or failing power supply.

I'll probably have more questions later.

Nil wrote:
On 08 Dec 2016, Nil wrote in
alt.comp.hardware.pc-homebuilt:

I've agreed to try to fix a friend's computer (HP ENVY Phoenix
h9-1335 Desktop running Windows 8.1 64-bit) and I find myself
confronted with a bunch of newer technology things I've been
avoiding.

You can read the below to catch up if you want. The state of things
now:

The old disk was failing. I cloned it to a new 2 TB hard disk (thanks
so much Paul for the guidance.) The main OS partition was too corrupt
to boot, but I managed to backup most of the files elsewhere. I ran the
restore routine to reinstall Windows 8 as it came from the HP factory,
and then upgraded it to Win 8.1. I recovered the Media Center and
Office 2007 keys from the old registry, so they are now installed. My
friend's music and other data files are recovered as best as possible.
Thanks to everybody for their valuable thoughts during this difficult
re-birth.

This PC came with a 16 GB solid state drive. That drive is dead - it
doesn't respond to power and is not detected in the several computers I
hooked it up to. The drive was apparently used for disk caching, using
a program called ExpressCache. I'm wondering if I should bother
replacing it. Will it really make much of a difference? From what I've
read, ExpressCache may not work with some SSDs, and it looks like 16-GB
drives are scarce these days. I can find some NOS ones, but 32-GB SSDs
can be had cheaper. But maybe they won't work on this system. Dunno.

What do you think? Is it worthwhile pursuing the SSD cache drive, or
should I just let it go?


======= history ========

- The computer has UEFI. Never had to deal with it before.

- The hard disk is 2 TB, partitioned as GPT. Don't know about GPT.

- I think it has an additional small solid state drive - don't
know what for yet.

- There's no VGA port, so I have to scrounge up an adapter to plug
my spare monitor into its DVI port.

One day he turned it on and and got an error message about "no
boot disk found". I have to buy a new USB keyboard and mouse
before I can really check it out, but with the broken USB keyboard
I have, I've managed to get it to boot to a point where Windows
starts to go into a "Recovery" process, but that seems to bomb out
after 5 or 10 minutes. This happens about 1 out of 5 attempts -
the other times I get the "boot disk" error.

I took the HD out and put it in my USB caddy and connected it to
my Win7-64 laptop. The disk shows up in Disk Manager, but I can't
seem to read the files on the main partition (though I can read
the Recovery partition.)

Some questions before I really get into it, which won't happen
until this weekend...

- Can I boot the computer with an optical disk such as Hiram's and
use its diagnostic utilities that I'm used to using on MBR disks?

- If I can't get the computer to boot, how best to access the
files on the disk to back it up or copy stuff off it?

- Any guesses as to what the real problem is? I'm assuming a
failing disk, failing RAM, or failing power supply.

I'll probably have more questions later.

Let it go.

Either go with a proper SSD for C: and get the
permanent speed of an SSD.

Or stick with the hard drive.

One of these caching options, has two modes of operation.
The small SSD can contain data which is not on the hard
drive. Or, it can contain data which is also on the hard drive.
The former is dangerous, in cases where the SSD could failed
on you. I think the former case, helps with write performance
or something.

There is apparently an option in the software interface,
to move stuff off the 16GB drive when doing maintenance.
And that ensures the hard drive has a complete copy.

While hybrid drive schemes are amusing, I'll pass.

If you cannot afford an SSD, there is nothing wrong
with modern hard drives. Buy in pairs, with the second
one for your backups.

Paul

On 06 Jan 2017, Paul wrote in
alt.comp.hardware.pc-homebuilt:

Nil wrote:
What do you think? Is it worthwhile pursuing the SSD cache drive,
or should I just let it go?

Let it go.

Either go with a proper SSD for C: and get the
permanent speed of an SSD.

Or stick with the hard drive.

That's what I'm gonna do, stick with the HDD. From what I've read, the
SSD will improve boot time, which is of little importance, and *might*
slightly improve program start-up time, but I doubt that will be missed
by the user. It's better to keep things simple and stable. Besides,
I've spent enough time on this thing. The machine is working well. Time
to move on.

Thanks again for your help. It's been a learning experience.

On Fri, 06 Jan 2017 12:34:44 -0500, Nil wrote:

| On 06 Jan 2017, Paul wrote in
| alt.comp.hardware.pc-homebuilt:
|
| Nil wrote:
| What do you think? Is it worthwhile pursuing the SSD cache drive,
| or should I just let it go?
|
| Let it go.
|
| Either go with a proper SSD for C: and get the
| permanent speed of an SSD.
|
| Or stick with the hard drive.
|
| That's what I'm gonna do, stick with the HDD. From what I've read, the
| SSD will improve boot time, which is of little importance, and *might*
| slightly improve program start-up time, but I doubt that will be missed
| by the user. It's better to keep things simple and stable. Besides,
| I've spent enough time on this thing. The machine is working well. Time
| to move on.

I have SSDs for C: drive on 3 PCs and really don't see a lot of difference over SATA
III HDDs other than startup. Files do open faster, but it's definitely not a night
and day difference. Backups are noticeably faster, though. Also, I like not having
to mess with defragging of system drives before I back them up.

Larc

On 06 Jan 2017, Larc wrote in
alt.comp.hardware.pc-homebuilt:

I have SSDs for C: drive on 3 PCs and really don't see a lot of
difference over SATA III HDDs other than startup. Files do open
faster, but it's definitely not a night and day difference.
Backups are noticeably faster, though. Also, I like not having
to mess with defragging of system drives before I back them up.

In this case, it's just a small 16 GB SSD used for disk caching only.
The main disk is still rotating platters. I think the SSD is of little
consequence.