“The parameter is incorrect”: an update
I believe I’m zeroing in on the cause of the bug.
A comment in a mirror of a 1997 Sysinternals post, “Inside Windows NT Disk Defragmenting” says this about FSCTL_GET_VOLUME_BITMAP:
Return
If there are errors related to the volume’s support for this FSCTL or FileHandle representing a valid volume handle, an appropriate native NT error code is returned (as defined in the NT DDK file NTSTATUS.H). If the cluster specified in InputBuffer is out of range for the volume, the call will return STATUS_INVALID_PARAMETER. If there are no errors and there are no clusters beyond the last one described in the Map array, the FSCTL returns STATUS_SUCCESS. Otherwise STATUS_BUFFER_OVERFLOW is returned to notify the caller that further calls should be made to retrieve subsequent mappings.
…which is far more enlightening for this matter than Microsoft’s current documentation for FSCTL_GET_VOLUME_BITMAP:
Remarks
The FSCTL_GET_VOLUME_BITMAP control code retrieves a data structure that describes the allocation state of each cluster in the file system from the requested starting LCN to the last cluster on the volume. The bitmap uses one bit to represent each cluster:
- The value 1 indicates that the cluster is allocated (in use).
- The value 0 indicates that the cluster is not allocated (free).
Note that the bitmap represents a point in time, and can be incorrect as soon as it has been read if the volume has write activity. Thus, it is possible to attempt to move a cluster onto an allocated cluster in spite of a recent bitmap indicating that the cluster is unallocated. Programs using the DeviceIoControl function with the FSCTL_MOVE_FILE control code must be prepared for this possibility.
The handle used here must be a Volume handle and have been opened with any access. Note that only Administrators can open Volume handles.
The starting LCN in the input buffer may be rounded down before the bitmap is calculated. The rounding limit is file system dependent.
What exactly does Microsoft mean by “[…]the input buffer may be rounded down before the bitmap is calculated”?!!? I believe that that, together with the Sysinternals post, points to a bug in FSCTL_GET_VOLUME_BITMAP’s return behavior, or in defragsvc’s usage thereof.
To aid in debugging, I’m uploading a zip file with:
- A Process Monitor trace of a defrag run wherein defrag throws the ”The parameter is incorrect. (0×80070057)” error.
- A dump of defrag.exe immediately after the error is thrown.
- A dump of svchost.exe -defragsvc immediately after the error is thrown.
- (hopefully informative set of) Screenshots of a WinDbg session immediately before, during, and after the error is thrown.
- The symbols that I set breakpoints for in WinDbg.
- Some remarks on FSCTL_GET_VOLUME_BITMAP collected from a few sources on the internet.
- A few notes on the debugging process.
A note about the Process Monitor trace: I have removed a (very) few entries that contained personal information, entries that I’m quite certain have no relevance to the error.
Now it’s up to Microsoft to fix the issue.
Alexander Riccio 