NTLDR missing, partinfo o/p

[Robin Faichney]

I moved a drive from a client's pc to my own and when it was put back,
after activating the system partition (there's no others), I got
"NTLDR is missing". Attempts to replace it failed so I ran PM off a
boot floppy and got PT error #108. (This is the second time this has
happened recently -- is it something I'm doing?) Forgot to say it's
FAT32 though Win XP Home. After some googling d/l and ran partinfo.exe
but I have no experience with this kind of stuff and would be very
grateful for help. I don't want to lose client's data. Here's the
output:

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: (e-mail address removed)
BiosExtensions: 0x2100 Subsets (0x00000005): Access EDD
EGeo 0x0000 16383 16 63 151221440 0 512


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

Disk 0: 10001 Cylinders, 240 Heads, 63 Sectors/Track.

BiosExtensions: 0x2100 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 [ 0 1 1] 0C [ 785 25 19] 63
151221376 [Large Drive Placeholders]

0 1 1 10001 100 19
Actual Values

Error #109: Partition ends after end of disk.

ucEndCylinder (10001) must be less than 10001.

Error #108: Partition didn't end on cylinder boundary.

ucEndHead expected to be 239, not 100.

Error #108: Partition didn't end on cylinder boundary.

ucEndSector expected to be 63, not 19.




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

Disk 0: 73835.5 Megabytes

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

Volume Partition Partition Start
Total

Letter:Label Type Status Size MB Sector #
Sector Sectors

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

C:NO NAME FAT32X Pri,Boot 73838.6 0 0
63 151221376






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

Boot Sector for drive C: Drive 1, Starting Sector: 63, Type: FAT32

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

1. Jump: EB 58 90

2. OEM Name: MSDOS5.0

3. Bytes Per Sector: 512

4. Sectors Per Cluster: 64

5. Reserved Sectors: 32

6. Number of FAT's: 2

7. Reserved: 0x0000

8. Reserved: 0x0000

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: 151221376 (0x9037480)

15. Big Sectors Per FAT: 19075

16. Extended Flags: 0x0000

17. FS Version: 0

18. First Cluster of Root: 2 (0x2)

19. FS Info Sector: 1

20. Backup Boot Sector: 6

21. Reserved: 0x00 00 00 00 00 00 00 00 00 00 00 00

22. Drive ID: 0x80

23. Reserved for NT: 0x00

24. Extended Boot Sig: 0x29

25. Serial Number: 0x50AC646E

26. Volume Name: NO NAME

27. File System Type: FAT32

28. Boot Signature: 0xAA55

 

[Zvi Netiv]

I moved a drive from a client's pc to my own and when it was put back,
after activating the system partition (there's no others), I got
"NTLDR is missing". Attempts to replace it failed

Attempting to replace the "missing" NTLDR was a bad idea. The file isn't really
missing but is inaccessible because of erroneous disk settings of the CMOS. By
attempting to replace NTLDR with the wrong disk settings you actually worsened
the problem!

so I ran PM off a
boot floppy and got PT error #108. (This is the second time this has
happened recently -- is it something I'm doing?)

Possibly. It didn't happen by itself!

Forgot to say it's
FAT32 though Win XP Home. After some googling d/l and ran partinfo.exe
but I have no experience with this kind of stuff and would be very
grateful for help. I don't want to lose client's data. Here's the
output:
[...]
Disk 0: 10001 Cylinders, 240 Heads, 63 Sectors/Track.

Apparently the drive settings in the CMOS. Note the 240 heads!

BiosExtensions: 0x2100 Subsets (0x00000005): Access EDD
The BIOS supports INT 13h extensions for this drive.
[...]
0 0 80 [ 0 1 1] 0C [ 785 25 19] 63 151221376 [Large Drive Placeholders]

Some of the above parameters make no sense.

0 1 1 10001 100 19
Actual Values

Error #109: Partition ends after end of disk.
ucEndCylinder (10001) must be less than 10001.
Error #108: Partition didn't end on cylinder boundary.
ucEndHead expected to be 239, not 100.

The partition table in the MBR seems to be quite a mess

Error #108: Partition didn't end on cylinder boundary.
ucEndSector expected to be 63, not 19.

Naturally, because of the erratic data.

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

Disk 0: 73835.5 Megabytes

============================= Partition Information
Volume Partition Partition Start Total
Letter:Label Type Status Size MB Sector # Sector Sectors
------------- --------------- -------- -------- ---------- -
C:NO NAME FAT32X Pri,Boot 73838.6 0 0 63 151221376

========================================================================
Boot Sector for drive C: Drive 1, Starting Sector: 63, Type: FAT32
========================================================================
1. Jump: EB 58 90
2. OEM Name: MSDOS5.0

The OEM number confirms that the boot sector was created by XP.

3. Bytes Per Sector: 512
4. Sectors Per Cluster: 64
5. Reserved Sectors: 32
6. Number of FAT's: 2
7. Reserved: 0x0000
8. Reserved: 0x0000
9. Media Descriptor: 0xF8
10. Sectors Per FAT: 0
11. Sectors Per Track: 63 (0x3F)
12. Number of Heads: 255 (0xFF)

Note the discrepancy in the number of heads between the boot sector (255) and
the MBR (240).

13. Hidden Sectors: 63 (0x3F)
14. Big Total Sectors: 151221376 (0x9037480)
15. Big Sectors Per FAT: 19075
16. Extended Flags: 0x0000
17. FS Version: 0
18. First Cluster of Root: 2 (0x2)
19. FS Info Sector: 1
20. Backup Boot Sector: 6
21. Reserved: 0x00 00 00 00 00 00 00 00 00 00 00 00
22. Drive ID: 0x80
23. Reserved for NT: 0x00
24. Extended Boot Sig: 0x29
25. Serial Number: 0x50AC646E
26. Volume Name: NO NAME
27. File System Type: FAT32
28. Boot Signature: 0xAA55

Looks like a quite simple case, that was worsened by careless action.

Misfortune may have first struck by accidentally mounting the drive in a PC with
the wrong CMOS settings for the guest drive, and then forcing the wrong data
into the MBR by some bad manipulation.

To fix the problem do as follows:

Get RESQ from www.resq.co.il/resq.php and prepare a RESQ boot disk as explained
in the ResQ program welcome message.

The following is to be conducted with the problem drive installed as disk 0
(first), in the PC where it belongs! Set the drive type to "auto" in the setup
(modern BIOSes will show the drive's model instead).

Boot of the RESQ floppy just made. When at the A: prompt, run RESQDISK /KILL of
the floppy. This will reset the partition table to zero, then reboot, with the
RESQ floppy in the drive. Rebooting after zeroing the partition table is a
MUST, to let the BIOS re detect the drive, with the correct translation
parameters.

When at the A: prompt, run RESQDISK /FAT32 /REBUILD The program will offer to
write a new MBR when finished with the search. Accept, then reboot, this time
without the floppy in the drive. XP should start normally if you haven't done
more nonsense that you didn't tell us about.

To prevent future damage to your clients' drives, when importing their drive to
your PC, pay attention to set the drive first to "auto" in the setup!

Regards, Zvi

 

[Robin Faichney]

On Sun, 08 May 2005 12:58:04 +0300, Zvi Netiv

<some very useful stuff>

Thanks a million! You and your program are wonderful!

 

[Zvi Netiv]

On Sun, 08 May 2005 12:58:04 +0300, Zvi Netiv

<some very useful stuff>

Thanks a million! You and your program are wonderful!

From the cheerful response I suppose that the drive was recovered fully.

Thanks for the feedback, Zvi

 

[Folkert Rienstra]

Attempting to replace the "missing" NTLDR was a bad idea.

Neither bad nor very smart. If the file system works then obviously there's
nothing wrong with it because drivers (OS, whatever) ignored the bios settings
and/or the MBR CHS settings.

The file isn't really missing but is inaccessible because of erroneous disk
settings of the CMOS.

Wrong. Because of the bootsode using CHS instead of LBA.

By attempting to replace NTLDR with the wrong disk settings you actually
worsened the problem!

Nonsense. It just didn't accomplish anything, that's all.

Possibly. It didn't happen by itself!

So if XP does this to him he is to blame for using XP, right?

Forgot to say it's FAT32 though Win XP Home. After some googling d/l and
ran partinfo.exe but I have no experience with this kind of stuff and would be
very grateful for help. I don't want to lose client's data. Here's the output:
[...]
Disk 0: 10001 Cylinders, 240 Heads, 63 Sectors/Track.

Apparently the drive settings in the CMOS. Note the 240 heads!

BiosExtensions: 0x2100 Subsets (0x00000005): Access EDD
The BIOS supports INT 13h extensions for this drive.
[...]
0 0 80 [ 0 1 1] 0C [ 785 25 19] 63 151,221,376 [Large Drive Placeholders]

Some of the above parameters make no sense.

It's the placeholder comment that doesn't make sense.
Presumably it expects the CHS values *to be* "Large Drive Placeholders",
in other words: to ignore them, and then it goes on to comment on them,
converting them first to non-existant values and then goes on to comment
on those (non existant) values how they must be wrong.
That's what makes no sense.

The CHS values in themselfs aren't Large Drive Placeholders and will
steer the bootcode the wrong way, using CHS Int13 instead of LBA Int13.

The partition table in the MBR seems to be quite a mess

It's what partinfo makes of it that is quite a mess.
CHS values in Partition type 0C should be ignored.
For large drives they should however be 'Large Drive
Placeholders' i.e. largest possible CHS values: 1023 254 63

Naturally, because of the erratic data.

Nope. CMOS and Partinfo itself.

The OEM number confirms that the boot sector was created by XP.

The partiton bootsector, so the partition was formatted by XP.
Doesn't say anything about the partitioning itself.

Note the discrepancy in the number of heads between the boot sector (255) and

the MBR (240).
BIOS.


Looks like a quite simple case, that was worsened by careless action.

If it was you wouldn't be proposing what you are proposing below.

Misfortune may have first struck by accidentally mounting the drive in a PC with
the wrong CMOS settings for the guest drive, and then forcing the wrong data
into the MBR

by some bad manipulation.

Only if he edited the MBR himself.
Else it was some POS program like PM that wrecked it.

To fix the problem do as follows:

Get RESQ from www.resq.co.il/resq.php and prepare a RESQ boot disk as explained
in the ResQ program welcome message.

The following is to be conducted with the problem drive installed as disk 0
(first), in the PC where it belongs! Set the drive type to "auto" in the setup
(modern BIOSes will show the drive's model instead).

Boot of the RESQ floppy just made. When at the A: prompt, run RESQDISK /KILL
of the floppy.
This will reset the partition table to zero, then reboot, with the RESQ floppy in
the drive. Rebooting after zeroing the partition table is a MUST, to let the BIOS
re detect the drive, with the correct translation parameters.

When at the A: prompt, run RESQDISK /FAT32 /REBUILD The program will
offer to write a new MBR when finished with the search.

Accept, then reboot, this time without the floppy in the drive.

You forgot: cross your fingers (that resqdisk will find the partition).

XP should start normally if you haven't done
more nonsense that you didn't tell us about.

Thanks for admitting that replacing the NTLoader wasn't a problem at all.

 

[Zvi Netiv]

Let's start by quoting the OP's reply to my post and rubbing your nose into it:

Thanks a million! You and your program are wonderful!

To your follow-up:

Neither bad nor very smart. If the file system works then obviously there's
nothing wrong with it because drivers (OS, whatever) ignored the bios settings
and/or the MBR CHS settings.

If you used your brain for thinking (you should really try that sometime)
instead of memorizing piles of specs, then you may had come to the correct
conclusion on what happened. FWIM, the file system didn't work!

Wrong. Because of the bootsode using CHS instead of LBA.

Correct. And who is responsible for that? The CMOS settings is!

Nonsense. It just didn't accomplish anything, that's all.

To Robin's luck, but it could have turned the wrong way, easily.

So if XP does this to him he is to blame for using XP, right?

Where from do you bring your idiotic assertions?

Forgot to say it's FAT32 though Win XP Home. After some googling d/l and
ran partinfo.exe but I have no experience with this kind of stuff and would be
very grateful for help. I don't want to lose client's data. Here's the output:
[...]
Disk 0: 10001 Cylinders, 240 Heads, 63 Sectors/Track.

Apparently the drive settings in the CMOS. Note the 240 heads!

BiosExtensions: 0x2100 Subsets (0x00000005): Access EDD
The BIOS supports INT 13h extensions for this drive.
[...]
0 0 80 [ 0 1 1] 0C [ 785 25 19] 63 151,221,376 [Large Drive Placeholders]

Some of the above parameters make no sense.

It's the placeholder comment that doesn't make sense.
Presumably it expects the CHS values *to be* "Large Drive Placeholders",
in other words: to ignore them, and then it goes on to comment on them,
converting them first to non-existant values and then goes on to comment
on those (non existant) values how they must be wrong.
That's what makes no sense.

To Robin's luck, he first acted on my advice and not yours, and recovered the
drive. Although your being correct (probably) about the "large" setting being
the original mistake in the chain of events that led to the problem. Yet your
assertion, above, is useless in explaining to the user how to fix the mess.

Posters with problems have no interest in your pedantry.

The CHS values in themselfs aren't Large Drive Placeholders and will
steer the bootcode the wrong way, using CHS Int13 instead of LBA Int13.

That's correct, and useless now. I also suspect that you acquired that wisdom
only after having read my post and properly deduced the "why" from the "what",
in my advice.

It's what partinfo makes of it that is quite a mess.
CHS values in Partition type 0C should be ignored.
For large drives they should however be 'Large Drive
Placeholders' i.e. largest possible CHS values: 1023 254 63

How is an ordinary user supposed to understand and act upon this useless
book-keeping info? As for myself, I don't need it - fact!

Nope. CMOS and Partinfo itself.

You really can't resist it. ;-)

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

The partiton bootsector, so the partition was formatted by XP.
Doesn't say anything about the partitioning itself.

May I suggest that you dedicate some time in experimenting, hands on, rather
than memorizing specifications.

[...]

If it was you wouldn't be proposing what you are proposing below.

But I did, and it worked. You may choke on it, if you insist. ;-)

Only if he edited the MBR himself.
Else it was some POS program like PM that wrecked it.

How didn't I think of it? ;-) Till now I thought that the MBR edited itself!

You forgot: cross your fingers (that resqdisk will find the partition).

Crossing your fingers is advised in RESQDISK's on-screen messages. From the
result, it helped. ;-)

Thanks for admitting that replacing the NTLoader wasn't a problem at all.

You can't guarantee that the attempt to replace NTLDR had nothing to do in the
chain of events that led to the problem. Obviously you haven't seen yet
everything in disaster recovery.

No comments on this one? ;-)

Regards, Zvi