Helen,
There are some changes for network redirectors and the Multiple UNC
Provider (MUP) on Windows Vista that are likely affecting you. These
changes could account for why your network redirector driver may not be
working as expected on Windows Vista. I don’t believe that there are any
significant changes to the WNet APIs that would affect your network
provider DLL on Windows Vista.
The network redirectors and MUP changes on Windows Vista will be
documented in the the Windows Driver Kit (WDK) released with Windows
Vista Beta 2. Once Windows Vista Beta 2 is officially released, you can
download the WDK.
This information will also be provided to attendees at the IFS Plugfest
scheduled at Microsoft for the week of November 14-18th.
I am also including some excerpts from documentation on the
IOCTL_REDIR_QUERY_PATH request below that may help you resolve your
problems. I believe the problem with your current code is not
specifically related to the Windows Vista changes. Your code may be
assuming that the input and output buffers are the same. NOTE that this
IOCTL is a METHOD_NEITHER and the response is returned in Irp-UserBuffer
not IrpSp->Parameters.DeviceIoControl.Type3InputBuffer where the input
parameter is passed…
Regards,
Steven Baker
Programmer/Writer
Windows Driver Kits Team
============ Excerpts from documentation on IOCTL_REDIR_QUERY_PATH ===
Input Parameters
IrpSp->Parameters.DeviceIoControl.Type3InputBuffer is set to a
QUERY_PATH_REQUEST data structure containing the request.
typedef struct _QUERY_PATH_REQUEST {
ULONG PathNameLength;
PIO_SECURITY_CONTEXT SecurityContext;
WCHAR FilePathName[1];
} QUERY_PATH_REQUEST, *PQUERY_PATH_REQUEST;
PathNameLength - The length in bytes of the Unicode string contained in
the FilePathName member.
SecurityContext - A pointer to the security context.
FilePathName - A non-NULL terminated Unicode string of the form
<server><share><path>. The length of the string in bytes is specified
by the PathNameLength member.
Output Parameters
IRP->UserBuffer is set to a QUERY_PATH_REQUEST data structure containing
the response.
typedef struct _QUERY_PATH_RESPONSE {
ULONG LengthAccepted;
} QUERY_PATH_RESPONSE, *PQUERY_PATH_RESPONSE;
LengthAccepted - The length in bytes of the prefix claimed by the
provider from the Unicode string path specified in the FilePathName
member of the QUERY_PATH_REQUEST structure.
…
I/O Status Block
The Status member is set to STATUS_SUCCESS on success if the
\server\share prefix name is recognized or an appropriate NTSTATUS
value such as one of the following:
STATUS_BAD_NETWORK_PATH
The specified share name cannot be found on the remote server. The
machine name (\server, for example) is valid, but specified share name
cannot be found on the remote server.
STATUS_BAD_NETWORK_NAME
The network path cannot be located. The machine name (\server, for
example) is not valid or the network redirector cannot resolve the
machine name (using whatever name resolution mechanisms are in use).
STATUS_INSUFFICIENT_RESOURCES
There were insufficient resources available to allocate memory for
buffers.
STATUS_INVALID_DEVICE_REQUEST
An IOCTL_REDIR_QUERY_PATH request should only come from MUP and the
requestor mode of the IRP should always be KernelMode. This error code
is returned if the requestor mode of the calling thread was not
KernelMode.
…
Comments
Network redirectors should only honor kernel-mode senders of this IOCTL,
by verifying that Irp->RequestorMode is KernelMode.
Note that IOCTL_REDIR_QUERY_PATH is a METHOD_NEITHER IOCTL. This means
that the input and output buffers may not be at the same address. A
common mistake by UNC providers is to assume that the input buffer and
the output buffer are the same and use the input buffer pointer to
provide the response.
When a UNC provider receives an IOCTL_REDIR_QUERY_PATH request, it has
to determine whether or not it can handle the UNC path specified in the
FilePathName member of the QUERY_PATH_REQUEST structure. If so, it has
to update the LengthAccepted member of the QUERY_PATH_RESPONSE structure
with the length in bytes of the prefix it has claimed and complete the
IRP with STATUS_SUCCESS. If the provider cannot handle the UNC path
specified, then it must fail the IOCTL_REDIR_QUERY_PATH request with an
appropriate NTSTATUS error code and must not update the LengthAccepted
member of the QUERY_PATH_RESPONSE structure. Providers must not modify
any of the other members or the FilePathName string under any condition.
…
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Helen Friedland
Sent: Thursday, September 22, 2005 10:15 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Any changes in network provider behavior in
Longhorn/Vista?
Tony,
Thank you for your reply. Yes, I looked in the Platform SDK
documentation, but there’s nothing there about Vista.
The way I handle IOCTL_REDIR_QUERY_PATH in the file system driver is as
follows:
I get QUERY_PATH_REQUEST from
currentIrpStack->Parameters.DeviceIoControl.Type3InputBuffer.
Then I compare it to the UNC Server path that I am supposed to support
and return the number of bytes matched in
PQUERY_PATH_RESPONSE (which, incidently points the same buffer
currentIrpStack->Parameters.DeviceIoControl.Type3InputBuffer).
and
Irp->IoStatus.Information = sizeof *pathResponse
Irp->IoStatus.Status = STATUS_SUCCESS;
This is taken from the example by Nagar…
I am wondering if I am supposed to handle IOCTL_REDIR_QUERY_PATH
differently in Vista… Unfortunately, it is not documented in the IFS
Kit, so my only source on information on this is Nagar’s book which is
old.
I believe I am registered before the other redirectors.
I know I already mentioned it, but this code works perfectly well in
Windows XP…
Thanks.
Helen.
Tony Mason wrote:
Helen,
Network Provider’s are a user mode component, documented as part
of the Platform SDK. Have you checked the Platform SDK documentation
for any warnings in this area?
If you are getting far enough that you get the UNC call, it
sounds like your NP has already been traversed, though (in general, you
get called once the NP indicates the name to MPR). Is your query path
call successful? Are you registered before or after the other
redirectors?
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com http:</http:>
Looking forward to seeing you at the next OSR File Systems class
in Los Angeles, CA October 24-27, 2005.
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Helen Friedland
Sent: Friday, September 23, 2005 12:22 AM
To: ntfsd redirect
Subject: [ntfsd] Any changes in network provider behavior in
Longhorn/Vista?
Hello,
I have my own file system with a network provider dll that works
fine in Windows XP/2000. It supports UNC paths.
However, it does not work with Vista Beta-1.
This is what happens:
The network provider dll gets loaded fine.
At some point my file system driver receives
IOCTL_REDIR_QUERY_PATH
which I handle the usual way – I return the length of the UNC
path recognized, etc.
However, IRP_MJ_CREATE on the UNC path is never called (on
Windows XP, this is what gets called).
So if I try to browse to the path in the explorer, at this point
the explorer gives an error “Network path is not found”.
I guess my question is are their any changes to network provider
API in Vista? Am i missing an implementation of some NP capability that
is new to Vista? Where would I look for the information on this?
Any pointers are appreciated.
Thanks.
Helen.
Yahoo! for Good
Click here to donate http:</http:>
to the Hurricane Katrina relief effort. — Questions? First check the
IFS FAQ at https://www.osronline.com/article.cfm?id=17 You are currently
subscribed to ntfsd as: xxxxx@osr.com To unsubscribe send a blank email
to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to
xxxxx@lists.osr.com
Yahoo! for Good
Click here to donate http:</http:> to the
Hurricane Katrina relief effort. — Questions? First check the IFS FAQ
at https://www.osronline.com/article.cfm?id=17 You are currently
subscribed to ntfsd as: xxxxx@windows.microsoft.com To unsubscribe
send a blank email to xxxxx@lists.osr.com