I’m in the process of converting a filter to use shadow file objects. It’s at the point where it works without any bugchecks but there are some issues.
I’m having a problem with writing to the SFO and I think it is a sharing/access issue. My Write routine completes with STATUS_SUCCESS but info is always zero and nothing is written to the file. Additionally, on the cache writes, CcCopyWrite returns TRUE but again, nothing is actually written. After setting breakpoints, I can see that the buffer and sizes are all valid values. Even when I try to use FltWriteFile in PreWrite, it also returns STATUS_SUCCESS but again with zero bytes written.
My shadow object is created successfully and the “upper” object can be opened with Notepad/Wordpad/etc without any issues the first time. The reason I think that there is a sharing issue is because when I try to open the file a second time, or write with certain programs, my pre-create throws 0xC0000043 (STATUS_SHARING_VIOLATION). I don’t quite understand this error because I mirror the create values when creating/opening the lower object and close the lower object when a close comes in for the upper object and clean up appropriately (or so I think).
I don’t want to overwhelm the post with a hodgepodge of code so if there are areas that may be suspect, please let me know and I can post those particular areas if needed. Thanks.
I would start by tracking the processing via FileSpy, or similar,
without your driver in place. Then with your driver in place, narrow
down the request which is failing and determine what is still open that
would cause the sharing violation. I would guess that you are not
correctly cleaning up the handles to your SFO’s. It’s trivial to add
tracking information on active opens so you can easily see what handles
remain open and what their accesses are.
SFO implementations are inherently complicated, both the SFO management
and deciding what the ‘cut-off’ line is between what you will handle at
your layer and what you will push off to the underlying file system.
Pete
On 8/29/2014 7:33 AM, xxxxx@gmail.com wrote:
I’m in the process of converting a filter to use shadow file objects. It’s at the point where it works without any bugchecks but there are some issues.
I’m having a problem with writing to the SFO and I think it is a sharing/access issue. My Write routine completes with STATUS_SUCCESS but info is always zero and nothing is written to the file. Additionally, on the cache writes, CcCopyWrite returns TRUE but again, nothing is actually written. After setting breakpoints, I can see that the buffer and sizes are all valid values. Even when I try to use FltWriteFile in PreWrite, it also returns STATUS_SUCCESS but again with zero bytes written.
My shadow object is created successfully and the “upper” object can be opened with Notepad/Wordpad/etc without any issues the first time. The reason I think that there is a sharing issue is because when I try to open the file a second time, or write with certain programs, my pre-create throws 0xC0000043 (STATUS_SHARING_VIOLATION). I don’t quite understand this error because I mirror the create values when creating/opening the lower object and close the lower object when a close comes in for the upper object and clean up appropriately (or so I think).
I don’t want to overwhelm the post with a hodgepodge of code so if there are areas that may be suspect, please let me know and I can post those particular areas if needed. Thanks.
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
–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295
When you issue the lower writes, are you issuing paging I/O?
My guess is that you’re running into EOF issues. Writes past EOF for paging I/O don’t move EOF but may succeed.
Tony
OSR
Thanks Tony! I guess you wouldn’t be the moderator if you didn’t know what you were talking about. Once I added an EOF extension, it all works well.
And thanks for the suggestion Pete. It seems that something is not being released (which I still haven’t figured out) that is preventing a cleanup/close from coming in but I think I am close to figuring it out. Now if only I could get !htrace to work…
What’s not working about it?
-scott
OSR
@OSRDrivers
wrote in message news:xxxxx@ntfsd…
Thanks Tony! I guess you wouldn’t be the moderator if you didn’t know what
you were talking about. Once I added an EOF extension, it all works well.
And thanks for the suggestion Pete. It seems that something is not being
released (which I still haven’t figured out) that is preventing a
cleanup/close from coming in but I think I am close to figuring it out. Now
if only I could get !htrace to work…
If I do
!htrace 0
it seems to print out everything for the system which doesn’t do me much good. I actually let the printout go for a few minutes before I just ended up killing the debug session. Then if I do
!htrace 0
I get the following:
kd> !htrace 0 fffff880`03373000
Process 0xfffff88003373000
ObjectTable 0x6800002000000000
ERROR: Cannot read structure field value at 0x6800002000000038, error 1
ERROR: Cannot read object table debug information.
--------------------------------------
Parsed 0x0 stack traces.
Dumped 0x0 stack traces.
So either too much or nothing. Obviously I don’t have something configured correctly but from the little documentation that is available on !htrace, I can’t seem to figure out what that may be.
From the WinDbg docs the syntax is:
!htrace [Handle [Process [Max_Traces]]]
So specifying your driver name is wrong.
This also requires that Handle Tracing be enabled for the process address
specified. If you have Driver Verifier running it’s on for the System
Process, which will cover any Kernel handles that are created. For other
processes you can use Application Verifier.
-scott
OSR
@OSRDrivers
wrote in message news:xxxxx@ntfsd…
If I do
!htrace 0
it seems to print out everything for the system which doesn’t do me much
good. I actually let the printout go for a few minutes before I just ended
up killing the debug session. Then if I do
!htrace 0
I get the following:
kd> !htrace 0 fffff880`03373000
Process 0xfffff88003373000
ObjectTable 0x6800002000000000
ERROR: Cannot read structure field value at 0x6800002000000038, error 1
ERROR: Cannot read object table debug information.
--------------------------------------
Parsed 0x0 stack traces.
Dumped 0x0 stack traces.
So either too much or nothing. Obviously I don’t have something configured
correctly but from the little documentation that is available on !htrace, I
can’t seem to figure out what that may be.