I am seeing some very strange behaviour when my filter driver filters
device objects from the FileSystem\MRxDAV WebDAV redirector. Are there
known issues here that I need to be aware of?
I have a simple passive filter driver which installs filter device objects
over file system device objects (using IoRegisterFsRegistrationChange) and
volume device objects (by looking for mount requests). The filter is very
simple at the moment. It just KdPrint()s the path in any CREATE IRPs. It
all works fine as long as I don’t hook the WebDAV redirector.
As soon as I hook the WebDAV redirector I see some screwy IRP behaviour
when opening Windows Explorer with no WebDAV drives mapped. If I map a
drive letter to a WebDAV share the system appears to hang when I log on.
Using OSR’s IrpTracker I can see that the major function code changes
between stack locations on some of the IRPs that have gone through to
WebDavRedirector. It looks like WebDavRedirector is maybe trashing IRPs
that have already been completed. I see this behaviour even if my filter
device’s dispatch routine is simply:
pCurrentLoc = IoGetCurrentIrpStackLocation(pIrp);
pNextLoc = IoGetNextIrpStackLocation(pIrp);
pMyExt = (PMYEXTENSION) pDeviceObject->DeviceExtension;
*pNextLoc = *pCurrentLoc;
// Guard against naughty drivers above us that have copied their
// completion routine pointer into our stack location.
IoSetCompletionRoutine(pIrp, DummyCompletion, NULL, FALSE, FALSE, FALSE);
return IoCallDriver(pCWExt->m_pDev, pIrp);
I get the same behaviour if I use the IoCopyCurrentIrpStackLocationToNext
macro.
So I guess my questions are:
- Are there known issues here?
- If so, are there known workarounds?
- If not, have I done something dumb?
Your help would be most appreciated. Thanks,
Richard Cartwright
The WebDav filesystem in XP was extremely unreliable in my experience.
We couldn’t get Office documents to save reliably on a WebDav share even
without our filter running on most of the machines we tested. In the
end, we decided not to support it. Maybe it’s been improved in Win2k3.
In the background, the WebDav driver hands off all filesystem requests
to a user-mode service that performs the actual I/O on temporary files
in the IE temp folder that are mirrors of the actual remote file. It’s
not pretty.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Richard
Cartwright
Sent: Tuesday, May 13, 2003 8:54 PM
To: File Systems Developers
Subject: [ntfsd] IRP corruption filtering WebDav redirector
I am seeing some very strange behaviour when my filter driver
filters device objects from the FileSystem\MRxDAV WebDAV
redirector. Are there known issues here that I need to be aware of?
I have a simple passive filter driver which installs filter
device objects over file system device objects (using
IoRegisterFsRegistrationChange) and volume device objects (by
looking for mount requests). The filter is very simple at the
moment. It just KdPrint()s the path in any CREATE IRPs. It
all works fine as long as I don’t hook the WebDAV redirector.
As soon as I hook the WebDAV redirector I see some screwy IRP
behaviour when opening Windows Explorer with no WebDAV drives
mapped. If I map a drive letter to a WebDAV share the system
appears to hang when I log on.
Using OSR’s IrpTracker I can see that the major function code
changes between stack locations on some of the IRPs that have
gone through to WebDavRedirector. It looks like
WebDavRedirector is maybe trashing IRPs that have already
been completed. I see this behaviour even if my filter
device’s dispatch routine is simply:
pCurrentLoc = IoGetCurrentIrpStackLocation(pIrp);
pNextLoc = IoGetNextIrpStackLocation(pIrp);
pMyExt = (PMYEXTENSION) pDeviceObject->DeviceExtension;
*pNextLoc = *pCurrentLoc; // Guard against naughty drivers
above us that have copied their // completion routine pointer
into our stack location. IoSetCompletionRoutine(pIrp,
DummyCompletion, NULL, FALSE, FALSE, FALSE); return
IoCallDriver(pCWExt->m_pDev, pIrp);
I get the same behaviour if I use the
IoCopyCurrentIrpStackLocationToNext
macro.
So I guess my questions are:
- Are there known issues here?
- If so, are there known workarounds?
- If not, have I done something dumb?
Your help would be most appreciated. Thanks,
Richard Cartwright
You are currently subscribed to ntfsd as: xxxxx@nryan.com
To unsubscribe send a blank email to xxxxx@lists.osr.com