How the DSR System Checks for Partition Changes
After the Dell MBR boots a DSR-DOS partition as drive C:, the autoexec.bat file runs dsrcheck.exe to examine the disk's partition layout. If things are not as it expects, the restore process is aborted.
(Note to self: I haven't yet examined how a WinPE DSR checks for partition changes.)
Autoexec.bat launches the command
"c:\bin\dsrcheck.exe run".
DSRcheck provides principally two functions: to evaluate the state of the computer's
partition layout to determine whether to allow the restore process to proceed,
and to return the partition table (specifically, the partition-type indicators
and active flag) to its normal state. This latter function is necessary
because the Dell-specific method of booting the restore partition
(Ctrl+F11) altered the partition table.
DSRcheck examines the following:
- Current partition table must match a reference copy of the original, else error: "Partition change detected".
- Sector with reference partition table must end in '55 AA', else error: "Data needed for restoring has been corrupted".
- PBR 1 must be FAT16, else error: "Partition change detected".
- PBR 1 label must be "DellUtility", else error: "Partition change detected".
- PBR 2 must be NTFS.
- PBR 3 must be the active partition, else error: "Dell Restore partition was not found".
(Note to reader: remember that Ctrl+F11
made the 'DB' partition the active partition.)
- PBR 3 must be FAT32X, else error: "Dell Restore partition was not found".
- PBR 3 label must be "DellRestore", else error: "Dell Restore partition was not found".
The two label checks are on the name in the partition's boot sector, not the label in the partition's root directory. The check is case-sensitive.
(Note to reader: most people may not realize there are actually two places a partition
name can be stored. It's not easy to set lowercase characters here,
as the DOS command, 'LABEL', always converts input to uppercase.)
The reference copy of the partition table is stored in Sector 18 (decimal) of
the Restore partition, at offset 01BE-01FDh. This is a duplicate of the original
partition table at offset 01BE-01FDh in the disk's master boot sector.
DSRcheck first checks that the sector containing the reference partition table ends in '55 AA'. If not, DSRcheck aborts, leaving the real partition table with the descriptor types and active flag in a mess--these were altered by the Ctrl+F11 sequence, and are not cleaned up when DSRcheck aborts.
If the sector with the reference partition table ends in '55 AA', DSRcheck changes the descriptor types in the real partition table to DE/07/DB, and proceeds to compare the partition table to the reference partition table. DSRcheck resets the active partition indicator based on which partition is marked active in the reference partition table.
Warning: it appears this reference sector includes boot code besides the partition table and the usual '55 AA' bytes at the end of the sector. However, the alternate MBR boot code is different from the real MBR boot code, so should not be used. Nonetheless, DSRcheck compares only the partition table (and the trailing '55 AA'). It does not check any other part of this reference sector such as the MBR or DiskID sections, and those parts of the reference sector can actually even be blank.
(Note to self: I haven't yet figured out what the boot code in this
sector is for. Perhaps it is an artifact leftover from the system build process.)
Ctrl+F11 works as long as the partition is marked type
'DB' and is not already the active partition. That's enough for the
Dell MBR to boot the partition. DSRcheck, however, is pickier.
As seen above, DSRcheck imposes additional restrictions in order to let the restore
process proceed. For example, if you have repartitioned the hard disk, the
Dell MBR may still be intact and Ctrl+F11 will boot the
DSR partition, but the partition table will no longer match the reference partition
table so DSRcheck will not allow the restore process to continue.
