mithriltabby: Mushroom cloud (Nuke)
[personal profile] mithriltabby
Microsoft created the notion of a “file system filter driver” for Windows. Normal device drivers are how the operating system talks to devices, such as your hard drive. Filter drivers let you create a device that attaches to a real device and serves as the gateway through which requests go into the real device. They can spy on requests, invalidate requests, rewrite them, or even respond to them without letting the request touch the underlying device at all. The technology is very handy if you need to write, say, a virus scanner.

In Windows 2000, they left some holes in their support for intercepting several kinds of requests, and on that platform you need to do ugly things like hacking the underlying driver’s fast I/O locking callbacks or meddling with the undocumented KeServiceDescriptorTable in the kernel. This happened often enough that they added calls in Windows XP that let you avoid having to do this: CmRegisterCallback() so people don’t need to meddle with the code that talks to the Registry, and FsRtlRegisterFileSystemFilterCallbacks() so people don’t wind up messing with the locking callbacks.

These new callbacks do not work as filters where you receive the request and do whatever you want with it. (I suspect Microsoft have annual public floggings for the person who creates the most consistent extension to an API in the past year, and their engineers are desperate to avoid this. It’s the only way I can explain their ACL code.) You can get called before the actual operation on the underlying device and after the operation. The documentation states that if you return an error code, you can prevent the request from going down to the filtered device, and that if you return success, the operation will proceed. But the documentation doesn’t say anything about what to do if you want to handle the request yourself and not send it to the filtered device.

Since Microsoft can’t be bothered to write good documentation or expose their source code to driver writers to figure things out for themselves, I had to step through the code at the assembly language level to figure out what was going on. And sure enough, there was a magic code, 0x126, which turned out to be the completely and thoroughly undocumented STATUS_FSFILTER_OP_COMPLETED_SUCCESSFULLY, which only shows up IFS kit header files for Windows Server 2003 (though a thoroughly updated Windows XP does know to check for it). It does not appear in MSDN, does not appear in the IFS kit documentation, and only shows up on Google as part of some header files that happened to get indexed. The comment in the header file is: “A file system or file system filter driver has successfully completed an FsFilter operation.”

It turns out that yes, this is the missing piece of the puzzle. Returning it will avoid the call into the underlying driver. Leaving this bit of information out of the documentation, though, cripples the API as surely as any bit of bad code would.

This is the kind of thing you need to do on Windows to solve Blue Screen of Death level problems. This is one of many reasons why I loathe working with Windows drivers.

Date: 2005-02-18 07:45 am (UTC)
From: [identity profile] zevblue.livejournal.com
(this is from Roger) Didn't Microsoft lose a big lawsuit about exactly thi sort of thing, a few years back, in which they promised to document all their undocumented features? Perhaps you should send this to the Department of Justice... :-)

Date: 2005-02-18 05:05 pm (UTC)
From: [identity profile] racerxmachina.livejournal.com
Next time there's a Microsoft informational meeting on campus (bring your resume, win an Xbox), I'm inviting you to provide counterpoint.

Date: 2005-02-18 08:38 pm (UTC)
From: [identity profile] racerxmachina.livejournal.com
Jeezus, you mean someone HAS to wear The Bitch Hat in a team? Way to foster morale.

October 2025

S M T W T F S
   1234
5678 91011
12131415161718
19202122232425
262728293031 

Most Popular Tags

Style Credit

  • Style: Midnight for Heads Up by momijizuakmori

Expand Cut Tags

No cut tags
Page generated Jan. 26th, 2026 10:33 pm
Powered by Dreamwidth Studios