Partition resize causes lock-up during boot sequence
- From: "TJ" <google@xxxxxxxxxxx>
- Date: 6 Jan 2007 15:55:12 -0800
I've spent the last week trying to debug what has to be the weirdest
issue I've ever come across on Windows 2003 Server SP2 Enterprise with
Active Directory.
In Brief:
Needed to create additional partitions on the boot disk, so shrank the
NTFS file-system in partition 2 from ~90GB down to ~40GB, then adjusted
the partition table entry to reflect the reduced size.
When starting Windows normally it hangs (freezes - no further response
until hard reset) during the boot process, just after it has finished
checking the disks (when using the '/bootlog /sos' boot options). When
booting in Safe Mode the boot is completely successful.
If the partition table entry is reset to its original value (by
altering just 4 bytes), Windows will boot normally.
After reading the detail below, I hope you can suggest some further
diagnostic strategies, tools, or ideas as to what I'm dealing with
here.
TJ.
----
Detail:
RAID 1+0 (Mirror + Stripe) 120GB logical volume on 4x 60GB IDE drives
on a Promise FastTrak TX2000 controller, using signed drivers
v2.00.0.34. The RAID volume has 2 primary partitions, 1=24GB (C:)
containing operating system, 2=90GB (D:) containing data.
After painstaking exploration it seems that *something* in the boot
sequence causes the system to hang during a normal start-up if the
partition table has been adjusted to reflect the reduced size of the
NTFS file-system contained within it.
To be clear, Windows in Safe Mode will boot, reports no problems when
CHKDSK is run on either partition, and Disk Manager shows both
partitions as healthy and the ~50GB of unallocated space.
All attempts to start Windows normally end with it locking up
immediately after the autocheck reports all volumes clean.
As soon as the partition table's 2nd entry is edited to report the
original size (~90GB) by altering the LBA "last sector" value, Windows
will start-up successfully.
I tried several partition-size values, including:
a) exact size of the shrunken NTFS file-system
b) aligned on the next track boundary
c) aligned on the next cylinder boundary
The drive reports 63 sectors x 255 heads geometry.
In case it was some unusual side-effect of the resize, from Safe Mode I
used DISKPART to expand the 2nd partition (from 40GB) by 1GB (EXTEND
size=1000) to 41GB so that, even if somehow the partition table and
file-system were in conflict, Windows would write values it was happy
with into the partition table and expand the NTFS file-system contained
within it.
This didn't solve the issue, Windows would continue to lock-up during a
normal start-up, but starts fine in Safe Mode. As soon as the partition
table was returned to its original size (~90GB) Windows would again
start-up successfully.
I've tried to use boot-logging (C:\Windows\ntbtlog.txt) to work out
which driver is causing the problem, but there is rarely a boot-log
when the problem occurs.
I've tried using the SysInternals "autoruns.exe" tool to selectively
disable 3rd party drivers from the boot process but so far I've only
succeeded in loosing all keyboard, mouse, and network access!
I tried running RegMon.exe in "boot logging" mode but again, that was
unsuccessful mostly due to the sheer volume of data recorded (> 29MB)
and the effects regmon logging seemed to have on the boot process
itself.
Ideally what I need is a non-invasive boot logger reporting to the
screen during start-up (or to a debugger on COM ports) in order to
identify which driver Windows is attempting to load at the point it
locks up.
I have a couple of theories about whats happening, but no evidence:
1) Some driver is using a stored file-system or partition size to
locate
data on the disk, instead of using the dynamic size reports read from
the
disk.
2) Some form of 'protection' system has been installed by a 3rd party
application that has stored data in the 'spare' sectors between the end
of the file system and the end of the partition, and is using the
partition size as the key to locating that data.
The 'working' partition table looks like this:
1: start=63, end=49258899, id=7 (NTFS)
2: start=49158900, end=238276079, id=7 (NTFS)
A typical 'non-working' partition table looks like this:
1: start=63, end=49258899, id=7 (NTFS)
2: start=49158900, end=166346388, id=7 (NTFS)
In both cases the NTFS file-system has the same size (it isn't being
resized from its ~40GB size) and to re-iterate, Windows has no problems
with the file-system at all and reports it clean and healthy.
Follow-up:
I wondered if somehow the values being written to the partition table
entry were too small, so as a trial I took the original partition size
and reduced it by ONE SECTOR ONLY, and it still causes Windows to
lock-up during a normal start-up, whilst a Safe Mode start-up is
successful.
In Safe Mode it shows the file-system is ~41GB whilst the partition is
~90GB - chkdsk reports no problems.
.
- Follow-Ups:
- Prev by Date: Re: Volume Shadow Copy x SQL instance
- Next by Date: Re: Partition resize causes lock-up during boot sequence
- Previous by thread: Folder view settings on a thumb drive
- Next by thread: Re: Partition resize causes lock-up during boot sequence
- Index(es):
Relevant Pages
|
|
