I ran Bootfix to fix a boot issue, now I'm getting Disk Read Error.

Would a Recovery Console Disk work ...?

Yes, that would do the equivalent (same) job.

Edit: Sorry about awhile back there, I lost my internet connection for 40 minutes straight. Thankfully, NeverSayDie thought it was an opportune time to chime in.

Alright, well, I have XPCD.iso, or whatever it's called. Now all I have to do is launch it. Somehow I have to make a disk of it, and then I'm home free.

So close, yet so far away. Yet SO CLOSE. The solution is as easy as running Recovery Console!

The solution is as easy as running Recovery Console!

Yes, it should be ... fingers crossed!

Before you get started on doing anything else, could I get you to provide me with a copy of the VBR, probably more for my own curiosity than anything else. It is the same procedure as you have used previously for the MBR, only with two little changes in the command that you need to run, which will be:

dd if=/dev/sdb1 of=vbr.bin bs=512 count=1

The two changes are:

• Use sdb1 instead of sdb (assuming hard drive is still represented as sdb)
• Use vbr.bin instead of mbr.bin

Thank you.

=========================
I thought it might be interesting to see the changes that running fixboot might make (if/when you get to run it):

• Compare a before and after snapshot of the VBR.

I have collected the VBR dump of an XP installation, with just one partition on the hard drive. This is what it looks like viewed with a hex editor:

 VBR-GJN.bin.png   72.93K   12 downloads

Note the "A disk read error occurred." standard error message on the right hand side.

• That error message should look familiar to you.

Hi

I looked into the MFT mirror having an LCN of 16 on an XP install and the information I found was inconclusive.

Usually on an XP install I see the MFT mirror located past the MFT at a higher LCN. On Windows 7 I often see it at LCN 2.

When I did a search for others with it located at LCN 16 I only found people with MFT problems (they can't see their files but you can) but there are too many variables to say that it is indicative of a problem.
mftmirr_lcn 16 might be perfectly normal and fine.

Here is the root of the question that would determine if it was the problem. Is LCN 16 damaged or does not actually contain the MFT mirror?

If the extrapolation routine in Testdisk simply pulls the second record of the MFT to get this value but does not actually check for its existence while the BIOS actually checks for its existence then I could see this being the problem. Unfortunately, I don't have time to look at Testdisk's source code today and I don't see anything you did that would have affected this.

If FIXBOOT does not work, you'll need to run chkdsk /r in the recovery console to see if it repairs any MFT problems. I advise you to backup any important data on the drive before trying this step.

Questions.
Did you ever resize that partition (maybe with GParted for example)?
Did you used to have Windows 7 or Vista on that drive?

Also, I look forward to seeing your VBR per AustrAlien's instructions.

James

Sorry folks, I couldn't get on today. But here's that VBR dump. Hopefully it's corrupt, so we can finally know what's wrong.

EDIT: Also, I never resized the partition, and I've only ever had Windows XP on this drive. As far as I know. It might've had something else on it before I got it.

Also, I can run CHKDSK on one of my working computers if need be. That'd be a more effective thing to do than Fixboot, you say?

VBR view in hex editor:


The NTFS Bios Parameter Block:


Note: Green highlighted bytes differ from my own VBR dump.

Comment: I am feeling optimistic about a resolution, based on what I am seeing.

• Consulting with my colleagues and will get back to you (one of us will) when we have discussed the matter and made a decision on the next step.

An interesting reference FYI:

• An Examination of the NTFS Volume Boot Record
  from The Starman's Realm

Also, I can run CHKDSK on one of my working computers if need be. That'd be a more effective thing to do than Fixboot, you say?

CHKDSK could possibly fix it if fixboot does not work. Only if the MFT mirror value is causing the problem (we don't know) and fixboot pulls the wrong value too (if the second record in the MFT on that drive is in fact wrong).

fixboot is safe and fixes everything about the VBR

chkdsk is dangerous and might fix it or make it worse.

I've been doing this a long time and am pessimistic about chkdsk because of problems in the past. I may be overly critical since Microsoft has always worked to make chkdsk better and safer for many years now.

That's why I said to backup important data before trying the chkdsk step. It's kind of a 'last chance shot in the dark' if fixboot does not repair the problem

James

I believe that the VBR may be pointing at the wrong/non-existent drive to boot from.

The NTFS Bios Parameter Block:


Note: Green highlighted bytes differ from my own VBR dump.

Look at the smaller of the two red-outlined boxes in the above image:

thestarman says of this "should never vary between NTFS Systems":

• First byte:80h is the drive number !

  thestarman: http://thestarman.pcministry.com/asm/mbr/NTFSBR.htm#7C7B

It should read "8000 8000", and not "8100 8000".
==========================

Let's change that value in the BPB and see what happens.

• I am going to change that to read ""8000 8000" and attach the amended VBR to this post.

Please download the attached vbra.zip file and extract (right-click > Extract All...) the vbra.bin file to the xPUD flashdrive.

• Copy the VBR to the first sector of the Windows system drive by running the following command in the usual manner:
  
  dd if=vbra.bin of=/dev/sdb1 bs=512 count=1
  
• Shut down xPUD and remove the flashdrive.
  
• Attempt to start the computer normally to load Windows. Success?

Alrightee then, let's try that, I'll try it in a sec.

I believe that the VBR may be pointing at the wrong/non-existent drive to boot from.

I believe it is also responsible for the abnormal behaviour exhibited in xPUD of showing the internal hard drive as sdb instead of sda.

I would appreciate it if you would boot to xPUD again after making the planned VBR change and letting me know whether the internal hard drive is now represented as sda or not.

Eureka! It boots again!

Kinda.

I'm not longer getting Disk Read Error. It boots all the way to the Windows Advanced Options Menu, to the Windows XP splash screen, and onward. The damages done by Bootfix are, as of now, officially undone. Mission accomplished.

BUT...

After the Windows XP splash screen is done, I get to a black screen that hangs for a long time. This was the problem I brought out Bootfix for. Should I just wait it out, or should I open up a new thread for this?

Still, commendable work, ladies and gentlemen. From the people who posted, to the silent partners who watched and most likely weighed in elsewhere. Current state of the malware removal and faulty user error repairing arts INDEED! If anyone's earned handsome Paypal donations it's the present company. But first I need to see about fixing this hang here, and then seeing if my malware problem is handled.



EDIT: And in xPUD, the main hard drive is still SDB. I still haven't figured out why, but right now I'm not that concerned. This is a big victory for you guys.

Eureka! It boots again! ...

It boots all the way to the Windows Advanced Options Menu, to the Windows XP splash screen, and onward. ...

After the Windows XP splash screen is done, I get to a black screen that hangs for a long time. ...

Very good!

Now, I need to determine whether or not you are able to successfully start Windows at all:

• in Safe Mode, or Safe Mode with networking or Safe Mode with Command Prompt.
• normally .... after waiting patiently .... for up to 2 hours.

I have to ask, because I am not sure given what you have posted.

Thank you for testing with xPUD:

• The mystery remains yet to be solved in that case!

Alright, I'll give it two hours. Hold on, this is gonna take a while...

You may also need that level of patience when attempting Safe Mode etc.