Windows NT layered IO drivers were a PitA. Because those higher in the stack would have to deal with whatever alterations those lower had made to the IO stream,

Windows NT layered IO drivers were a PitA. Because those higher in the stack would have to deal with whatever alterations those lower had made to the IO stream, device driver writers would try to force their driver to load as low as possible to avoid writing all the code to handle it. File system filter drivers were where the chaos this caused manifested. If there was just one loaded, you might not see any problems (though the anti-virus guys could be relied on to find a way...). But once you had a few (AV, file system quotas, backup etc.) all sorts of horrible things would start happening. People always complained about blue screens but experience taught us to love and cherish them as it meant the damage a filter driver had done had actually been caught rather than it silently doing horrible things to files. The other nice thing about the BSODs was that you could always pinpoint the driver that had pooped its pants by analyzing the dump file. In the NT4 days, manipulating the load order was a simple registry entry for the driver. We put a lot of time and effort into finagling them to figure out which were the worst offenders. In the end, we just figured out which combinations of filters were worst and quit using them. Windows 2000 (I think) fixed this by removing the ability of drivers to manipulate the load order. That forced the driver writers to up their game a bit and write the code necessary to deal with whatever something lower in the stack had done.