This project is read-only.

Whats about the NTLDR Section after the boot sector in a logical volume?

Jan 26, 2010 at 8:56 AM


Windows OSs have a so called NTLDR Section after the normal boot sector of a logical volume. This section is for XP 6 sectors long and for Vista (and Win7 AFAIK) 8 Sectors long.
XP is no problem, but the vista NTLDR section is always overwritten by vista when it boots ... is there any offset or so which I need to adjust, so Vista doesn't kill it's own NTLDR section?

Any knowledge in this area?

Ciao Ephraim

Jan 26, 2010 at 9:00 AM
Edited Jan 26, 2010 at 9:01 AM

I've the informations about this from:


The eight  physical sectors directly following a Windows™ Vista  NTFS Boot Sector, contain code which can interface with both the older NTLDR file (in order to boot up Windows™ NT, 2000, XP, 2003 OS partitions) plus code to interact with the new BOOTMGR (boot manager) program introduced with the Vista OS. This code is still necessary when booting up a Windows™ OS (even though the bootmgr  or NTLDR files  may not exist in the OS partition you start booting up from; as would be the case if, for example, you installed Windows™ Vista on a disk already containing a bootable Win 98 OS in the first partition followed by Vista's partition).

Jan 26, 2010 at 9:43 AM

Can it be, that the numBootClusters in the NTFS Formatter has to do with this part?

int numBootClusters = (BootCode == null ? 2 : Utilities.Ceil(BootCode.Length, _clusterSize));  // BootCode.Length = 512, _clusterSize = 4096 => BootCode 1 Sector and clusterSize 8 Sector

so numBootClusters are 8 sectors which is less then I need, VBR + NTLDR section are 9 sectors? (the last sector of NTLDR section is killed, and not only when Vista boots as I found out currently).


I'm currently trying it with

int numBootClusters = (BootCode == null ? 2 : Utilities.Ceil(BootCode.Length, 8192));

So the numBootClusters will be 16 Sectors big.


Ciao Ephraim

Jan 26, 2010 at 10:48 AM

Sad, it wasn't that :(

Jan 26, 2010 at 11:48 AM

It depends somehow on the amount of data I copy into the vhd.... when I just create the disk and format the partition, all is fine ...
But when I copy data into the partition, then the 9th sector of the disc is overwritten with 0xFF overall.

Any ideas?

Ciao Ephraim


Jan 26, 2010 at 10:44 PM

Hi Ephraim,

Large quantities of 0xFF typically indicates that one of the 'bitmap' attributes/files in NTFS has stomped on that sector.

Chkdsk can probably help here.  Try running it after you've created and formatted the partition, and again after you've copied a few files in, and again once you've copied all files in.  Hopefully it can indicate what's wrong with the file system.  Don't use the /f option to repair the file system.

If it flags a particular file, or record segment at fault, the output of ntfsdump run on the partition might be useful to help narrow things down.  It generates a lot of output, so normally best to pipe it into a file:

ntfsdump foo.vhd > dump.txt





Jan 27, 2010 at 1:04 PM

Thx for the hint .... I will try that.

Ciao Ephraim

Jan 29, 2010 at 10:13 AM

Hey Ken,

I used chkdsk and NTFSDump, but I'm not sure how to use the results. chkdsk reports about ~20 wrong index entries and NTFSDump dumps about 240 MB and then dies with the following exception:

F:\Tools\DiscUtils>NTFSDump.exe -H -S -M d:\virtualDisk.vhd > ntfsdump.txt

Unbehandelte Ausnahme: System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
   bei DiscUtils.Ntfs.NtfsFileSystem.DumpDirectory(Directory dir, TextWriter writer, String indent)
   bei DiscUtils.Ntfs.NtfsFileSystem.DumpDirectory(Directory dir, TextWriter writer, String indent)
   bei DiscUtils.Ntfs.NtfsFileSystem.DumpDirectory(Directory dir, TextWriter writer, String indent)
   bei DiscUtils.Ntfs.NtfsFileSystem.DumpDirectory(Directory dir, TextWriter writer, String indent)
   bei DiscUtils.Ntfs.NtfsFileSystem.Dump(TextWriter writer, String linePrefix)
   bei NTFSDump.Program.DoRun()
   bei DiscUtils.Common.ProgramBase.Run(String[] args)
   bei NTFSDump.Program.Main(String[] args)

I just create a disk, partition and formating it and the copy some files into it. What am I doing wrong to cause this?

Ciao Ephraim

Jan 29, 2010 at 10:34 AM

and chkdsk finds a failure in the attribute BITMAP of the masterfiletable and free space which is marked as associated in the volumebitmap.

Whatever this means :).

Any ideas?

Jan 30, 2010 at 11:56 AM

Sounds like the corruption is happening after a number of files have been added to the disk.

I've just finished some fairly large changes inside the NTFS logic, and uploaded them - if you could try using the latest code from the repository, that would be really helpful.  I'm not sure if it will have fixed this, but if we're looking at the same code, might help narrow down the problem.

If you could zip up the output NTFSDump (as much of it as you got), I can take a look at that to see if I can spot the bug in DiscUtils from that.

Can you explain roughly what's being done here - is it essentially populating a disk with a large number of files?

If so, is the disk much bigger than the contents you're adding, or is the disk getting quite full?

I'm trying to get a feel for which part of the NTFS implementation might be broken.




Feb 1, 2010 at 1:28 PM

Hey Ken,

I just tried it with the latest changeset of discutils and is still the same behave.

The created disk is about 25GB big and the data copied into the disc is about 15GB so not that filled up.
I'm not sure when the sector is overwritten, but when I stop it during the copy of the files, the sector wasn't wasted.
So I think it can somehow depend on the size of data or the count of files copied into the vhd, but thats just a guess and I haven't proofen it.

In my case, there are about 60K files and 35.5K directoires copied into the vhd.
I'll pm you with the dump file I get... I just create one with the latest code.
The last was about 200MB as NTFSDump died.

So now chkdsk finds no indexing problems but still complains about the BITMAP thing ...
And ntfsdump doesn't die! :)

Any further questions? (PM is in construction)

Ciao Ephraim

Feb 5, 2010 at 8:21 AM

Hey Ken,

one difference which I have is, that I use different MBRs and VBRs. In the good case, the MBR and VBR are from XP formated disks. In the bad cases the MBR and VBR are either from Vista or Seven.
And in the good case the vhd is created in XP Environment. In the bad cases it is created in Vista or Seven Envrionment. Could this matter?

Ciao Ephraim


Feb 5, 2010 at 3:07 PM

It's me again :).

Some tests results.

I created a util which creates a vhd and fills it with as many files as I want to fill the vhd with.
And inserts a VBR from a Win7 as bootCode to the NTFSFileSystem.Format function.

Without the bootCode and 65540 files, chkdsk can't find any failure.
With the bootCode and 32770 files, chkdsk can't find any failure.
With the bootCode and 65540 files, chkdsk FINDS a failure in the BITMAP-attribute of the MFT.

So far so good. But here I stuck, cause I have no knowledge about the MFT stuff, yet :).

You should have a PM with a link where you can download the testapp.
The used numbers where in the test beginning the limits of an int but afai can see now, it has nothing to do with such limits and
so the numbers are taken randomly.

Hopefully it helps tracking down the problem. The BPB of the VBR looks equal in all three cases (except of the volume signature of course).

Any ideas what I can test or do further?

Ciao Ephraim

Feb 5, 2010 at 9:20 PM

Hi Ephraim,

Thanks for the test code - unfortunately, I've tried it with these values, and it worked OK for me:

With the bootCode and 65540 files

Chkdsk on Win7 indicated there were no problems.

Something very strange going on here - can you reproduce the failure with those inputs?



Feb 6, 2010 at 2:55 PM

I've also checked in a change that forces the $Boot file to at least 8KB when formatting with NTFS - hopefully that will negate any differences seen between the OS's.



Feb 15, 2010 at 8:55 AM

Hey Ken,

thx for your help. I think the $Boot 8KB checkin did the trick. At least, I can't reproduce the problem since using the latest changeset and the error was easily to reproduce before.
So IMHO the status is fixed.

Ciao Ephraim