Problems with STATUS_REPARSE with WebDav redirector on Windows 7

NTFSD
1

We’ve been having troubles in our FS filter driver redirecting I/O through the webdav redirector on Windows 7. I can also duplicate this problem (or something that appears to be the same problem) with our filter driver entirely out of the picture by creating file symlinks that have http/webdav URIs as the target of the symlink.

One interesting thing is that accessing the same file(s) thru WebDav with a normal mapped (i.e. Z:) drive always seems to work. It’s only in the case of STATUS_REPARSE style redirection (that our filter driver uses and I’m thinking symlinks also use) that we see this problem. I’ve also been able to duplicate the problem accessing a variety of WebDav servers (both local servers and “cloud” based).

The outwardly visible result of the problem is that while browsing files (right-click or try to open) in Explorer, while it often works, sometimes Explorer will become unresponsive like it’s waiting for some response or something. Problem is that Explorer will never come out of this state and essentially becomes “hung” and the only way to fully recover is to hard-reboot the box.

Examining LAN traces of the problem when it occurs it just appears that the webdav client/redirector has become unresponsive and stops sending requests to the webdav server.

Tracing I/O flow in our filter driver we see a couple things: In our PreCreate code path we make a call to FltCreate using the remote http/webdav path to check so see the file exists on the remote webdav server. Often when we see the Explorer hang it appears that we have made this call FltCreate and it never returns. Other times it appears the hang occurs after we have returned STATUS_REPARSE in our PreCreate to hand the I/O off to the Webdav redirector. At any rate in both cases it appears that WebDav redirector or one of the other components in the I/O chain (MUP/FltMgr) are spinning in an endless loop or gone brain-dead in some way.

Since we’ve been able to duplicate the problem without our filter with symlinks using only pure Microsoft components, we earlier opened an incident with MS support. After duplicating the problem and tinkering with a few WebDav settings, loading a few patches, etc. all to no avail, the basic word we got from Microsoft was that WebDav was just sort of finicky in general and that the behavior we were seeing with Explorer was “working as designed”. They recommended we move away from relying on WebDav and do something different (like use mapped drives or write our own http/REST redirector or use stubs/HSM-style methods in combo with our own REST calls to always copy files local before allowing user access).

So most likely if we can’t find a resolution to the problem we’ll end up following Microsoft’s suggestion, but before we commit to that route I thought it would be a good idea to first try this forum to see if anyone has any ideas/suggestions how we might find out more about the issue and possibly work around it.

We’re currently tinkering with the various timeout and other settings in the Registry related to the Webdav service & redirector, but so far nothing has helped much.

Any help/suggestions would be greatly appreciated. Thanks.

2

Any chance you could post some of the stacks you’re seeing ?

It might also be useful to describe what your filter is doing.

Also, as always, when things just stop working in the create path it might be worth looking at whether oplocks have a role to play. For example, when you issue your FltCreate to check for the presence of the file do you set the FILE_COMPLETE_IF_OPLOCKED ? does it make a difference ? Procmon might also be helpful there…

Thanks,
Alex.

3

Thanks for the feedback and suggestions Alex. We tried playing with FILE_COMPLETE_IF_OPLOCKED but it didn’t help. But it does appear that by tweaking various Webdav Registry timeout parameters we can make the problem go away.

The short version of what our filter does:

For all I/O to a certain directory we want to redirect to a webdav server so that we get the same basic affect as a mapped drive (Z:) but not requiring the drive letter but more like a xNIX mount point.

So we do this mainly by monitoring Creates in PreCreate handler and using STATUS_REPARSE to redirect the Creates thru WebDav redirector to the remote server.

There is some additional complexity in Pre/PostCreate due the way Windows validates paths that requires us to make sure we create the mirror directory structure of the remote server locally even though all files are stored remotely. So doing this requires us to generate additional I/O in some cases so we end up calling FltCreate(remote path)… in either Pre or PostCreate to check to see if file or folder exists on the remote server.

So what we see is that sometimes the call to FltCreate in PreCreate to the remote server never returns. Other times it seems that after we have done the STATUS_REPARSE and handed things off to WebDav redirector then Webdav just seems to go out to lunch and stops doing anything.

If we see the problem again we’ll get some stack traces and LAN traces and post additional information.

Thanks again.