Introduction
Have you ever wondered how exactly NT's two file system management utilities, chkdsk and format, work? Maybe you've had an application that would have been perfect if you could have incorporated chkdsk or format functionality into it. On this page I present Chkdskx and Formatx, two utilities that very precisely clone the command-line chkdsk and format utilities that come with NT. In fact, the clones support the same switches as the standard chkdsk and format and produce almost exactly the same output. So while they don't do anything special, their source code demonstrates how you can write your own interfaces to chkdsk and format functionality.Chkdskx and Formatx work on NT 4.0.
FMIFS
Chkdskx and Formatx don't have to know anything about on-disk file system
layouts to their jobs because they are clients of a system utility library
that worries about this for them. The library is FMIFS.DLL (Format Manager
for Installable File Systems is my guess at what the name represents) and
it is located in the Winnt\System32 directory. It exports a handful of functions
including Chkdsk, ChkdskEx, Format and FormatEx. When you select Format
from Explorer's volume context menu (the one you get when you right-click
on a drive icon), Explorer uses FormatEx to format the drive, and when you
request a disk consistency check on the Tools tab of a drive's properties
dialog Explorer calls out to Chkdsk. Actually, Explorer uses a yet higher-level
function, SHFormatDrive, in SHELL32.DLL to access FormatEx, and Chkdsk gets
called as a result of Explorer's use of Shell32's internal function, CDrive_Properties.
CDrive_Properties creates the drive properties dialog box and pressing the "Check Now" button results in a chkdsk dialog that is created by Shell32's DiskToolsCommand. SHFormatDrive and ChkdskDlgProc are what actually present
the options and progress dialog boxes that are presented in response to
either request.
TheFormatEx function in FMIFS.DLL is prototyped like this:
VOID FormatEx ( PWCHAR DriveRoot ,
DWORD MediaFlag ,
PWCHAR Format,
PWCHAR Label,
BOOL QuickFormat ,
DWORD ClusterSize ,
PFMIFSCALLBACK Callback);
where the FMIFSCALLBACK is:
typedef BOOLEAN (__stdcall *PFMIFSCALLBACK)(
CALLBACKCOMMAND Command,The callback function takes three arguments, interpreting the first one as a command argument that indicates what FormatEx is trying to communicate. I've made the command an enumerated type and filled in the table of roughly 16 commands with the ones that are used during typical FormatEx and Chkdsk operation. For example, one command is OUTPUT, which a callback function can respond to by intepreting the third parameter (ActionInfo) as a pointer to string and displaying the string on the screen. Another command type is a PROGRESS command. The ActionInfo parameter is a pointer to a DWORD that the callback interprets as a precentage. Thus, in a long format process the FMIFS client can keep the user informed of progress via a progress dialog or text print-outs.
DWORD SubAction,
PVOID ActionInfo );
The Chkdsk command's definition follows a similar convention:
VOID Chkdsk( PWCHAR DriveRoot,
PWCHAR Format,Chkdsk's arguments are also self-explanatory and you can see that the exact same callback definition is used for Chkdsk.
BOOL CorrectErrors,
BOOL Verbose,
BOOL CheckOnlyIfDirty,
BOOL ScanDrive,
PVOID Unused2,
PVOID Unused3,
PFMIFSCALLBACK Callback );
You might think at this point that FMIFS is where the file system on-disk structure knowledge is located. However, FMIFS is itself a client of other libraries that contain knowledge about specific file system formats. For example, UFAT.DLL is the library that actually "knows" about FAT on-disk layout so it can perform FAT formatting or consistency checking operations. UNTFS.DLL is where NTFS information is located. You'll note that both the Chkdsk and FormatEx FMIFS functions take file system type string parameters. FMIFS simply takes the file system string and creates a DLL name by placing a 'U' in front of it and a '.DLL' at the end: U
This hierarchical arrangment makes it easy for Microsoft to add new file system types to the system without having to write custom verions of the file system management tools. They simply write a DLL for the new file system type and make the management tools (like Explorer) aware of the new format name.
Chkdskx and Formatx
Chkdskx and Formatx demonstrate the use of the functions in FMIFS I've described. I've made them behave almost exactly like the real command-line chkdsk and format. Interestingly, only Explorer uses the FMIFS functions, and then only indirectly through SHFormatDisk. The command-line chkdsk and format programs bypass FMIFS convenience functions and interface directly with UFAT.DLL and UNTFS.DLL The utility libraries are where most of the text output you see when you run the commands is generated, so the output of my Chkdskx and Formatx is very similar to the real chkdsk and format's output.Download Chkdskx and Formatx plus Source Code (54KB)