- Geometry emulation - switched to using volume boot sector values, when such values exist.
- LBA -> CHS calculation errors fixed.
Cylinder was not correctly calculated and bits 9 and 10 of cylinder were not placed correctly in MBR partition entry.
When a disk image file is mounted, the boot parameter block is now read from the volume boot record. If geometry values are found there, they are reported as disk geometry to Windows. This causes disk geometry queries made by applications and other drivers to report the same geometry values as were found originally in the VBR when image file was mounted. This also causes reformatting of the volume to not overwrite this geometry with other geometry values and similar.
The change can be seen with my devioctl tool (latest versions). "Disk CHS geometry" and "LBA length" are values reported by Windows. They of course depend on what the disk driver, in this case ImDisk, has originally reported when the disk device was created. "Partition information" is what Windows thinks about the "partition", also depends on what ImDisk reports. "Volume boot record values" are values read from BIOS parameter block in volume boot record.
Before this change:
C:>devioctl geometry E: Disk CHS geometry: Media type : 12 Cylinders : 83 Tracks per cyl: 32 Sectors per tr: 63 Bytes per sect: 512 Total CHS size: 85671936 (81.7 MB) LBA length : 86030336 (82.04 MB) Partition information: Start offset : 32256 Partition size: 86030336 (82.04 MB) Hidden sectors: 1 Partition no : 1 Partition type: 0x06 Boot indicator: 0 Recognized par: 0 Volume boot record values: OEM name : NTFS Bytes per sect: 512 Sectors per cl: 1 Reserved sect : 0 FAT count : 0 FAT root entr : 0 Total sectors : 0 Media descript: 0xF8 Sectors pr FAT: 0 Sect per track: 17 Number of head: 15 Physicl drv no: 0 E:: The operation completed successfully.
After this change:
C:>devioctl geometry E: Disk CHS geometry: Media type : 12 Cylinders : 658 Tracks per cyl: 15 Sectors per tr: 17 Bytes per sect: 512 Total CHS size: 85908480 (81.93 MB) LBA length : 86030336 (82.04 MB) Partition information: Start offset : 8704 Partition size: 86030336 (82.04 MB) Hidden sectors: 1 Partition no : 1 Partition type: 0x06 Boot indicator: 0 Recognized par: 0 Volume boot record values: OEM name : NTFS Bytes per sect: 512 Sectors per cl: 1 Reserved sect : 0 FAT count : 0 FAT root entr : 0 Total sectors : 0 Media descript: 0xF8 Sectors pr FAT: 0 Sect per track: 17 Number of head: 15 Physicl drv no: 0 E:: The operation completed successfully.
So, this makes the BPB and Windows "running values" agree. This also means that the function that saves a volume as an image file prefixed with an MBR, can use the same way to identify disk geometry for both ImDisk volumes and physical disk volumes (and volumes created by other virtual disk drivers).
Now, this seems to work correctly for filesystems with a BPB in the volume boot record and as long as the values there are "sane". This is usually the case for FAT12, FAT16, FAT32, NTFS, HPFS. It does not work at all with exFAT, HFS+ etc as far as I can see. There is something like BPB values in EXT2/EXT3 and UFS boot records, but I cannot really understand what their values come from. For example, I have a 10,000 MB VHD file with C/H/S geometry 20317/16/63 where FreeBSD is installed. In the volume boot record of the boot partition, FreeBSD has Sectors/Head = 18 and Number of Heads = 2...
There is also of course the possibility that ImDisk will mistakenly treat something as a BPB geometry that is not meant to be something like that, just happens to be stored at the same location in a filesystem format that uses that byte position for something else. For now, it just checks that the bytes per sector is a power of two and that heads and cylinders are not unreasonably high.
Anyway. This should not be worse than it was before. The only problem is that if, for example, a FAT32 volume is mounted with geometry from BPB and the volume is reformatted as exFAT, the geometry values will not "survive" a dismount/remount. Because the next time the volume is mounted there are no BPB geometry values for ImDisk to read, since exFAT has no BPB. If that image is then saved as an image file with MBR prefix, it will be placed in a very different place in the image than it was possibly originally loaded from.
Further changes in this release:
- Partition auto-detection works with partition entries that start at LBA=0.
Previously, such entries were treated as "not used" and simply skipped. Corresponding change has also been made to devio (with variants). There were a discussion about this bug here: http://reboot.pro/17715/
- Support for sparse image files.
A new command line option -o sparse causes ImDisk to create a sparse image file. This effectively sets sparse flag using FSCTL_SET_SPARSE, it causes image file size not to be increased to virtual disk automatically and it causes the image write routines to call FSCTL_SET_ZERO_DATA when an all-zero block is written to image.
- ExAllocatePoolWithTag instead of ExAllocatePool.
This means that poolmon.exe and other kernel memory monitoring, verifying and leak detecting tools that work on running drivers will work more like expected with ImDisk. Pool tag for imdisk.sys is now "ImDi" and for Awealloc it has been changed to "AWEA". The 64 bit versions now free pool memory using ExFreePoolWithTag instead of ExFreePool. This causes a BAD_POOL_CALLER blue screen in case something goes entirely wrong and the driver tries to free the wrong memory block. The 32 bit version is still left without this check, to be compatible with NT 4.0 and earlier.