Re: UNC Path Access on Window 2008 (Please Help!)

NTFSD
1

Are there any MUP experts on this forum?
Does anyone know what MUP expects from Local disk Filesystem drivers?

On Win2K8 IRP_MJ_DIRECTORY_CONTROL request (with IRP_MN_QUERY_DIRECTORY minor function code) after getting valid buffer and buffer length from our fsd
returns STATUS_INVALID_NETWORK_RESPONSE and never completes the request.
Any responses would be greatly appreciated!
-Jeff

From: “xxxxx@yahoo.com”
To: Windows File Systems Devs Interest List
Sent: Sun, April 18, 2010 1:22:45 PM
Subject: RE:[ntfsd] UNC Path Access on Window 2008

Here is the FileSpy trace of the failed path : IRP_MJ_DIRECTORY_CONTROL failure happens at #113
(notice that Y:\ and \Device\Mup\localhost\iwserver reference the same device)
When we call our Win2K8 server from Win2K3 we go though Y:. However, when we call win2K8 server from another win2K8 machine (or using \localhost) we go through \Device\Muo\localhost\iwserver.

# Time sent Dur. Process Thread ID DeviceObject Type IRP Request IRP Flags TopLvlIrp FileObject FsContext FsContext2 FO Flags Sop Path Status More info
…
…

93 12:58:16.416 0 cmd.exe 2236 99AB8C08 FastIO FASTIO_QUERY_OPEN A9FE9CAC 00000000 00000000 00000000 00000000 \Device\Mup\localhost\iwserver\default\main* FAILURE
94 12:58:16.416 0 cmd.exe 2236 99AB8C08 IRP 9982D008 IRP_MJ_CREATE 00000884 00000000 99DF02F8 00000000 00000000 00000000 00000000 \Device\Mup\localhost\iwserver\default\main* STATUS_OBJECT_NAME_INVALID FILE_OPEN CreOpts: 00200000 Access: 00000080 Share: 00000007 Attrib: 0
98 12:58:16.416 0 cmd.exe 2236 99AB8C08 IRP 9982D008 IRP_MJ_CREATE 00000884 00000000 99DF02F8 AEA901C0 AEA90460 00000002 00000000 \Device\Mup\localhost\iwserver STATUS_SUCCESS FILE_OPEN CreOpts: 00000021 Access: 00100000 Share: 0 Attrib: 0 Result: FILE_OPENED
95 12:58:16.416 0 System 1180 98D4CE38 IRP 9A4174E8 IRP_MJ_CREATE 00000884 00000000 998FD420 99EDC880 99A89008 00000000 00000000 Y: STATUS_SUCCESS FILE_OPEN CreOpts: 00000101 Access: 00000080 Share: 0 Attrib: 0 Result: FILE_OPENED
96 12:58:16.416 0 System 1180 98D4CE38 FastIO FASTIO_QUERY_NETWORK_OPEN_INFO 998FD420 99EDC880 99A89008 01040041 99EDC8A8 Y: STATUS_SUCCESS
97 12:58:16.416 0 System 1180 98D4CE38 IRP 99EF5E28 IRP_MJ_QUERY_INFORMATION 00060874 00000000 998FD420 99EDC880 99A89008 01040041 99EDC8A8 Y: STATUS_SUCCESS FileInternalInformation
99 12:58:16.416 0 cmd.exe 2236 99AB8C08 IRP 99EF5E28 IRP_MJ_QUERY_INFORMATION 00060870 00000000 99DF02F8 AEA901C0 AEA90460 00040002 999ADB5C \Device\Mup\localhost\iwserver STATUS_SUCCESS FileNameInformation
100 12:58:16.416 0 cmd.exe 2236 99AB8C08 IRP 99EF5E28 IRP_MJ_QUERY_VOLUME_INFORMATION 00060870 00000000 99DF02F8 AEA901C0 AEA90460 00040002 999ADB5C \Device\Mup\localhost\iwserver STATUS_SUCCESS FileFsVolumeInformation Length: 00000220
101 12:58:16.416 0 cmd.exe 2236 99AB8C08 IRP 99EF5E28 IRP_MJ_CLEANUP 00000404 00000000 99DF02F8 AEA901C0 AEA90460 00040002 999ADB5C \Device\Mup\localhost\iwserver STATUS_SUCCESS
104 12:58:16.416 0 cmd.exe 2236 99AB8C08 IRP 99EF5E28 IRP_MJ_CLOSE 00000404 00000000 99DF02F8 AEA901C0 AEA90460 00044002 999ADB5C \Device\Mup\localhost\iwserver STATUS_SUCCESS
102 12:58:16.416 0 System 952 98D4CE38 IRP 99E9F598 IRP_MJ_CLEANUP 00000404 00000000 998FD420 99EDC880 99A89008 01040041 99EDC8A8 Y: STATUS_SUCCESS
103 12:58:16.416 0 System 952 98D4CE38 IRP 99E9F598 IRP_MJ_CLOSE 00000404 00000000 998FD420 99EDC880 99A89008 01044041 99EDC8A8 Y: STATUS_SUCCESS
109 12:58:16.432 15 cmd.exe 2236 99AB8C08 IRP 99EE86B0 IRP_MJ_CREATE 00000884 00000000 9A4B5F80 AABF48B0 AABF4B50 00000002 00000000 \Device\Mup\localhost\iwserver\default\main STATUS_SUCCESS FILE_OPEN CreOpts: 00000021 Access: 00100001 Share: 00000007 Attrib: 0 Result: FILE_OPENED
105 12:58:16.432 0 System 1180 98D4CE38 IRP 9A8E5BA8 IRP_MJ_CREATE 00000884 00000000 99E7A218 99EDE8B0 99A89008 00000000 00000000 Y:\default\main STATUS_SUCCESS FILE_OPEN CreOpts: 00000101 Access: 00000081 Share: 00000007 Attrib: 0 Result: FILE_OPENED
106 12:58:16.432 0 System 1180 98D4CE38 FastIO FASTIO_QUERY_NETWORK_OPEN_INFO 99E7A218 99EDE8B0 99A89008 01040041 99EDE8D8 Y:\default\main STATUS_SUCCESS
107 12:58:16.432 15 System 1180 98D4CE38 IRP 99E74668 IRP_MJ_QUERY_SECURITY 00000004 00000000 99E7A218 99EDE8B0 99A89008 01040041 99EDE8D8 Y:\default\main STATUS_SUCCESS
108 12:58:16.447 0 System 1180 98D4CE38 IRP 99E74668 IRP_MJ_QUERY_INFORMATION 00060874 00000000 99E7A218 99EDE8B0 99A89008 01040041 99EDE8D8 Y:\default\main STATUS_SUCCESS FileInternalInformation
111 12:58:16.447 0 cmd.exe 2236 99AB8C08 IRP 99EE86B0 IRP_MJ_DIRECTORY_CONTROL/IRP_MN_QUERY_DIRECTORY 00060800 00000000 9A4B5F80 AABF48B0 AABF4B50 00040002 9A93E72C \Device\Mup\localhost\iwserver\default\main STATUS_SUCCESS FileBothDirectoryInformation FileMask: *
110 12:58:16.447 0 System 1180 98D4CE38 IRP 9983DCB0 IRP_MJ_DIRECTORY_CONTROL/IRP_MN_QUERY_DIRECTORY 00000000 00000000 99E7A218 99EDE8B0 99A89008 01040041 99EDE8D8 Y:\default\main STATUS_SUCCESS FileBothDirectoryInformation FileMask: *
113 12:58:16.447 0 cmd.exe 2236 99AB8C08 IRP 99EE86B0 IRP_MJ_DIRECTORY_CONTROL/IRP_MN_QUERY_DIRECTORY 00060800 00000000 9A4B5F80 AABF48B0 AABF4B50 00040002 9A93E72C \Device\Mup\localhost\iwserver\default\main STATUS_INVALID_NETWORK_RESPONSE FileBothDirectoryInformation FileMask:
112 12:58:16.447 0 System 4044 98D4CE38 IRP 9983DCB0 IRP_MJ_DIRECTORY_CONTROL/IRP_MN_QUERY_DIRECTORY 00000000 00000000 99E7A218 99EDE8B0 99A89008 01040041 99EDE8D8 Y:\default\main STATUS_SUCCESS FileBothDirectoryInformation FileMask: *
114 12:58:16.447 0 cmd.exe 2236 99AB8C08 IRP 99EE86B0 IRP_MJ_CLEANUP 00000404 00000000 9A4B5F80 AABF48B0 AABF4B50 00040002 9A93E72C \Device\Mup\localhost\iwserver\default\main STATUS_SUCCESS
117 12:58:16.447 0 cmd.exe 2236 99AB8C08 IRP 99EE86B0 IRP_MJ_CLOSE 00000404 00000000 9A4B5F80 AABF48B0 AABF4B50 00044002 9A93E72C \Device\Mup\localhost\iwserver\default\main STATUS_SUCCESS
115 12:58:16.447 0 System 1180 98D4CE38 IRP 99E9F598 IRP_MJ_CLEANUP 00000404 00000000 99E7A218 99EDE8B0 99A89008 01040041 99EDE8D8 Y:\default\main STATUS_SUCCESS
116 12:58:16.447 0 System 1180 98D4CE38 IRP 9A8E5BA8 IRP_MJ_CLOSE 00000404 00000000 99E7A218 99EDE8B0 99A89008 01044041 99EDE8D8 Y:\default\main STATUS_SUCCESS

Any suggestions?
-Jeff

—
NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

2

>Does anyone know what MUP expects from Local disk Filesystem drivers?

Am I wrong that local disk filesystems have nothing to do with MUP at all?

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

3

On 4/21/2010 8:29 AM, Maxim S. Shatskih wrote:

> Does anyone know what MUP expects from Local disk Filesystem drivers?

Am I wrong that local disk filesystems have nothing to do with MUP at all?

You are correct. Srv is the component which will call into the local
file systems when satisfying network requests.

To address the OPs question … there are a number of things which could
be going wrong. I would recommend to start by filtering the requests
coming into their local file system, the trace shown was captured on the
client or those going through MUP. If they post this information as
well, maybe we can be of more help.

Pete

–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295

4

OP has server and client on the same machine, so log contains also server requests. Notice localhost in the client path.

I thought that srv runs in the user mode land, so requests from system/kernel (on server side) are little bit suspicious for me.

The handling of dirlist IRP is quite difficult with regard to handling the request context (driven by ReturnSingleEntry, InitialQuery, IndexSpecified, RestartScan), status returning, all supported info classes and buffer arrangement like alignment of structures etc.

It seems that srv is not happy with some field of the FILE_BOTH_DIR_INFORMATION structure. Do you have tests which use the native API for dirlist, not WIN32 API? The reason I am asking is that the requests come from kernel? Maybe ReturnSingleEntry is not set in the first request. and FSD rely on it.

Bronislav Gabrhelik

5

On 4/21/2010 9:55 AM, xxxxx@xythos.com wrote:

OP has server and client on the same machine, so log contains also server requests. Notice localhost in the client path.

If the Y: drive is the physical device then the flow definitely
indicates that the directory_control request is not being correctly
handled by the local fsd. You can see the flow goes from the UNC path ->
routed via the localhost to srv (this is not evident) but then the
request comes back through the top of the stack in the SYSTEM context
into the local fsd. This happens twice for the directory_control requests.

It appears the first request, usually a ReturnSingleEntry but not
always, is correctly handled but then the subsequent request is not
correctly handled. Without looking through code and debugging the
returned information, it is difficult to speculate what could be the
problem.

The handling of dirlist IRP is quite difficult with regard to handling the request context (driven by ReturnSingleEntry, InitialQuery, IndexSpecified, RestartScan), status returning, all supported info classes and buffer arrangement like alignment of structures etc.

You have a fantastic source -> FastFat! It works and you can see exactly
how to handle these requests.

Pete

It seems that srv is not happy with some field of the FILE_BOTH_DIR_INFORMATION structure. Do you have tests which use the native API for dirlist, not WIN32 API? The reason I am asking is that the requests come from kernel? Maybe ReturnSingleEntry is not set in the first request. and FSD rely on it.

Bronislav Gabrhelik

NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295

6

Thank you for your responses,
As I stated in one of my previous posts single entry works just fine.
The failure happens during the first call to FindNextFile() (in my user mode test below) and only when directory listing contains more than 3 entries. Also failure happens only
when srv is on the stack. So Srv definitely does not like something that we are returning to it.
Our driver implementation has been around for 12 years now and it works fine on WinNT, Win2000 and Win2003. So this is something new on Win2008.
I have looked at FastFat before and I do not see any differences between how they handle the same request. I did not run FastFat on Win 2008 and I have not tried connecting to it
through localhost. This is something I’ll definitely try.

Here is my user mode test example:
hFind = FindFirstFile(szDir, &ffd);

if (INVALID_HANDLE_VALUE == hFind)
{
DisplayErrorBox(TEXT(“FindFirstFile”));
return dwError;
}

// List all the files in the directory with some info about them.

do
{
if (ffd.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY)
{
_tprintf(TEXT(" %s

\n"), ffd.cFileName);
}
else
{
filesize.LowPart = ffd.nFileSizeLow;
filesize.HighPart = ffd.nFileSizeHigh;
_tprintf(TEXT(" %s %ld bytes\n"), ffd.cFileName, filesize.QuadPart);
}
}
while (FindNextFile(hFind, &ffd) != 0); //first call to this function fails when directory contains more then 3 entries

Thank you,
-Jeff

________________________________
From: Peter Scott
To: Windows File Systems Devs Interest List
Sent: Wed, April 21, 2010 1:14:24 PM
Subject: Re: [ntfsd] Re: UNC Path Access on Window 2008 (Please Help!)

On 4/21/2010 9:55 AM, xxxxx@xythos.com wrote:
> OP has server and client on the same machine, so log contains also server requests. Notice localhost in the client path.
>

If the Y: drive is the physical device then the flow definitely indicates that the directory_control request is not being correctly handled by the local fsd. You can see the flow goes from the UNC path -> routed via the localhost to srv (this is not evident) but then the request comes back through the top of the stack in the SYSTEM context into the local fsd. This happens twice for the directory_control requests.

It appears the first request, usually a ReturnSingleEntry but not always, is correctly handled but then the subsequent request is not correctly handled. Without looking through code and debugging the returned information, it is difficult to speculate what could be the problem.

>
> The handling of dirlist IRP is quite difficult with regard to handling the request context (driven by ReturnSingleEntry, InitialQuery, IndexSpecified, RestartScan), status returning, all supported info classes and buffer arrangement like alignment of structures etc.
>

You have a fantastic source -> FastFat! It works and you can see exactly how to handle these requests.

Pete

> It seems that srv is not happy with some field of the FILE_BOTH_DIR_INFORMATION structure. Do you have tests which use the native API for dirlist, not WIN32 API? The reason I am asking is that the requests come from kernel? Maybe ReturnSingleEntry is not set in the first request. and FSD rely on it.
>
> Bronislav Gabrhelik
>
>
> ---
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

-- Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295

---
NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) visit: http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
7

On 4/21/2010 3:14 PM, J Sukh wrote:

Thank you for your responses,
As I stated in one of my previous posts single entry works just fine.
The failure happens during the first call to FindNextFile() (in my user
mode test below) and only when directory listing contains more than 3
entries. Also failure happens only
when srv is on the stack. So Srv definitely does not like something that
we are returning to it.

There is no reason why you need to return more than one entry at a time.
That said, as a test, why don’t you see if you can successfully work
through all the requests in the listing by returning them one at a time?
This would allow you to confirm that the content of each entry and the
returned status and information fields are correct.

Pete

Our driver implementation has been around for 12 years now and it works
fine on WinNT, Win2000 and Win2003. So this is something new on Win2008.
I have looked at FastFat before and I do not see any differences between
how they handle the same request. I did not run FastFat on Win 2008 and
I have not tried connecting to it
through localhost. This is something I’ll definitely try.

Here is my user mode test example:
hFind = FindFirstFile(szDir, &ffd);

if (INVALID_HANDLE_VALUE == hFind)
{
DisplayErrorBox(TEXT(“FindFirstFile”));
return dwError;
}
// List all the files in the directory with some info about them.

do
{
if (ffd.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY)
{
_tprintf(TEXT(" %s

\n"), ffd.cFileName);
> }
> else
> {
> filesize.LowPart = ffd.nFileSizeLow;
> filesize.HighPart = ffd.nFileSizeHigh;
> _tprintf(TEXT(" %s %ld bytes\n"), ffd.cFileName, filesize.QuadPart);
> }
> }
> while (FindNextFile(hFind, &ffd) != 0); //first call to this function
> fails when directory contains more then 3 entries
>
> Thank you,
> -Jeff
>
> ------------------------------------------------------------------------
> *From:* Peter Scott
> *To:* Windows File Systems Devs Interest List
> *Sent:* Wed, April 21, 2010 1:14:24 PM
> *Subject:* Re: [ntfsd] Re: UNC Path Access on Window 2008 (Please Help!)
>
> On 4/21/2010 9:55 AM, xxxxx@xythos.com
> wrote:
> > OP has server and client on the same machine, so log contains also
> server requests. Notice localhost in the client path.
> >
>
> If the Y: drive is the physical device then the flow definitely
> indicates that the directory_control request is not being correctly
> handled by the local fsd. You can see the flow goes from the UNC path ->
> routed via the localhost to srv (this is not evident) but then the
> request comes back through the top of the stack in the SYSTEM context
> into the local fsd. This happens twice for the directory_control requests.
>
> It appears the first request, usually a ReturnSingleEntry but not
> always, is correctly handled but then the subsequent request is not
> correctly handled. Without looking through code and debugging the
> returned information, it is difficult to speculate what could be the
> problem.
>
> >
> > The handling of dirlist IRP is quite difficult with regard to
> handling the request context (driven by ReturnSingleEntry, InitialQuery,
> IndexSpecified, RestartScan), status returning, all supported info
> classes and buffer arrangement like alignment of structures etc.
> >
>
> You have a fantastic source -> FastFat! It works and you can see exactly
> how to handle these requests.
>
> Pete
>
> > It seems that srv is not happy with some field of the
> FILE_BOTH_DIR_INFORMATION structure. Do you have tests which use the
> native API for dirlist, not WIN32 API? The reason I am asking is that
> the requests come from kernel? Maybe ReturnSingleEntry is not set in the
> first request. and FSD rely on it.
> >
> > Bronislav Gabrhelik
> >
> >
> > ---
> > NTFSD is sponsored by OSR
> >
> > For our schedule of debugging and file system seminars
> > (including our new fs mini-filter seminar) visit:
>> http://www.osr.com/seminars
> >
>> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> -- Kernel Drivers
> Windows File System and Device Driver Consulting
> www.KernelDrivers.com
> 866.263.9295
>
> ---
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
> ---
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

--
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295
8

> The failure happens during the first call to FindNextFile()
You are speaking about client side. I think you should concentrate on server side where is used (Zw)NtQueryDirectoryFile() directly (just my guess because it is called in system context). I would put there breakpoint, inspect passed parameters, and simulate the same behavior with test which uses native API (at server side!). As you will try to decode buffer in your test, you have chance to find the problem.

I am quite sure there is some problem how structures are fitted into buffer. I would check structure alignment (multiple of eight), NextEntryOffset and IO_STATUS_BLOCK.Information.

How is it with “…” “.” items? Do you emit them? My experience is that some silly applications including common dialogs require them, as they don’t expect the FindFirstFile() fails, but it is another topic.

Just to be sure, did you try to have the client on the other machine? Did you try some pre-Vista OS at client side. It might something indicate as CIFS was improved since Vista.

Good luck!
Bronislav Gabrhelik

9

On 4/22/2010 1:22 AM, xxxxx@xythos.com wrote:

> The failure happens during the first call to FindNextFile()
You are speaking about client side. I think you should concentrate on server side where is used (Zw)NtQueryDirectoryFile() directly (just my guess because it is called in system context). I would put there breakpoint, inspect passed parameters, and simulate the same behavior with test which uses native API (at server side!). As you will try to decode buffer in your test, you have chance to find the problem.

Right, I would agree, this is why the suggestion I made of simply adding
one entry at a time to the buffer and returning that, regardless of
whether they ask for one entry or not. This will allow you to confirm
the information returned from the IoStatus.Information/Status and the
content of individual buffers is correct. If this succeeds then move on
to adding multiple entries where the important aspects are, as you point
out, alignment as well as content.

Pete

–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295

10

Thanks again for your useful suggestions,
I did try clients on pre-Vista clients. Everything works fine there. The problem only happens when requests come from Win2008 clients (including Win 2008 localhost).
We do emit “.” successfully for directory listing of every size.
Did Srv change significantly on Win2008 compare to Win2003?
I found another interesting difference between how requests are handled between Win2K3 and Win2K8 clients.
IRPs for querying the same directory come in with different flags depending what client is sending it.

\ this IRP comes in from win2K3 client:
Local var @ 0xaa343bf0 Type _IRP*
0x9998c008
+0x000 Type : 0n6
+0x002 Size : 0x94
+0x004 MdlAddress : 0x9a42bfa0 _MDL
+0x008 Flags : 0x60800
+0x00c AssociatedIrp : __unnamed
+0x010 ThreadListEntry : _LIST_ENTRY [0x99934fa4 - 0x99934fa4]
+0x018 IoStatus : _IO_STATUS_BLOCK
+0x020 RequestorMode : 1 ‘’
+0x021 PendingReturned : 0 ‘’
+0x022 StackCount : 1 ‘’
+0x023 CurrentLocation : 1 ‘’
+0x024 Cancel : 0 ‘’
+0x025 CancelIrql : 0 ‘’
+0x026 ApcEnvironment : 0 ‘’
+0x027 AllocationFlags : 0x6 ‘’
+0x028 UserIosb : 0x0012eef0 _IO_STATUS_BLOCK
+0x02c UserEvent : (null)
+0x030 Overlay : __unnamed
+0x038 CancelRoutine : (null)
+0x03c UserBuffer : 0x0012ef38 Void
+0x040 Tail : __unnamed

\ this IRP comes in from win2K8 client:
1: kd> dt 0x9a63d4d8 _IRP
ntdll!_IRP
+0x000 Type : 0n6
+0x002 Size : 0x28c
+0x004 MdlAddress : 0x9995fb54 _MDL
+0x008 Flags : 0
+0x00c AssociatedIrp :
+0x010 ThreadListEntry : _LIST_ENTRY [0x9a63d4e8 - 0x9a63d4e8]
+0x018 IoStatus : _IO_STATUS_BLOCK
+0x020 RequestorMode : 0 ‘’
+0x021 PendingReturned : 0x1 ‘’
+0x022 StackCount : 15 ‘’
+0x023 CurrentLocation : 15 ‘’
+0x024 Cancel : 0 ‘’
+0x025 CancelIrql : 0 ‘’
+0x026 ApcEnvironment : 0 ‘’
+0x027 AllocationFlags : 0 ‘’
+0x028 UserIosb : (null)
+0x02c UserEvent : (null)
+0x030 Overlay :
+0x038 CancelRoutine : (null)
+0x03c UserBuffer : 0x9995fbf8 Void

________________________________
From: “xxxxx@xythos.com”
To: Windows File Systems Devs Interest List
Sent: Thu, April 22, 2010 12:22:52 AM
Subject: RE:[ntfsd] Re: UNC Path Access on Window 2008 (Please Help!)

> The failure happens during the first call to FindNextFile()
You are speaking about client side. I think you should concentrate on server side where is used (Zw)NtQueryDirectoryFile() directly (just my guess because it is called in system context). I would put there breakpoint, inspect passed parameters, and simulate the same behavior with test which uses native API (at server side!). As you will try to decode buffer in your test, you have chance to find the problem.

I am quite sure there is some problem how structures are fitted into buffer. I would check structure alignment (multiple of eight), NextEntryOffset and IO_STATUS_BLOCK.Information.

How is it with “…” “.” items? Do you emit them? My experience is that some silly applications including common dialogs require them, as they don’t expect the FindFirstFile() fails, but it is another topic.

Just to be sure, did you try to have the client on the other machine? Did you try some pre-Vista OS at client side. It might something indicate as CIFS was improved since Vista.

Good luck!
Bronislav Gabrhelik

—
NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer