Chkdsk error "The second NTFS boot sector is unwriteable"
When I run CHKDSK /R on my Windows 7 partition everything verifies OK except at the very end I get this error :
"Write failure with status 0xc0000015 at offset 0x1dcf34de00 for 0x200 bytes.
The second NTFS boot sector is unwriteable"
I am not experiencing any problems that I know of with this system. I believe the 0xc0000015 error means NT_STATUS_NONEXISTENT_SECTOR. I tried using a free disk utility which verifies that 1) the primary NTFS boot secor is OK and 2) it can not read the backup NTFS boot sector. I tried to repair it by copying the primary NTFS boot sector but that also failed with a write failure. I tried using windows 7 image backup and restore, but as expected that just restored the problem. The hard drive in question is an OCZ Vertex SSD.
Any thoughts on what I should or can do about this ? I'd like to avoid a full format and Windows 7 install if possible .
If I recall, the second NTFS boot sector is located at the end of a partition, correct? If so, apparently your disk has bad sectors in this area. What would happen if you shrank the partition slightly and then tried another chkdsk repair (chkdsk c: /f)? Would that regenerate the backup copy of the boot sector in the now slightly smaller Windows partition?
If so, I would then try creating a partition in the area that contained the error. Format it and run CHKDSK /R on it to see if the bad sector can be mapped out. Then expand the main partition to full size again.
Interesting suggestion :) . My only question is, if there are bad sectors near the end of the partition, why didnt my CHKDSK /R find them ? Doesnt CHKDSK /R scan all sectors, allocated and free ?? My unenlightened theory at this point is that somehow the system thinks the second NTFS boot sector lives on a sector that doesnt exist. How that might have happened is a long story at this point.
I'm not sure of the specifics of CHKDSK /R. I know that it checks all of the sectors inside of a partition, but I'm not sure of what it does with the few sectors that are used for NTFS housekeeping.
If you have a disk editor, check out your theory by examining the partition table entry to see where it thinks the last sector of the partition is located.
Using Acronis Disk Editor on a different partition with no problems :
View NTFS boot sector
Big total sectors (293042175) + hidden sectors (2048) = 293044223
Scroll to bottom .. last sector 293044223 (NTFS backup) matches above calculation
Now to the bad partition :
View NTFS boot sector
Big total sectors (250059368) + hidden sectors (2048) = 250061416
Scroll to bottom ..last sector ..failed to read 250061423
But sector 250061423 is greater then the calculation for where the backup NTFS should be - 250061416
Looking at sector 250061416 I can see the NTFS backup sector. Somehow the partition doesnt have the correct number of sectors but apparently it did at some point ?? There is a long story about what has happened here. I had a hardware failure on a different drive which has since gone RMA. As part of my recovery attempts, I tried to use Windows 7 image restore on the failed hardware volume and on this volume. All of these image restores failed for various reasons (my favorite useless error message was 0x80070490 element not found). I am faiirly certain that the volume with the CHKDSK second NTFS boot sector problem was OK until all these failed image restores. Eventually I gave up using Windows 7 image restore and recovered my data from the hardware failure using Acronis True Image ! So now I have just this NTFS boot sector issue ..again a different volume from the one that had a hardware failure. I think I may try the suggestion of shrink and reallocate to see what happens.
TMI ..I know
Bottom line ..Windows 7 Image recovery is "limited" (and thats being kind)
I will be a customer soon of Acronis ..was pleasantly surprised that trial software allowed me to restore an entire partition from a Windows image backup (vhd)
It does sound like something got out of "sync" here. Are you checking the entries in the partition's boot sector against the entries in the partition table? They should agree, but from your description it sounds like one of them is off by 7 sectors. I've attached snips from my XP VM showing the first partition on the disk in both views.
To see the partition table you have to select an entire disk. Click either on the disk icon at the bottom of the DD screen, or on a disk in the list. If you select a partition then you'll see nonsense in the partition table view. Make sure that the text at the top of the window starts at sector 0. Your graphic image shows that you are viewing starting at sector 2048.
Compare the two figures (mine and yours) to see what I mean.
More proof that something has changed the partition. I compared the CHKDSK output from a good run on Nov 14 with one that was bad from yesterday:
Bad run Good run
125032447 KB total disk space. 125029684 KB total disk space
31258111 total allocation units on disk 31257421 total allocation units on disk.
4096 bytes in each allocation unit. 4096 bytes in each allocation unit.
I would think that total disk space and allocation units should be the same between runs ? Windows 7 image restore stands accused based on circumstantial evidence !
I think that the partition table entry is the faulty one. The number of sectors entry is shown as (250059376) whereas the value shown in the partition boot record is (250059368). Keep in mind that the two displays differ by 1 since the P-Table starts counting from sector 0 (in other words, the first sector on the disk is called sector 0 instead of sector 1). Therefore, the value for number of sectors should be (250059369).
I think that you can fix this by editing the partition table. Go back to the view as partition table setting in Disk Director and change the value for number of sectors to (250059369), then save the sector. Repeat the test you did in your reply #4 and see if things now line up properly.
I would recommend making this change while booted to the Disk Director boot CD while Windows is shut down. If the change is incorrect, you can go back and restore the current value for number of sectors.
It isn't clear whether Windows 7 Image Restore or Acronis True Image (TI) was the culprit here. Both TI and DD normally will use the older 63-sector offset rules when making partition table entries. TI has recently added some code to allow partitions with 2048-sector offset rules (like yours) to be restored and to maintain the 2048-sector offset. So it could be that your original Windows 7 image restore was guilty of writing an incorrect partition table entry, and TI simply copied the faulty P-Table to the restored image. Or, it could be that TI tried and incorrectly modified the P-Table entry when restoring.
Mark, thanks for the advice. I dont think Acronis software is the culprit. My original problem was a hard disk (Vista boot volume) that went bad, and I couldnt get Windows image restore (either Windows 7 or Vista) to restore the Vista volume. One issue was that some of my Windows image restore sets included both the Vista volume and the Windows 7 volume, and hence my theory that Windows image porked the Windows 7 volume somehow. The bad hardware Vista volume is long gone. The CHKDSK problem with the Windows 7 volume occurred before I installed any Acronis software. I did succesfully restore my Vista volume to another HDD using Acronis TI with the same windows image backups (vhd) that failed with windows image restore . Now I am using Acronis DD to diagnose and perhaps fix the CHKDSK problem with the Windows 7 volume.
Complicated but true :)
Ouch, I have major issues with the DVD bootable media I created.
True Image - Recovery is only showing 1 of 6 partitions on 2 WD Caviar Black drives (1 tb). Its wierd because Backup shows all of them ??
Disk Directory - No mouse. I have a standard Microsoft USB mouse that worked fine with TI. I could navigate somewhat with the keyboard but it wasnt easy. I am not positive but I think some disks were missing again ?
Since I am using downloaded trial versions does that have any bearing on this ?
The TI and DD recovery environments are Linux-based, so your symptom probably means that your hardware isn't completely supported. I wasn't aware that you were using the trial version of Disk Director. The trial is extremely limited in functionality, so it probably will not allow you to edit the partition table.
There is always more than one way to skin a cat. You could download Symantec's free partition table editor, PTEDIT32, from here: ftp://ftp.symantec.com/public/english_us_canada/tools/pq/utilities/PTEDIT32.zip
It's a Windows program, so you can run it directly in Windows 7 (start it using Run as administrator). Be careful to select the correct hard disk before making any changes!
However, being the cautious type, I would not want to do it this way. Instead, do you have another bootable Windows OS on this PC? If so, run it from another Windows version and modify the P-Table on the Windows 7 disk. If something goes wrong then you haven't made the whole PC unbootable, and you can go back and undo the edit.
Yes I have a triple boot : Vista x64,Windows 7 RC1 x64, and Windows 7 Pro x64 . My inclination at this point is to try your earlier suggestion first, ie, shrink the partition by a small amount (say 1Gb) and see what happens ?? Editing the partition table would be a last resort in my view. Also, even if I do this from another partition, the bootmgr and boot folder live on the damaged partition , so there is a possibilty of a disaster. However, I should be prepared, as the boot files used to live on the Vista volume that died and I managed to recover from that.
Thanks for all your help.
Your choice, but modifying the ending sector of a partition should not affect booting. The links in the Vista/Win 7 Boot Configuration Database (BCD) depend only on the Disk ID and the starting sector of each partition.
If you do shrink the partition, use the tool that was used to create it (probably Windows 7 or Vista Disk Management).
Problem solved !
From Windows 7 RC1:
a) shrank Win7Pro partition by 1gb
b) allocated new dummy partition 1gb
c) CHKDSK on both partitions clean
d) delete dummy partition
e) extended original partition back to full size
f) CHKDSK clean
Mark ... thanks for your help. It was interesting to say the least. Left to my own devices, I probably would have formatted and reinstalled Windows 7, and thanks to TI I was able to recover my Vista partition. My only issue with Acronis software at this point is the boot media DVD trial versions of TI and DD do not work on my system. I am sure in the long run that I will become a paying customer. Goodbye to Windows image backup !?!
That's great news. The Acronis boot media problem is solvable. For TI, there may already be a new download of the boot media ISO (this only shows up for customers who have registered the software) with updated Linux hardware support. The same is true for DD. If you are considering purchasing DD I would hold off until version 11 is released (due out next month or maybe January).
Glad to help; I enjoy this type of forensic analysis. Would you mind posting the two Disk Director screen shots of the partition table and the partition boot record after the fix (similar to the screen shots in your reply #8) so that I can see how Disk Management fixed the problem? I'm just curious.
I see that. Now the partition is 6144 sectors smaller, or 3 MB. But the values for the number of sectors are in agreement between the partition table entry and the value in the partition boot record. So at least these are consistent.
This may be normal. Windows Disk Management will usually reserve a small block of unallocated space at the end of a disk just in case you decide in the future to convert a partition to a Dynamic Disk. The reserved space used to be 7.88 MB (one cylinder) when the older 63-sector partitioning rules were in use.