> Now a break point was triggered correctly after the operation was started.
I’m not sure i understood you right. About what operation you are talking
about? How much time passed before a break point was triggered?
The mini filter implements a layered FS where a reparse point is created and when this reparse point is read the filter driver intercepts IRP_MJ_READ and fetches data by contacting a user mode application which brings the data from a backend storage.
What i meant by operation was - the proper functioning of the driver.
the breakpoint was triggered only after the copy started happening.
It’s stack corruption. Now i’m absolutely sure. Do you use
FltQueueDeferredIoWorkItem routine to defer work?
no, there is a separate system thread created. from the post callback work items are created and pushed in a list. The system thread pulls the workitems from the list and processes them.
The question I have is - how is this stack corruption avoided when the calls to filter manager are serialized by using a mutex.
Are you sure you don’t pass to system thread work items with pointer to
variable allocated from stack?
The question I have is - how is this stack corruption avoided when the
calls to filter manager are serialized by using a mutex.
For example, when you use mutex the thread blocks for some time and routine
which corrupts stack writes to stack exactly at this moment. I.e. before
FltGetStreamContext routine was called.
no, the work items are allocated from a non paged pool.
I meant not work items directly. I meant don’t you pass some pointer to
variable with queued work?
I rechecked, for queued work no pointer a variable on stack is passed.
But crash is because of stack corruption. By the way. You have everything
works well with driver verifier because it’s waiting for IRP to be
completed and therefore stack area to be corrupted isn’t in use. Now I can
help only by browsing the sources.
Though, i can make one more patch. Wait a little.
Breakpoint occurs only while FltpGetStreamListCtrl routine is being
executed?
How many CPUs your virtual machine has?
I hope you have virtual machine with one CPU. Try these commands:
e fltmgr+0x12A5 0F 23 C4 0F 21 F8 48 0D 03 00 09 00 0F 23 F8 48 89 4C 24 08
E9 07 00 00 00 90 90 E9 E0 FF FF FF;
e fltmgt+0x1640 0F 21 FB 48 83 E3 FC 0F 23 FB EB 15 48 8D 8B 08 05 00 00 FF
15 EF 6A 01 00 FF 15 31 6B 01 00 EB DB 48 83 C4 40 41 5F 41 5E 5F 5E 5B C3
CC 90 90;
I patched FltpGetStreamListCtrl routine to make it set hardware breakpoint
to be occured when there will be writing into return address. Breakpoint is
set right after routine is called. Also it disables this breakpoint right
before returning.
When there will be writing to return address the breakpoint will be occured
and you will ba able to see a writer.
Don’t use any breakpoints at all with this patch.
For the second patching instruction, I am getting an error.
kd> e fltmgt+0x1640 0F 21 FB 48 83 E3 FC 0F 23 FB EB 15 48 8D 8B 08 05 00 00 FF 15 EF 6A 01 00 FF 15 31 6B 01 00 EB DB 48 83 C4 40 41 5F 41 5E 5F 5E 5B C3 CC 90 90;
Couldn’t resolve error at ‘fltmgt+0x1640 0F 21 FB 48 83 E3 FC 0F 23 FB EB 15 48 8D 8B 08 05 00 00 FF 15 EF 6A 01 00 FF 15 31 6B 01 00 EB DB 48 83 C4 40 41 5F 41 5E 5F 5E 5B C3 CC 90 90;’
kd> e fltmgt+0x1640 0F 21 FB 48 83 E3 FC 0F 23 FB EB 15 48 8D 8B 08 05 00 00 FF 15 EF 6A 01 00 FF 15 31 6B 01 00 EB DB 48 83 C4 40 41 5F 41 5E 5F 5E 5B C3 CC 90 90
Couldn’t resolve error at ‘fltmgt+0x1640 0F 21 FB 48 83 E3 FC 0F 23 FB EB 15 48 8D 8B 08 05 00 00 FF 15 EF 6A 01 00 FF 15 31 6B 01 00 EB DB 48 83 C4 40 41 5F 41 5E 5F 5E 5B C3 CC 90 90’
Try these:
e fltmgr+0x12A5 0F 23 C4 0F 21 F8 48 0D 03 00 09 00 0F 23 F8 48 89 4C 24 08
E9 07 00 00 00 90 90 E9 E0 FF FF FF;
e fltmgr+0x1640 0F 21 FB 48 83 E3 FC 0F 23 FB EB 15 48 8D 8B 08 05 00 00 FF
15 EF 6A 01 00 FF 15 31 6B 01 00 EB DB 48 83 C4 40 41 5F 41 5E 5F 5E 5B C3
CC 90 90;
thanks. these patching instructions worked , but due to a single CPU the VM is really slow.
I will post the result.
My test case is aborting due to the slow VM and I need to modify the test case, I will recheck the test case and post the results tomorrow.
Thanks.
Don’t add CPUs to vm.
yes, I have kept the CPUs to 1 and re-ran the testcase.
The breakpoint was not hit but while running the testcase the VM crashed and the analyze-v output points to ntkrnlmp.exe, the stack is corrupted but I believe that the source of the crash is the same.
Was it just one VM crash? Or is it stable? What virtual machine you use?