Hi all,
I’m implementing a minifilter that hook into post create, pre cleanup and pre close.
in post create and pre cleanup I search for an ADS, read it and indicate the data to a user-mode application that do some processing. In pre close I only do some cleanups.
I have a weird problem that happen with winword.
When I open the first file everything is OK. when I open the second file the file is open as “Read Only”.
I can see in procmon and in the filter that when this happen there is a create request from winword with write access that fails with SHARING_VIOLATION.
I tried to see using procmon who did create and not close and I coudn’t see any process.
This is the first time that a create with write access is asked for this file.
To make things more complex: this problem doesn’t happen when I open the files from winword “file open” menu. It only happen when openning the files from file explorer.
In addition it doesn’t happen when I mark the two files and open them together. It only happen when openning one file at a time.
Any ideas?
Any suggestions how to debug this?
Regards,
Sagi
We have to assume that your ADS handling is getting in the way. Typically
“not from explorer, but OK from file open” means a timing window (explorer
will open the file and then close it and then word will open it almost
immediately).
Sharing between ADS and ::$DATA usually do not interact, however watch out
for DELETE sharing.
Any suggestions how to debug this?
Me, I would eyeball my code, but you might want to experiment with adding
IO_IGNORE_SHARE_ACCESS_CHECK until it works and then work out what that
create is important…
Rod
wrote in message news:xxxxx@ntfsd…
> Hi all,
> I’m implementing a minifilter that hook into post create, pre cleanup and
> pre close.
> in post create and pre cleanup I search for an ADS, read it and indicate
> the data to a user-mode application that do some processing. In pre close
> I only do some cleanups.
>
> I have a weird problem that happen with winword.
> When I open the first file everything is OK. when I open the second file
> the file is open as “Read Only”.
> I can see in procmon and in the filter that when this happen there is a
> create request from winword with write access that fails with
> SHARING_VIOLATION.
>
> I tried to see using procmon who did create and not close and I coudn’t
> see any process.
> This is the first time that a create with write access is asked for this
> file.
>
> To make things more complex: this problem doesn’t happen when I open the
> files from winword “file open” menu. It only happen when openning the
> files from file explorer.
>
> In addition it doesn’t happen when I mark the two files and open them
> together. It only happen when openning one file at a time.
>
> Any ideas?
> Any suggestions how to debug this?
>
> Regards,
> Sagi
>
10x for the reply.
I do think that its timing issue. I did some debugging and I temporary removed some of the code in the user-mode application that do the process in file open and file close. The code that I removed has nothing to do with the file system. After doing so the problem occured only after several tries to recreate it. I tried to verify that its a timing issue by adding sleep instead of the code that I removed and than the “Read Only” appeared allways as before.
Can it be that this issue depends only or timing and not on actions of the driver/application?
Can it be that this happen only because I extend handling of post-create, pre-cleanup and pre-close?
in your suggestion to add IO_IGNORE_SHARE_ACCESS_CHECK did you mean in the filter pre-create?
I will try this but I’m not really sure for now what to do when I will find out the problematic create.
I will update the forum whe I have more info.
Any more help is very welcome.
Regards,
Sagi
I would look some more into what Rod has suggested. ADS and the main stream interfere in delete sharing (at least for NTFS). You would set IO_IGNORE_SHARE_ACCESS_CHECK in the Flags parameter in FltCreateFile and friends.
How and when do you open your ADS and when do you close that handle ?
Thanks,
Alex.
From: xxxxx@lists.osr.com [xxxxx@lists.osr.com] on behalf of xxxxx@ngsoft.co.il [xxxxx@ngsoft.co.il]
Sent: Friday, October 02, 2009 23:15
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] Winword create fail with SHARING_VIOLATION
10x for the reply.
I do think that its timing issue. I did some debugging and I temporary removed some of the code in the user-mode application that do the process in file open and file close. The code that I removed has nothing to do with the file system. After doing so the problem occured only after several tries to recreate it. I tried to verify that its a timing issue by adding sleep instead of the code that I removed and than the “Read Only” appeared allways as before.
Can it be that this issue depends only or timing and not on actions of the driver/application?
Can it be that this happen only because I extend handling of post-create, pre-cleanup and pre-close?
in your suggestion to add IO_IGNORE_SHARE_ACCESS_CHECK did you mean in the filter pre-create?
I will try this but I’m not really sure for now what to do when I will find out the problematic create.
I will update the forum whe I have more info.
Any more help is very welcome.
Regards,
Sagi
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
Hi,
I open the ADS with IO_IGNORE_SHARE_ACCESS_CHECK flag.
I open it in post-create read the ADS and close it (all inside post-create handling)
and open, read it and close it again in pre-cleanup (all inside pre-create handling).
When the send the indication to the user-mode application the ADS stream is closed.
I open the ADS with write, read and delete share.
Just for a check I added in pre-create FILE_SHARE_WRITE to requested ShareAccess.
After this change I never saw the problem.
I know that this is not a solution but its a hint the problem is not with the ADS that I open but with sharing violation of the file itself.
Any new ideas?
Thanks,
Sagi
Hi All,
As I said before I suspected that this problem doesn’t occur because of a specific thing that my driver or application is doing. It seem like a matter of synchronization.
To verify this I took the scanner sample from the DDK and tried to recreate the prblem using it.
To simulate the handling that my application is doing I added a 100 ms sleep in the scanuser.exe message handling.
now that the scanner minifilter is running and scanuser.exe is running I tried to open some word documents (word 2003 but also happen in word 2007) and I can see the same issue.
some of the documents open with “Read Only”.
I feel that its a synch issue between file explorer and winword.
As I said I can see that this issue happen in the second document that I open. but after more research I saw that if winword is open (with no document open) the problem also occur (sometimes) in the first document that I open. The difference between the two scenarios is that when winword is not open there is a delay between the “double click” in fexplorer and the file open (because winword is loading).
By now I’m pretty convinced that this issue is not specific to my driver (its definitly not connected to ADS), but does someone know of a work around for this problem?
Thanks,
Sagi
> By now I’m pretty convinced that this issue is not specific
to my driver (its definitly not connected to ADS), but does
someone know of a work around for this problem?
Unfortunately you may find that your customers do not respond to the logic.
In general if things break the last thing installed will be blamed.
You might find that someone can point you to a KB referring to this issue,
otherwise you are going to have to diagnose it yourself. My guess that a
well placed CcWaitForLazyWriter might help you out, but it will have to well
placed or you will pan performance.
Rod
Hi,
If my analyze is correct than the faulty modules are file explorer and winword (and how they synchronize with each other).
This seem strange.
Regarding CcWaitForLazyWriter. I found an API called CcWaitForCurrentLazyWriterActivity.
It looks like an API that file system drivers use and not minifilter. Is it OK to be called by minifilters?
Thanks,
Sagi
> If my analyze is correct than the faulty modules are file explorer and
winword (and how they synchronize with each other).
I’d say that you know the “what”, but not the “why”. You need to understand
what flow of operations is interacting with which other flow of operations
to cause the failure. This will may well be very tricky - there is a
Schroedingers cate issue that the act of measurement may perturb the system
enough to mak it work. Start with FileSpy and see whether it helps.
Once you know the why you can hypothesise of ways of avoiding the issue. I
only suggested CcWait because the lazy writer is often a good cause of
timing related issues…
This seem strange.
You said it
Regarding CcWaitForLazyWriter. I found an API called
CcWaitForCurrentLazyWriterActivity.
It looks like an API that file system drivers use and not minifilter. Is
it OK to be called by minifilters?
Good point. My copy of the doc doesn’t say that you mustn’t use it, but it
really is a use with care operation. *never* use it in a paging path and
make sure that you never hold locks when you call it. This last makes it of
at best dubious utility for a filter - just because you don’t hold locks
doesn’t mean that some filter above you isn’t holding locks…
But you first stage is to understand the flow of operations which cause the
failure…