Pierre Schweitzer’s Blog

FsRtl, understand Filesystem Runtime library, is a part of ntoskrnl (Windows and ReactOS kernel). It provides a set of advanced functions for FSD, FileSystem Drivers, to interact easily with system. For example, most used function by FSD writers must the FsRtlNotify* functions. Those ones, called by the driver, notify kernel (and then user) that a change occurs on volume. It can be change on files (added, deleted, modified, etc.) or a change on volume status (locked, dismounted, etc.). As you can see, those functions aren’t “essentials”; a FSD can be written without them, it will just lack some features.

That’s why they weren’t a priority in ReactOS development, so most of them aren’t implemented, and producing BSOD, Blue Screen Of Death. Indeed, in kernel, in order to preserve system integrity, when a call to an unimplemented functions is done, it produces a BSOD. For example, FsRtlNotifyInitializeSync is written that way in kernel:

VOID
NTAPI
FsRtlNotifyInitializeSync(IN PNOTIFY_SYNC *NotifySync)
{
    KEBUGCHECK(0);
}

It’s KEBUGCHECK macro that produces the BSOD (taking is name from KeBugCheck function). But why have been those functions ignored? First of all, because of their non-vital state, but also because of their lack of documentation. When a function is documented, and all its components released it’s easier, reading MSDN to find an implementation. But FsRtl was really badly documented (and even if efforts have been done, it’s still not enough). Moreover, FsRtl functions are often using parameters that Microsoft calls “opaque” pointers. Concrete, those are pointers to internal structures. Kernel deals with them and FSD are just keeping their pointers to call functions later. So, we point to unknown elements. When writing FSD that’s not a problem, and even more that can be an advantage: kernel do everything. But, for implementation, it becomes a real problem because those internal structures (such as NOTIFY_SYNC) aren’t documented. Some of the undocumented structures can be found with WinDbg, but FsRtl ones can’t be. Only remains one solution: reverse engineering. That way, we can find how ntoskrnl work with those structures, and we can try finding what for are the field designed.

For now, on my FsRtl work, no internal structure has been added. I’ve to become a bit better . Anyway, using the above described methods, I managed to implement, in my branch pierre-fsd, many FsRtl functions, this makes kernel a bit more closer to Windows one. Indeed, I’m pretty proud to say that all Dbcs and Name functions have been implemented and working! But new problems are coming… Last function I implemented is FsRtlNotifyVolumeEvent. And it calls (as Windows one) a Io, Input/Output, function from kernel: IoReportTargetDeviceChangeAsynchronous. And this functions isn’t implemented! BSOD has just been moved…

So adventure has to be continued