Oplocks handling in minifilter and sharing violation errors from office 2010

Hello,

In my minifilter’s PostOpCreate, I reopen the file using FltCreateFile if the file object passed to me doesn’t have read access. If I get back STATUS_OPLOCK_BREAK_IN_PROGRESS, I schedule a work queue item that waits for the oplock break to complete and then reopens the file.

Let’s assume that this minifilter is installed on a file server ‘S’. I am using office 2010 on client ‘C’ that is not running my minifilter. From winword.exe running on ‘C’, if I try to save a file on some DFS share on file server ‘S’, I get an error “‘file’ is currently in use. Try again later.”

NOTE: The error happens only when I am connected to share as a non-admin user. If I am connected as admin user, everything works fine.

If I unload my filter, everything works fine. Hence, it’s definitely my minifilter which is causing this issue.

Any thoughts?

Thanks.
-Prasad

Hello,

On further investigation, I find that, if I stop scheduling the work queue item OR stop re-opening the file from the work queue item, the issue goes away.

When I open file from the work queue item, my open call succeeds. However, I get two more calls from in parallel (from lanman server) which are failed by the FSD with STATUS_SHARING_VIOLATION and hence the error that winword.exe is getting. I am wondering why FSD should return this error when I am re-opening the file from my work queue item using maximum sharing (FILE_SHARE_READ|FILE_SHARE_WRITE|FILE_SHARE_DELETE)?

I implemented the current scheme by things based on the inputs that I received on the thread http://www.osronline.com/showthread.cfm?link=226839

Searching google reveals, many people have run into similar problems while saving documents from Office applications to network shares and most of the times AV software is found to be the causing it and many of these AV players have released patches to their products to fix this. This gives me an impression that it’s common issue and hence there must be a common solution?

In general, are there any set of guidelines that need to followed by a mini-filter in order to avoid issues with op-locks?

My goal is to scan the file as soon as the op-lock break completes.

Thanks.
-Prasad

I suspect because Office does not permit some set of operations, for
example, it might open only with permit-read access. Any attempt to open
a handle with greater rights would result in a sharing error. So opening
it with maximum rights conflicts with the already-applied limitations. Do
you need, for example, write and delete capabilities? If you do, the file
system is correctly saying you can’t get them and therefore you have to
re-think what you are trying to do; if you only need read rights, why are
you asking for more?
joe

Hello,

On further investigation, I find that, if I stop scheduling the work queue
item OR stop re-opening the file from the work queue item, the issue goes
away.

When I open file from the work queue item, my open call succeeds. However,
I get two more calls from in parallel (from lanman server) which are
failed by the FSD with STATUS_SHARING_VIOLATION and hence the error that
winword.exe is getting. I am wondering why FSD should return this error
when I am re-opening the file from my work queue item using maximum
sharing (FILE_SHARE_READ|FILE_SHARE_WRITE|FILE_SHARE_DELETE)?

I implemented the current scheme by things based on the inputs that I
received on the thread http://www.osronline.com/showthread.cfm?link=226839

Searching google reveals, many people have run into similar problems while
saving documents from Office applications to network shares and most of
the times AV software is found to be the causing it and many of these AV
players have released patches to their products to fix this. This gives me
an impression that it’s common issue and hence there must be a common
solution?

In general, are there any set of guidelines that need to followed by a
mini-filter in order to avoid issues with op-locks?

My goal is to scan the file as soon as the op-lock break completes.

Thanks.
-Prasad


NTFSD is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

For our schedule of debugging and file system seminars 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

Have you seen this table?

http://msdn.microsoft.com/en-us/library/windows/desktop/aa363874(v=vs.85).aspx

It has worked for me, you can check the desiredaccess and sharedmode
between the first create and subsequent creates at your end to see if
you are doing the right thing or not.

having said that, the right way to scan fails in the most non invasive
fashion is to use the filter oplock, see FILE_RESERVE_OPFILTER in
ntcreatefile .
HTH,
Johri

On Mon, Sep 2, 2013 at 6:01 PM, wrote:
> I suspect because Office does not permit some set of operations, for
> example, it might open only with permit-read access. Any attempt to open
> a handle with greater rights would result in a sharing error. So opening
> it with maximum rights conflicts with the already-applied limitations. Do
> you need, for example, write and delete capabilities? If you do, the file
> system is correctly saying you can’t get them and therefore you have to
> re-think what you are trying to do; if you only need read rights, why are
> you asking for more?
> joe
>
>> Hello,
>>
>> On further investigation, I find that, if I stop scheduling the work queue
>> item OR stop re-opening the file from the work queue item, the issue goes
>> away.
>>
>> When I open file from the work queue item, my open call succeeds. However,
>> I get two more calls from in parallel (from lanman server) which are
>> failed by the FSD with STATUS_SHARING_VIOLATION and hence the error that
>> winword.exe is getting. I am wondering why FSD should return this error
>> when I am re-opening the file from my work queue item using maximum
>> sharing (FILE_SHARE_READ|FILE_SHARE_WRITE|FILE_SHARE_DELETE)?
>>
>> I implemented the current scheme by things based on the inputs that I
>> received on the thread http://www.osronline.com/showthread.cfm?link=226839
>>
>> Searching google reveals, many people have run into similar problems while
>> saving documents from Office applications to network shares and most of
>> the times AV software is found to be the causing it and many of these AV
>> players have released patches to their products to fix this. This gives me
>> an impression that it’s common issue and hence there must be a common
>> solution?
>>
>> In general, are there any set of guidelines that need to followed by a
>> mini-filter in order to avoid issues with op-locks?
>>
>> My goal is to scan the file as soon as the op-lock break completes.
>>
>> Thanks.
>> -Prasad
>>
>>
>> —
>> NTFSD is sponsored by OSR
>>
>> OSR is hiring!! Info at http://www.osr.com/careers
>>
>> For our schedule of debugging and file system seminars 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
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> For our schedule of debugging and file system seminars 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

@Joseph, I am re-opening the file in read mode only. While opening the file, I am specifying maximum sharing so that others can open the file while I am scanning. I am NOT getting the sharing violation error while re-opening the file. It’s winword.exe who is getting sharing violation error

Amritanshu, are you suggesting that I should re-open the file with FILE_RESERVE_OPFILTER? I am assuming that you are suggesting to use it with FltCreteFile? Also, the flag is available Windows 7(+) only and can fail if there are open handles.

Thanks.
-Prasad

hey, FILE_RESERVE_OPFILTER is an optimization see documentation for
FSCTL_REQUEST_FILTER_OPLOCK, the oplock is requested with the lowest
level of desired access (read attributes), which will not change the
oplock state for the file, so if this call is failing then the
"reopening of file in read only " might fail too. The advantage of
FILE_RESERVE_OPFILTER is that it reduces the small window that exists
between opening the handle and requesting the Filter oplock where a
sharing violation might happen still.

Perhaps, winword.exe at some point in its processing is opening the
file with desiredacces set to 0 (exclusive) which will fail because
of your handle. Hence the suggestion of using a FILTER oplock.

HTH,
Johri

On Tue, Sep 3, 2013 at 10:20 AM, wrote:
> @Joseph, I am re-opening the file in read mode only. While opening the file, I am specifying maximum sharing so that others can open the file while I am scanning. I am NOT getting the sharing violation error while re-opening the file. It’s winword.exe who is getting sharing violation error
>
> Amritanshu, are you suggesting that I should re-open the file with FILE_RESERVE_OPFILTER? I am assuming that you are suggesting to use it with FltCreteFile? Also, the flag is available Windows 7(+) only and can fail if there are open handles.
>
> Thanks.
> -Prasad
>
>
> —
> NTFSD is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> For our schedule of debugging and file system seminars 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

@Amritanshu, using FILE_RESERVE_OPFILTER solved the sharing violation issue reported by Winword. However, now, when I re-open the file from work queue item using FILE_RESERVE_OPFILTER, I am getting STATUS_OPLOCK_NOT_GRANTED for temporary file created by word and STATUT_SHARING_VIOLATION for the real file (the one I am trying to save). This defeats my purpose since I want to scan the file as soon as op-lock break completes.

Also reading documentation, it’s not clear to me as to how using FILE_RESERVE_OPFILTER stops sharing violation errors for other applications opening the same file? Can you elaborate a bit on it.

Also, if I change the “share permissions” from “Change, Read” to “Full Control, Change, Read”, the issue goes away even without using FILE_RESERVE_OPFILTER flag. I don’t know how it’s related.

My use case is the following and I would like to know guidelines in this specific context to avoid sharing issues.

  1. I perform scans from PostOpCreate and PreOpCleanup (last handle close)
  2. I require to re-open file if the original file object doesn’t have read permissions. I use FILE_COMPLETE_IF_OPLOCKED flag during re-open. If this triggers op-lock break, I would want to wait for op-lock break to complete and then re-open the file to trigger the scan.

Thanks.
-Prasad

hello! I think google rearranged my inbox for me :slight_smile: so I just saw your
reply. I bet you have made some progress by now. For completeness I
will reply to the thread.

If you look at the documentation around that flag you will see that
STATUS_OPLOCK_NOT_GRANTED most likely implies that there is already a
level1/filter oplock on the file. While status sharing violation will
happen when the existing handle to file doesn’t have FILE_SHARED_READ
set.

I am not sure why you are asking how the sharing violation is avoided.
At the risk of stating the obvious, oplock is a cache coherency
protocol, based on my understanding, when you specify that flag, the
create will succeed only when it is not in conflict with the current
oplock state of the file. Also, once you have an oplock the user mode
create will be getting blocked for the duration of the acknowledgement
of the break, hence avoiding the problem.

Till now I have mostly worked on legacy filters but here is what I
think you need to factor in, while re-opening in postcreate if the
original share access was exclusive or didn’t have file_share_read set
your Create is going to fail with Sharing violation any ways. Perhaps
the right way to scan the file in those scenario is to do it post
cleanup?

I dont know about the share permissions bit, if you have some fluency
on smb1/2 you can open the netmon traces and figure it out, I think
modifying share permissions in production environment might not be
acceptable to all :slight_smile:

HTH,
Johri

On Thu, Sep 5, 2013 at 1:31 PM, wrote:
> @Amritanshu, using FILE_RESERVE_OPFILTER solved the sharing violation issue reported by Winword. However, now, when I re-open the file from work queue item using FILE_RESERVE_OPFILTER, I am getting STATUS_OPLOCK_NOT_GRANTED for temporary file created by word and STATUT_SHARING_VIOLATION for the real file (the one I am trying to save). This defeats my purpose since I want to scan the file as soon as op-lock break completes.
>
> Also reading documentation, it’s not clear to me as to how using FILE_RESERVE_OPFILTER stops sharing violation errors for other applications opening the same file? Can you elaborate a bit on it.
>
> Also, if I change the “share permissions” from “Change, Read” to “Full Control, Change, Read”, the issue goes away even without using FILE_RESERVE_OPFILTER flag. I don’t know how it’s related.
>
> My use case is the following and I would like to know guidelines in this specific context to avoid sharing issues.
>
> 1. I perform scans from PostOpCreate and PreOpCleanup (last handle close)
> 2. I require to re-open file if the original file object doesn’t have read permissions. I use FILE_COMPLETE_IF_OPLOCKED flag during re-open. If this triggers op-lock break, I would want to wait for op-lock break to complete and then re-open the file to trigger the scan.
>
> Thanks.
> -Prasad
>
>
> —
> NTFSD is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> For our schedule of debugging and file system seminars 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 Amritanshu,

Thanks for your response.

I am using IO_IGNORE_SHARE_ACCESS_CHECK while re-opening the file from my minifilter. The re-opening of the file is creating side effects of applications (e.g. office in this case) getting sharing violation errors.

I have started another thread on the topic to validate whether re-opening the file in the mini-filter is really a viable option. You may have want to share your thoughts on the same at http://www.osronline.com/showthread.cfm?link=247683

Thanks.
-Prasad

Hi Amritanshu,

I explored further on the FSCTL_REQUEST_FILTER_OPLOCK/FILE_RESERVE_OPFILTER suggestion given by you and I don’t really see how it is going to help address my use case?

I wrote a sample application below (at end of this post) in user space that uses CreateFile/DeviceIoControl sequence to acquire a filter oplock on the file. It works exactly as expected. I run this application with a particular file and then if I try to modify the same file from other application say notepad.exe, the save action blocks. My WaitForSingleObject unblocks and it waits to press a key (getchar). After pressing a key my application “Gets out of the way” by closing the handle and then notepad.exe unblocks and proceeds with the save operation.

NOTE: My application succeeds to acquire the filter op-lock only if there is no handle open to the file. If I run filetest.exe and keep the file open in any sharing mode/desired access, my application cannot get the filter oplock and fails with ERROR_OPLOCK_NOT_GRANTED error.

This probably explains the behavior that I am getting in my minifilter too. When, I try to re-open the file PostOpCreate with FSCTL_REQUEST_FILTER_OPLOCK/FILE_RESERVE_OPFILTER, if fails with STATUS_OPLOCK_NOT_GRANTED. This is same as my user space application getting ERROR_OPLOCK_NOT_GRANTED.

This makes me go back to my question that: Should I reopen the file at all? I have asked this question at http://www.osronline.com/showthread.cfm?link=247683. But, haven’t really heard from anybody yet.

main(int argc, char **argv)
{
HANDLE hFile = INVALID_HANDLE_VALUE;
DWORD bytesReturned;
HANDLE hEvent = NULL;
OVERLAPPED ov = {0};
DWORD lastError;

if (argc != 2) {
printf(“Usage: %s filename\n”, argv[0]);
goto exit;
}

hFile = CreateFile(argv[1],
FILE_READ_ATTRIBUTES,
FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
NULL,
OPEN_EXISTING,
FILE_FLAG_OVERLAPPED,
NULL);
if (INVALID_HANDLE_VALUE == hFile) {
printf(“Unable to open file, lasterr = %d\n”, lastError = GetLastError());
goto exit;
}

hEvent = CreateEvent(NULL, FALSE, FALSE, NULL);
if (NULL == hEvent) {
printf(“Unable to create event object, lasterr = %d\n”, lastError = GetLastError());
goto exit;
}

ov.hEvent = hEvent;
if (FALSE == DeviceIoControl(hFile,
FSCTL_REQUEST_FILTER_OPLOCK,
NULL,
0,
NULL,
0,
&bytesReturned,
&ov)) {
lastError = GetLastError();
if (ERROR_IO_PENDING != lastError) {
printf(“DeviceIoControl failed, lasterr = %d\n”, lastError);
goto exit;
}
}

printf(“Waiting for event to get signaled”);
WaitForSingleObject(hEvent, INFINITE);
printf(“Event signaled”);
getchar();
exit:
if (INVALID_HANDLE_VALUE != hFile) {
CloseHandle(hFile);
}
if (NULL != hEvent) {
CloseHandle(hEvent);
}
return 0;
}

Thanks.
-Prasad

I suggested filter oplocks to avoid the failure you were getting in
the word application. It seems the other thread is closed now and
conclusions have been drawn.

On Wed, Sep 11, 2013 at 4:50 PM, wrote:
> Hi Amritanshu,
>
> I explored further on the FSCTL_REQUEST_FILTER_OPLOCK/FILE_RESERVE_OPFILTER suggestion given by you and I don’t really see how it is going to help address my use case?
>
> I wrote a sample application below (at end of this post) in user space that uses CreateFile/DeviceIoControl sequence to acquire a filter oplock on the file. It works exactly as expected. I run this application with a particular file and then if I try to modify the same file from other application say notepad.exe, the save action blocks. My WaitForSingleObject unblocks and it waits to press a key (getchar). After pressing a key my application “Gets out of the way” by closing the handle and then notepad.exe unblocks and proceeds with the save operation.
>
> NOTE: My application succeeds to acquire the filter op-lock only if there is no handle open to the file. If I run filetest.exe and keep the file open in any sharing mode/desired access, my application cannot get the filter oplock and fails with ERROR_OPLOCK_NOT_GRANTED error.
>
> This probably explains the behavior that I am getting in my minifilter too. When, I try to re-open the file PostOpCreate with FSCTL_REQUEST_FILTER_OPLOCK/FILE_RESERVE_OPFILTER, if fails with STATUS_OPLOCK_NOT_GRANTED. This is same as my user space application getting ERROR_OPLOCK_NOT_GRANTED.
>
> This makes me go back to my question that: Should I reopen the file at all? I have asked this question at http://www.osronline.com/showthread.cfm?link=247683. But, haven’t really heard from anybody yet.
>
> main(int argc, char **argv)
> {
> HANDLE hFile = INVALID_HANDLE_VALUE;
> DWORD bytesReturned;
> HANDLE hEvent = NULL;
> OVERLAPPED ov = {0};
> DWORD lastError;
>
> if (argc != 2) {
> printf(“Usage: %s filename\n”, argv[0]);
> goto exit;
> }
>
> hFile = CreateFile(argv[1],
> FILE_READ_ATTRIBUTES,
> FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
> NULL,
> OPEN_EXISTING,
> FILE_FLAG_OVERLAPPED,
> NULL);
> if (INVALID_HANDLE_VALUE == hFile) {
> printf(“Unable to open file, lasterr = %d\n”, lastError = GetLastError());
> goto exit;
> }
>
> hEvent = CreateEvent(NULL, FALSE, FALSE, NULL);
> if (NULL == hEvent) {
> printf(“Unable to create event object, lasterr = %d\n”, lastError = GetLastError());
> goto exit;
> }
>
> ov.hEvent = hEvent;
> if (FALSE == DeviceIoControl(hFile,
> FSCTL_REQUEST_FILTER_OPLOCK,
> NULL,
> 0,
> NULL,
> 0,
> &bytesReturned,
> &ov)) {
> lastError = GetLastError();
> if (ERROR_IO_PENDING != lastError) {
> printf(“DeviceIoControl failed, lasterr = %d\n”, lastError);
> goto exit;
> }
> }
>
> printf(“Waiting for event to get signaled”);
> WaitForSingleObject(hEvent, INFINITE);
> printf(“Event signaled”);
> getchar();
> exit:
> if (INVALID_HANDLE_VALUE != hFile) {
> CloseHandle(hFile);
> }
> if (NULL != hEvent) {
> CloseHandle(hEvent);
> }
> return 0;
> }
>
> Thanks.
> -Prasad
>
>
> —
> NTFSD is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> For our schedule of debugging and file system seminars 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

Well, the other thread is pretty much open and awaiting answers from the experts on the forum.

Thanks
-Prasad