Disk read error occurred. Press CTRL+ALT+DEL to restart.

[Sylvander]

1. Helping a neighbor.
OS = WinXP SP2.

2. Can boot to Windows OK using Windows NT 4.0, 2000, XP or Server 2003 boot floppy (http://www.nu2.nu/bootdisk/ntboot/).

3. Used Puppy 4.3-beta3->Gparted to:
(a) Scan the partition filesystem and it came up good [no faults, test completed].
(b) Checked, and the boot flag was already set.

4. (a) The 3 boot files are present in the root of C:
(b) Tried restoring a backup of track zero [using Acronis TI 11], but that made no difference.
(c) Also tried the 3 Recovery Console commands [fixboot, fixmbr, plus another if I remember], but made no difference.
(d) Cause of problem = Messed up boot files in the root of C:?
Should I replace them with the copies on the floppy?

5. There is an image backup of C:...
[I made this using Acronis True Image 11...
Prior to copy of partition contents (using Xfe), delete of originals, non-destructive reduction of partition using GParted]...
The restore of the backup eliminates the problem, but trying to avoid using that for a 2nd time, because I want to preserve the changes.

[Paul Komski]

Disk read error is what it says unless proved otherwise. That generally means bad sectors somewhere or a fault in the file system not detected by Puppy.

Since you have an image backup then I would run chkdsk C: /F as the first action assuming that the correct drive has been chosen in the BIOS setup.

Nothing to lose by copying the three boot files for WinXP to the hard drive system partition.

[Sylvander]

1. "generally means bad sectors somewhere or a fault in the file system not detected by Puppy"
(a) Used chkdsk c: /f and also chkdsk /r but found no problems.

2. "Nothing to lose by copying the three boot files for WinXP to the hard drive system partition"
Copied the boot floppy versions of the 3 boot files to the Windows root folder, but that made no difference.

3. Tried using my ptedit+partinfo+edit.com=DOS-Prompt bootable floppy [partinfo] to read the partition info and save it to info.txt, but that failed.
I guess these DOS programs are unable to access the NTFS partition.
Any way to get it to do the necessary?

4. Used my mbrtool+mbrwork bootable floppy to dump the MBR info to mbrtool.dmp.
Will post that asap.

[Sylvander]

Dump MBR for disk 128 (0)

Date for MBR dump is 09-29-2009

000 33 C0 8E D0 BC 00 7C FB 50 07 50 1F FC BE 1B 7C ³ 3ÀŽÐ¼.|ûP.P.ü¾.|
016 BF 1B 06 50 57 B9 E5 01 F3 A4 CB BD BE 07 B1 04 ³ ¿..PW¹å.ó¤Ë½¾.±.
032 38 6E 00 7C 09 75 13 83 C5 10 E2 F4 CD 18 8B F5 ³ 8n.|.u.ƒÅ.âôÍ.‹õ
048 83 C6 10 49 74 19 38 2C 74 F6 A0 B5 07 B4 07 8B ³ ƒÆ.It.8,tö*µ.´.‹
064 F0 AC 3C 00 74 FC BB 07 00 B4 0E CD 10 EB F2 88 ³ ð¬<.tü»..´.Í.ëòˆ
080 4E 10 E8 46 00 73 2A FE 46 10 80 7E 04 0B 74 0B ³ N.èF.s*þF.€~..t.
096 80 7E 04 0C 74 05 A0 B6 07 75 D2 80 46 02 06 83 ³ €~..t.*¶.uÒ€F..ƒ
112 46 08 06 83 56 0A 00 E8 21 00 73 05 A0 B6 07 EB ³ F..ƒV..è!.s.*¶.ë
128 BC 81 3E FE 7D 55 AA 74 0B 80 7E 10 00 74 C8 A0 ³ ¼�>þ}Uªt.€~..tÈ*
144 B7 07 EB A9 8B FC 1E 57 8B F5 CB BF 05 00 8A 56 ³ ·.ë©‹ü.W‹õË¿..ŠV
160 00 B4 08 CD 13 72 23 8A C1 24 3F 98 8A DE 8A FC ³ .´.Í.r#ŠÁ$?˜ŠÞŠü
176 43 F7 E3 8B D1 86 D6 B1 06 D2 EE 42 F7 E2 39 56 ³ C÷ã‹Ñ†Ö±.ÒîB÷â9V
192 0A 77 23 72 05 39 46 08 73 1C B8 01 02 BB 00 7C ³ .w#r.9F.s.¸..».|
208 8B 4E 02 8B 56 00 CD 13 73 51 4F 74 4E 32 E4 8A ³ ‹N.‹V.Í.sQOtN2äŠ
224 56 00 CD 13 EB E4 8A 56 00 60 BB AA 55 B4 41 CD ³ V.Í.ëäŠV.`»ªU´AÍ
240 13 72 36 81 FB 55 AA 75 30 F6 C1 01 74 2B 61 60 ³ .r6�ûUªu0öÁ.t+a`
256 6A 00 6A 00 FF 76 0A FF 76 08 6A 00 68 00 7C 6A ³ j.j.ÿv.ÿv.j.h.|j
272 01 6A 10 B4 42 8B F4 CD 13 61 61 73 0E 4F 74 0B ³ .j.´B‹ôÍ.aas.Ot.
288 32 E4 8A 56 00 CD 13 EB D6 61 F9 C3 49 6E 76 61 ³ 2äŠV.Í.ëÖaùÃInva
304 6C 69 64 20 70 61 72 74 69 74 69 6F 6E 20 74 61 ³ lid partition ta
320 62 6C 65 00 45 72 72 6F 72 20 6C 6F 61 64 69 6E ³ ble.Error loadin
336 67 20 6F 70 65 72 61 74 69 6E 67 20 73 79 73 74 ³ g operating syst
352 65 6D 00 4D 69 73 73 69 6E 67 20 6F 70 65 72 61 ³ em.Missing opera
368 74 69 6E 67 20 73 79 73 74 65 6D 00 00 00 00 00 ³ ting system.....
384 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ³ ................
400 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ³ ................
416 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ³ ................
432 00 00 00 00 00 2C 44 63 00 69 EF 7C 00 00 80 00 ³ .....,Dc.iï|..€.
448 01 01 07 FE FF FF C1 3E 00 00 78 B1 D4 01 00 00 ³ ...þÿÿÁ>..x±Ô...
464 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ³ ................
480 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ³ ................
496 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA ³ ..............Uª
Geometry values (from BIOS!) for this disk : (C/H/S) - 1023/254/63
Partition Table Information
ACT TYPE START-C/H/S END----C/H/S LBA-start LBA-length
Entry 1: 128 07 1 0 1 1023 254 63 16065 30716280
Entry 2: 0 00 0 0 0 0 0 0 0 0
Entry 3: 0 00 0 0 0 0 0 0 0 0
Entry 4: 0 00 0 0 0 0 0 0 0 0
Partition table as shown in MBR :
Entry 1: 80 00 01 01 07 FE FF FF C1 3E 00 00 78 B1 D4 01
Entry 2: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Entry 3: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Entry 4: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ

[Paul Komski]

Tried using my ptedit+partinfo+edit.com=DOS-Prompt bootable floppy [partinfo] to read the partition info and save it to info.txt, but that failed.
I guess these DOS programs are unable to access the NTFS partition.
They access niether FAT nor NTFS partitions. They read the metadata from the MBR and Partition Boot Sectors regardless of the partition type.

http://i38.tinypic.com/2nqxw7m.jpg

Above is the output for my main NTFS system partition as an example.

Possibly your partition boot sector is the main problem. You could try restoring an image but starting at a point a few MB away from where it starts now.

[Sylvander]

1. Tried running the partinfo bootable floppy on my own PC and it worked exactly as it aught to [ptedit looked like the image you displayed].
Partinfo gave a display of LOTS of partition info.
Highlights the fact that it definitely did NOT work as it aught on the neighbours PC, where the display of the info.txt file content was just BLANK!
I'll have a 2nd go at it tomorrow.

2. "You could try restoring an image but starting at a point a few MB away from where it starts now"
Not sure what you mean.
(a) Would the restored image be of the C: partition contents?
Or the Track0 image backup?
Or both?
Acronis TI did both together at the same backup, but they can be restored individually.

(b) And how would I determine/specify the location of the starting point?

3. How about I use the BootMaster Partition Recovery Program (http://bootmaster.filerecovery.biz/recover_boot_sector.html) to do a "BootSector Repair"? [If it displays there is such a need]

[Paul Komski]

And how would I determine/specify the location of the starting point?There are a number of methods but you could first create a brand new small partition (say a tiny hidden FAT 16 partitiojn) at the start of the drive and then restore to the large amount of unallocated space following that partition. That would mean the new boot sector would be at the start of the unallocated space.

How about I use the BootMaster Partition Recovery Program to do a "BootSector Repair"?Nothing to stop you trying it but if the intrinsic problem is with reading from the original area of metadata then it is unlikely to work. It also begs the question of why partition info abreacted.

[Sylvander]

1. Managed to get the partinfo bootable floppy to function on the neighbors PC.
Here's the result:

--------------------------------------------------------------------------
Partition Information Program
Sep 16 2002 - DOS32 Version
Copyright (c) 1994-2002, PowerQuest Corporation
Permission is granted for this utility to be freely copied so long
as it is not modified in any way. All other rights are reserved.

PowerQuest, makers of PartitionMagic(r), Drive Image(tm) and DriveCopy(tm), can be reached at
Voice: 801-226-6834 Web site: http://www.powerquest.com/support/
Fax: 801-226-8941 Email: help@powerquest.com
BiosExtensions: 0x3000 Subsets (0x00000005): Access EDD
EGeo 0x0000 16383 16 63 234441648 0 512


================================================== ==========================

Disk 0: 14593 Cylinders, 255 Heads, 63 Sectors/Track.

BiosExtensions: 0x3000 Subsets (0x00000005): Access EDD
The BIOS supports INT 13h extensions for this drive.

============================ Partition Tables ==============================

Partition -----Begin---- ------End----- Start Num

Sector # Boot Cyl Head Sect FS Cyl Head Sect Sect Sects

---------- - ---- ---- ---- ---- -- ---- ---- ---- ---------- ----------

0 0 80 1 0 1 07 [1023 254 63] 16065 30716280 [Large Drive Placeholders]

1 0 1 1912 254 63 Actual Values




================================================== ================================

Disk 0: 114471.0 Megabytes

============================= Partition Information ==============================

Volume Partition Partition Start Total

Letter:Label Type Status Size MB Sector # Sector Sectors

------------- --------------- -------- -------- ---------- - ---------- ----------

Unallocated Pri 7.8 None - 63 16002

NTFS Pri,Boot 14998.2 0 0 16065 30716280

Unallocated Pri 99464.9 None - 30732345 203704200






================================================== ======================

Boot Sector for drive *: Drive 1, Starting Sector: 16065, Type: NTFS

================================================== ======================

1. Jump: EB 52 90

2. OEM Name: NTFS

3. Bytes Per Sector: 512

4. Sectors Per Cluster: 8

5. Reserved Sectors: 0

6. Number of FAT's: 0

7. Root Dir Entries: 0

8. Total Sectors: 0 (0x0)

9. Media Descriptor: 0xF8

10. Sectors Per FAT: 0

11. Sectors Per Track: 63 (0x3F)

12. Number of Heads: 255 (0xFF)

13. Hidden Sectors: 63 (0x3F)

14. Big Total Sectors: 0 (0x0)

15. Unused: 0x80 00 80 00

16. Total NTFS Sectors: 30716272 (0x1D4B170)

17. MFT Start Cluster: 786432 (0xC0000)

18. MFT Mirror Start Clust: 1536215 (0x1770D7)

19. Clusters per FRS: 246

20. Size per Index Buffer: 1

21. Serial Number: 0x8A68A2E868A2D26D

22. Checksum: 0x00000000

23. Boot Signature: 0xAA55
--------------------------------------------------------------------------

2. Tried the BootMaster v5.0 bootable floppy.
It showed all [the NTFS partition] was good.

[Paul Komski]

The more I think about this the more I think this is a BIOS or motherboard related problem particularly since you can boot with the floppy and since the message sounds like a BIOS message.

I would double check cables as a matter of course but more importantly reset to defaults or reset with a new CMOS battery, update ESCD. Etc, etc.

[Sylvander]

Surely it has to be something on [written to] the HDD that's at fault, because it can be easily fixed just by restoring the image of the Windows partition.

e.g.
1. the message sounds like a BIOS message"
This sounds true to me, because I notice that the warnings included in the MBR do NOT include the warning given [as in the post title] during the attempt to boot Windows using the HDD boot arrangements.

2. I think this is a BIOS or motherboard related problem"
This would mean the motherboard+BIOS has no problem booting any bootable floppy, but it does have a problem booting this particular HDD, yes?
If so, how is it that it's possible to fix simly by restoring the image of the Windows partition?

3. double check cables as a matter of course but more importantly reset to defaults or reset with a new CMOS battery, update ESCD"
Again, if any of these things were at fault, surely it would NOT be possible to produce a fix simply by restoring the image of the Windows partition.
My neighbor isn't keen to begin messing with the innards of his PC, especially when it's me who suggested moving his data files off C:, reducing his Windows partition, and making new additional partitions to take the data files.
Will take a look in the BIOS setup though.
We did make a configuration change within his BIOS setup, to rearrange his boot menu sequence.
Strange arrangement...
The order is:
Optical disk, FDD, HDD...[present setting]
And they cycle in that order.
[Cannot put them in ANY order you like]
e.g.
FDD, HDD, Optical disk...
HDD, Optical disk, FDD...
But NOT:
FDD, optical disk, HDD.

[Paul Komski]

I obviously missed "The restore of the backup eliminates the problem, but trying to avoid using that for a 2nd time, because I want to preserve the changes."

It, (or possibly a Windows Repair installation), maybe your only option and until you have tried another restroe of the backup you cannot be sure it will work again.

Any chance of it booting if HDD is first in the boot order options? If you cant change the setting at least try failsafe defaults and ensure that no floppy nor CD disks are in their respective drives.

[Sylvander]

1. We studied his BIOS Setup configurations, but saw nothing amiss.

2. "possibly a Windows Repair installation), maybe your only option"
Keeping that as a fall-back position.
Problem is:
His XP installation is up to SP3 right now, and the XP installation disk [how to check if it's retail?] doesn't include any service packs.
Would a repair with that cause the loss of the SP's?
And then we'd need to reinstall them?
A lot of work?

3. "Any chance of it booting if HDD is first in the boot order options?"
Didn't see any sign of that making any difference, but could give it a go.
When we boot with the present boot order [optical, floppy, HDD], with the optical and floppy empty...
[Possibly USB Flash Drive and USB external HDD connected, but saw no sign that the BIOS can boot USB]
Seems there is an attempt [by the BIOS] to boot the HDD.
Previously it gave a < and beneath that a flashing cursor.
Now it gives the warning in the title of this thread.

4. To recapitulate:
(a) The Windows files are OK. [Load/run OK using the floppy]
(b) The Windows partition filesystem is OK. [Tested OK using GParted & chkdsk]
(c) The 3 boot files are [probably] OK. [changing them to good copies doesn't fix the problem, so problem is prior to that point]
(d) The MBR & PBS both seem OK. [Examined or tested]
(e) The problem exists within a region included in the image of the Windows partition, yes or no?

5. I need to study the boot sequence in detail.

[Paul Komski]

To recap:
a) If you can boot to Windows from the floppy then the windows partition is OK and the only files that could be implicated are the three/four main boot files found in the root of C.

b) If you cannot boot the same setup directly from the hard drive then the BIOS cannot or is not effectively communicating with the PBS of the system partition. That implies a bad MBR or a bad PBS or a BIOS malconfiguration that is not finding or is unable to read the MBR and/or the PBS

The problem exists within a region included in the image of the Windows partition, yes or no?Don't see how it can be when the partition starts up OK from the boot floppy. Thus hal.dll and all the other paraphernalia in the Windows partition must be OK.

Restoring the same image to a different hard drive should sort out whether the problem is hard drive or BIOS.

[Sylvander]

1. "a) If you can boot to Windows from the floppy then the windows partition is OK and the only files that could be implicated are the three/four main boot files found in the root of C"
(a) Just to make sure, we completed an XP No-Reformat, Nondestructive Total-Rebuild (http://www.informationweek.com/news/windows/showArticle.jhtml?articleID=189400897).
That seemed to go well, although there's still a window displaying right after completion of boot referring to...
%System Root%\System32\shell32.dll
Need to fix that, but don't know how[fix the Windows path variable?]

(b) I tried temporarily replacing the existing HDD copies of ntdetect.com & ntldr, but didn't try replacing the existing boot.ini which still has the following content:
------------------------------------------------------------------------------------------------------
[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOW S
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Home Edition" /noexecute=optin /fastdetect
-------------------------------------------------------------------------------------------------------

2. "That implies a bad MBR or a bad PBS or a BIOS malconfiguration that is not finding or is unable to read the MBR and/or the PBS"
What should I do about those?
Repartition the drive, reformat the new partitions, install Windows anew?
My neighbour is willing to do that.
His Windows disk includes SP2 [my error previously to say he had no SP's included].
It's an OEM disk [with code] included with the PC.

3. "Don't see how it can be when the partition starts up OK from the boot floppy. Thus hal.dll and all the other paraphernalia in the Windows partition must be OK"
(a) Does the image of the Windows partition include the PBS and/or MBR?
I expect not, but surely the backup of track0 made by Acronis TI would include, yes?
And I restored the backup of track0.

4. "Restoring the same image to a different hard drive should sort out whether the problem is hard drive or BIOS"
(a) But, but, but...
If I restore the image to the EXISTING HDD it fixes the problem...
So if restoring to a DIFFERENT HDD, and it works, what's the difference?
Doesn't prove anything surely.

(b) Or are you suggesting I make an image of the PRESENT Windows setup in the SHRUNK partition...
And restore THAT to a different HDD?
If that worked it would suggest the existing HDD [HDD1] is somehow at fault.
I don't foresee my neighbour coming up with an extra 120GB+ HDD though.

[Paul Komski]

but surely the backup of track0 made by Acronis TI would include, yes?
If there is any read/write malfunction going on in that area you can attempt to replace it any number of times and it probably wont "stick".

The restore of the backup eliminates the problem, but trying to avoid using that for a 2nd time,Unless you do it for a second time you wont know whether it will solve the problem a second time.

I reiterate that if you can boot the system from the special floppy then the problem almost certainly has to be with the mbr, the pbs, the three boot files or with the BIOS not finding the hard drive's MBR for whatever reason. Trying any second hand hard drive or moving the partition from the start of the drive have already been suggested.

Does the image of the Windows partition include the PBS and/or MBR?Not unless you cloned the whole hard drive with something like a linux dd.

I don't follow the %System Root%\System32\shell32.dll message and exactly where it comes in the boot process. I would think that a parallel installation could be a better troubleshooting approach than a repair.

[Sylvander]

WoooHooo! :)

SUCCESS! :D :cool:

Used testdisk.exe to do the fix, roughly as follows:
A. Just followed the various prompts and did what seemed sensible.

B. It detected the HDD, and the bootable Primary Partition in use.

C. Got it to scan deeper. Scan was somewhat slower than the others.

D. It listed 4 partitions as follows:
____Partition________Start_________End_______Size in sectors
1* HPFS-NTFS______1-0-1______1912-254-63____30716280
2__HPFS-NTFS_______0-1-1______1530-254-63____24595452
3__HPFS-NTFS_______1-0-1______1912-254-63____30716280
4__HPFS-NTFS_______1-0-8______1912-254-63____30716273

E. Looked to me like partition 3 [same as partition 1 = the one in use] was the correct one, but when I tried to select it and proceed was told that it had been deleted.
There was mention of a corrupted file system at one point.

F. Highlighted 4 instead and proceeded with that.
Was given the option to Rebuild Boot Sector, so did that [happened in a blink].

G. Given the option to Search MFT, so did that.
I think was told there were differences between MFT in use and the MFTmirror, so fixed the MFT.

H. Offered the option to boot the partition and did that.
And Windows XP BOOTED!
I imagine if I knew well how to operate this program, the fix would have been really easy.
As it was, it wasn't exactly difficult.
--------------------------------------------------------------------------

I. "I don't follow the %System Root%\System32\shell32.dll message and exactly where it comes in the boot process"
This is a windows that opens immediately after Windows has booted to the desktop.
I/he can close the window by clicking the X, but it's a pest.
Unrelated to the above problem I believe.
Should I post that in a different thread, or attempt to fix it here?

[Paul Komski]

It's good that you got success but it's not obvious which boot sector was fixed; in particular the MBR or the PBS. The most normal one of the four PBS positions (three since two are identical) is the second one with CHS 0-1-1 being normally equivalent to 63 sectors from the start of the drive.

1-0-1 (at a full one cylinder boundary into the drive) is often where one would find an extended partition sector if an extended partition is placed at the start of a drive but 1-0-8 is a most unusual value.

PTEdit would show you the current CHS value(s) for the primary partition(s) of the MBR's partition tables. If you have a backup of the MBR done prior to the repair then it would be possible see if that value has changed in the interim.

I think was told there were differences between MFT in use and the MFTmirrorIt's a pity you don't know for sure. The fact that the floppy booted the system OK implies that a corrupt MFT was not a cause of any problem since it exists within the boundaries of the booted partition - and being at the heart of its file system.

If the PBS has been the problem from the start then fixboot should have mended it but I have seen plain fixboot not work whilst specifying the partition in addition (as in fixboot C:) has been successful. But, as I said, if the PBS is at 1-0-8 and that remains the case, it is a most odd value.

[Paul Komski]

I forgot that you had posted the hex of an MBR and the relevant part of it are the three bytes in blue:

432 00 00 00 00 00 2C 44 63 00 69 EF 7C 00 00 80 00 ³ .....,Dc.iï|..€.
448 01 01 07 FE FF FF C1 3E 00 00 78 B1 D4 01 00 00 ³ ...þÿÿÁ>..x±Ô...

These translate to (http://mirror.href.com/thestarman/asm/mbr/PartTables.htm) a CHS value of 1-0-1 so any boot code using that MBR would have been looking at that position for the PBS.

PS
It is also not beyond reason that if that referenced sector was corrupt in some way then that could possibly have resulted in the Disk Read Error warning once the bootstrap routines from the BIOS reached that point in the boot process.

[Sylvander]

1. Regarding my logical reasoning that the problem had to exist within that region of the HDD covered by the image backup of the partition:
(a) Does this fix bear that out?

(b) I wish I knew enough to have a mental image the things that the image backup included.
The folders and files on the partition I understand, but not the other things.
Got any info that includes a visual display?

2. "if the PBS is at 1-0-8 and that remains the case, it is a most odd value"
(a) That's what we thought when we saw it...
And didn't want to use it...
But then it seemed to be the only [sensible = 15GB partition] one that could be used [Number 2 was only 12GB]...
[But yet it was 7 sectors too small = missing, because the start was too far in]
And then it was being displayed that it could be used and fixed...
So we gave that a go...
And it WORKED.
Pure beginners luck.

(b) I got the program to make a log during the process, and it's on the floppy...
But I cannot get any text file programs [Notepad, Wordpad, Leafpad, etc] to open it.
Attempting it in BoxPup made %CPU usage jump to 100% and the OS froze.
Had to Ctrl+Alt+backspace to drop to a command prompt and use the reboot command.
Any idea how to read/copy/paste that log?
.
.

[Paul Komski]

Does this fix bear that out?I'm not sure just what was fixed. One of three possibly corrupt PBSes or the relevant reference in the only partition table shown in the MBR dump you posted; (there is no reference to a second partition in that MBR Hex nor in the data from PartitionInfo).

The results from PartitionInfo show things a bit more elaborately. There is an unused complete cylinder (so-called unallocated primary partition) at the start of the drive and then an approx. 15 GB ACTIVE partition starting at CHS 1-0-1 followed by some 100 GB of further unallocated space (another so-called unallocated primary partition).

Much indication of what exactly was done would be gleaned from another MBR dump, from the info seen in PTedit or in repeated results from PartitionInfo. Conjecture will not be of any real help in understanding what exactly happened.

The geometry suggests that there was at one time either DDO or an Extended partition at the start of the drive and which was "deleted" and a primary boot partition replaced at the "start" of the drive.

Replacing an image file apparently fixed things on one occasion. When this is done to exactly the same LBA that the MBR is referencing then that would be normal. If it is replaced but to a different offset and the MBR not updated in parallel by the user or the software - then problems would obviously ensue.

It's only a guess but it looks as if the linkage from MBR to PBS, which originally was OK, became broken in some way and it looks as if either the PBS at 1-0-1 (as referenced by the MBR) was repaired in fixboot fashion or else the MBR was updated to reference a misaligned but otherwise normal PBS at 1-0-8.

Another possibility is that there were two partitions on the drive with the first being a System partition containing a boot.ini that was referencing a second Boot partition containing the Windows folder but that it was this second partition that was or became unreferenced or mis-referenced for some reason.

Any idea how to read/copy/paste that log?If the file is not corrupt any hex editor should be able to give it a whirl. Can the file be copied and pasted or can chkdsk be run on the floppy?

[Sylvander]

1. "the MBR was updated to reference a misaligned but otherwise normal PBS at 1-0-8"
That sounds right to me. :)

2. "Can the file be copied and pasted"
When I tried to copy & paste the log it was reported that the file was corrupted.
So I tried to use eraser to erase it, but that didn't work.
So I deleted it, which worked.

3. "Much indication of what exactly was done would be gleaned from another MBR dump, from the info seen in PTedit or in repeated results from PartitionInfo"
Must try to remember to get you that info.
Have written a note to self.

[Paul Komski]

That sounds right to me.Possibly - but partitions not starting on cylinder boundaries is very very far from the norm on anything pre-Vista.

Is there just one or are there two partitions on the relevant hard drive?

[Sylvander]

1. "Is there just one or are there two partitions on the relevant hard drive?"
(a) Right now there is only the one 15GB partition.
BUT, various operations were carried out as follows:

(b) The original 120GB partition was SHRUNK/reduced, perhaps to 25GB [can't remember the 1st size used] with contents still in place.
[AFTER an image was saved (using Acronis) and also the folder file contents copied (using Xfe)]
After this we found XP wouldn't boot using the HDD arrangements.

(c) I think we then restored the image of the 120GB partition.
Back to square 1?

(d) We had moved [actually copied and deleted the originals] his personal data files off C: to his external USB2 HDD which reduced the space occupied, but I was surprised by 3GB of content still in place after attempting and failing to delete ALL of the contents of C:
SHRANK the 120GB partition to perhaps 12GB [can't remember].
Tried copying his folders/files back, but they were to big for the available space.
So he accepted my suggestion to exclude all of the restore point files [they were HUGE; occupied about 6GB!]
At some point we increased the partition to 15GB.

(e) Eventually, [with difficulty] we succeeded in copying ALL of the chosen set of folders/files content back to C:
There's only about 8GB of folders files, yet they wouldn't go into 12GB [because of the mysterious 3GB of unknown content?]

(f) We weren't quite up to the business of keeping notes whilst tearing at our hair and wondering what the heck was going wrong.
Even the normally simple process of copying and deleting, and returning/writing files was going anything but routinely.

2. At one point we added a small [3GB?] FAT32 partition [right at the (other) END of the drive] for holding Puppy Linux pupsave files...
But at this time that has been eliminated and one [3 GB FAT32?] made instead at the end of his 1000GB external HDD.
That's working well, and seems like a good idea to store it on an external [we can play with the internal as much as we like using Puppy].
The only other partition on there right now is a 250GB partition [can't remember the formatting/filesystem].
The remainder is unallocated [I remembered your recommendation; I'm learning].

[Paul Komski]

If I can precis in another way.

1)You backed up files and made a full image file.

2) You resized down with GParted and then couldn't boot from the HDD but could boot from the WinXP QuickBoot diskette. Ergo - GParted's resizing had corrupted the communication between MBR and PBS. It is well known that so-called non-destructive resizing is not without risk. Reinstating the image file, unsurprisingly, got you back to square 1.

3) There were problems copying/moving files to the external (?FAT) partition and 3GB of something anonymous remainded on C but its not clear if this was done from the 120gig partition or the shrunken partition and whether it was done by xfe or Windows accessed via the floppy boot or whatever.

The simple thing to say is that moving files from NTFS partitions is not always as straightforward as it might appear to be - whether done from within windows or without.

The 3GB missing data might well have been findable using ExplorerXP or WinDirStat or else there was intrinsic corruption of the files system that chkdsk might have fixed.

I will hazard a guess that the PBS will still be at 1-0-1 in the current MBR and that something had been astray with the PBS after GParted had resized and that TestDisk repaired. I have known fixboot on its own not repair a PBS but for it to then succeed if the partition letter is suffixed to the command as:
fixboot C:

BTW I only "non-destructively resize" (or defrag) after having first done a chkdsk /F. Any resizing done in the presence of file corruption can be very dodgy. Scanning with non-windows utilities may be effective but maybe they do not do quite the same things.

[Sylvander]

The above is mainly correct, but I'd add the following:

A. "There were problems copying/moving files to the external (?FAT) partition"
1. The copy [from source (NTFS) to destination (NTFS) using Xfe within Puppy] went well; it was the the subsequent deletion of the originals [on C:], and then the copy back [from destination to source using Xfe within Puppy] that didn't go well.
The destination was [certainly at the last, and probably right at the start] an NTFS partition.
Wanted to make sure of copying from NTFS to NTFS.

2. Was forced to use BartPE to complete the deletion of the source files, and then successfully complete [I incorrectly thought] the copy back from the destination to source.

3. The copy back was actually fully completed successfully, only by using SyncBack->[under WINE]->within Puppy.
It detected 55 pages of files not copied over from destination to source.
It took a couple of runs to get all but 1 file copied. [Space short, so excluded the 6GB of "Restore Point" files]
I excluded that [un-needed] file from future comparisons, and the last run was rated as "Success".
If I remember, there were problems of not enough space to take all of the folders/files during the process, so deleted the [6GB of] "Restore-point" files from the set being used by SyncBack.
These began as a [2nd] copy of the destination fileset [1st copy] copied from C:
[May seem complicated, but isn't when you have them before you]
Did that so I could have an original copy plus a manipulated/altered/reduced 2nd copy to play with.

B. "3GB of something anonymous remainded on C"
1. My 1st guess was that this was a HUGE partition table or some-such.
I've read that partition table can be very large if the partition is very large.
But it could have been undeleted [lost?] files.

C. "its not clear if this was done from the 120gig partition or the shrunken partition and whether it was done by xfe or Windows accessed via the floppy boot or whatever"
1. The original attempt to delete, was of the contents of the 120GB partition, using Xfe.
But that reported a failure to completely delete EVERYTHING, so...

2. I booted a BartPE CD, and used the included Windows file explorer to delete the remainder from the 120GB partition.
That appeared to succeed.

D. "The 3GB missing data"
1. That problem existed at the point where we were attempting to delete all the files on the partition, and had to resort to using BartPE to succeed.
We had been trying to use a 12GB partition to hold 8GB of files [6GB of "Restore Point" files excluded], and it wasn't working, so we [deleted the 3GB of files using BartPE, and also] increased the partition size to 15GB.
Can't remember the exact sequence.

2. We were using WinDirStat within Windows loaded using the floppy, and also "Space Monger-portable->[under WINE]-within-Puppy" [my favourite] to study space usage.


E. "I will hazard a guess that the PBS will still be at 1-0-1 in the current MBR and that something had been astray with the PBS after GParted had resized and that TestDisk repaired"
I think you're spot on there.

F. "I only "non-destructively resize" (or defrag) after having first done a chkdsk /F"
I believe we did the "Puppy->GParted->[choose partition]->Check" version of this prior to the "non-destructively resize".
I believe I did everything I aught, but...
The best laid schemes of mice and men, go oft askew ["gang aft agley"].

[Paul Komski]

Whatever happened there was a point at which possibly both metadata and files systems seem to have become corrupt. Perhaps being less aggressive in resizing downwards would have been better. The alarm bells should have been ringing when data couldn't be deleted. At that point it would probably have been wise to have done a full (not quick) reformat of the partition (format C: /FS:NTFS from a RecoveryConsole for example (http://support.microsoft.com/kb/314058)) or at least have run chkdsk /F or whatever equivalent you preferred from Linux.

I don't know how Linux and Windows differ in their aggressive/repair modes but chkdsk doesn't just deal with the normal file system but also with metadata elements such as the MFT.

B. "3GB of something anonymous remainded on C"
1. My 1st guess was that this was a HUGE partition table or some-such.
I've read that partition table can be very large if the partition is very large.
But it could have been undeleted [lost?] files.

I don't know what you attempting to refer to since the partition tables are tiny elements (64 bytes in fact) within the MBR. A pagefile can be that sort of size as can a hibernation file. The MFT's size is not reported without specialist software but even on moderately large partitions with a lot of files seldom exceeds a couple of hundred MB and is normally under 50MB. An overfull partition of mine with numerous small files has metadata files as outlined in the attachment. The MFT is never much bigger than it needs to be. It start's out relatively small but unlike the fixed size FAT tables grows (in chunks) in line with the number of files added to the system.

[Sylvander]

1. "I don't know what you attempting to refer to"
I used incorrect terminology there.
What I was attempting to refer to was that it might be the NTFS version of what otherwise [had it been formatted as FAT32] might have been a FAT32 file allocation table for the partition.
I believe I'd read somewhere that for HUGE partitions that can become rather large.
At the time I saw the unexplained 3GB I was searching my memory for some idea of what might explain it, and that's what popped up.
I don't know much about the NTFS file system.

[Paul Komski]

The MFT is the nearest equivalent to a F.A.T. under NTFS. Everything in the NTFS file system (including folders) is a file under NTFS and every file is referenced from a minimum of one entry in the MFT; the $MFT file. The starting position of the MFT is defined/found in the PBS of the volume in question.

In order to avoid defragmentation of the MFT itself (which can impact on performance) the system normally initially reserves 12.5% of disk space for expansion of the MFT within that space as files are added to a system. Only if the MFT expands to beyond that amount is the MFT liable to defragmentation as another chunk of space gets added for further enlargement of the file.

12.5% of 120 gig would be 15 gig so this reserved space would be affected if a 120 gig partition was reduced this sort of level (as seems to have been done in this instance) - even if the MFT at that point in time was not particularly large in itself. I don't know to what level GParted will limit downsizing but with BiNG there is always a stated minimum value.

This copying of files, their subsequent deletion and copying back is I believe done by you to create a "defragmented" volume but you should realise that this will both enlarge the MFT unnecessarily and leave it very full of "holes". Some of that is written about in the following two links. I have said it before and I will say it again that there is no need to excessively or repeatedly defragment NTFS volumes and that unless defragmentation is very severe (the MFT itself apart) there is very little impact, if any, on performance. The way that an NTFS volume indexes its content and the way that data is mapped is done in a radically different way than under FAT volumes.

How to locate and correct disk space problems on NTFS volumes (http://support.microsoft.com/kb/303079).

How NTFS reserves space for its Master File Table (MFT) (http://support.microsoft.com/kb/174619)