Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results
The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.
Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/
Upcoming OSR Seminars | ||
---|---|---|
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead! | ||
Writing WDF Drivers | 12 September 2022 | Live, Online |
Internals & Software Drivers | 23 October 2022 | Live, Online |
Kernel Debugging | 14 November 2022 | Live, Online |
Developing Minifilters | 5 December 2022 | Live, Online |
Comments
because CSV can corrupt data if your driver is in the middle. Change your
driver to attach on top CSVFS stack.
Petr
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of [email protected]
Sent: Friday, July 29, 2011 11:50 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Cluster Shared Volume issue?
Hi All,
We have a encryption driver and when we install our driver on the Cluster
Shared Volume (CSV) node, the node redirects the volume. When i looked at
the logs i get Warning. Event ID 5125.
What do we need to do to make our driver compatible with CSV? I was unable
to find anything in MS documentation.
Has anyone came across this and made their driver compatible. I will
appreciate if i can get any pointer to make my driver compatible with CSV.
thanks
warning details
17416 06/23/2010 04:18:12 AM Warning <node_name> 5125
Microsoft-Windows-FailoverClusterin Cluster Shared Vol NT AUTHORITY\SYSTEM
Cluster Shared Volume 'Volume2' ('Cluster Disk 6') has identified one or
more active filter drivers on this device stack that could interfere with
CSV operations. I/O access will be redirected to the storage device over the
network through another Cluster node. This may result in degraded
performance. Please contact the filter driver vendor to verify
interoperability with Cluster Shared Volumes. Active filter drivers found:
<filter_driver_1>,<filter_driver_2>,<filter_driver_3>
---
NTFSD is sponsored by OSR
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
"CSV Metadata stack and avoid attaching to NTFS stack,"
If i understand you correctly, CSV has two stacks, Metadata and File System stack. we should avoid attaching to meta data stack? we should only attack to CSVFS stack
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of [email protected]
Sent: Saturday, July 30, 2011 12:50 AM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] Cluster Shared Volume issue?
Thanks Pert for the reply.
"CSV Metadata stack and avoid attaching to NTFS stack,"
If i understand you correctly, CSV has two stacks, Metadata and File System
stack. we should avoid attaching to meta data stack? we should only attack
to CSVFS stack
---
NTFSD is sponsored by OSR
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
Hello. Currently I've an issue with corrupted IRP inside my minifilter driver with the next stack:
[0x5] nt!IofCallDriver + 0x59
[0x6] CsvFs!CsvFsCallDriverCallout + 0x17
[0x7] nt!KeExpandKernelStackAndCalloutInternal + 0x78
[0x8] nt!KeExpandKernelStackAndCalloutEx + 0x1d
[0x9] CsvFs!CsvFsRemoveTopLevelIrpAndCallDriver + 0x90
[0xa] CsvFs!CsvFsEnqueueSingleClientNotify + 0x255
[0xb] CsvFs!CsvFsResumeOplockUpgrades + 0xf1
[0xc] CsvFs!CsvFsVolumeMoveToActive + 0x302
[0xd] CsvFs!CsvFsHandleVolumeStateChangedWorkerRoutine + 0x93
[0xe] CsvFs!CsvFsThreadPoolWorkerRoutine + 0x139
[0xf] nt!PspSystemThreadStartup + 0x55
[0x10] nt!KiStartSystemThread + 0x1c
The IRP from CsvFsRemoveTopLevelIrpAndCallDriver has a single StackCount and CurrentLocation equal to zero
+0x000 Type : 0n6
+0x002 Size : 0x118
+0x008 MdlAddress : (null)
+0x010 Flags : 0x10
+0x018 AssociatedIrp :
+0x020 ThreadListEntry : _LIST_ENTRY [ 0xffffe503
154bf180 - 0xffffe503
154bf180 ]+0x030 IoStatus : _IO_STATUS_BLOCK
+0x040 RequestorMode : 0 ''
+0x041 PendingReturned : 0 ''
+0x042 StackCount : 1 ''
+0x043 CurrentLocation : 0 ''
+0x044 Cancel : 0 ''
+0x045 CancelIrql : 0 ''
+0x046 ApcEnvironment : 0 ''
+0x047 AllocationFlags : 0x4 ''
+0x048 UserIosb : (null)
+0x050 UserEvent : (null)
+0x058 Overlay :
+0x068 CancelRoutine : (null)
+0x070 UserBuffer : (null)
+0x078 Tail :
It leading to the NO_MORE_IRP_STACK_LOCATIONS BSOD.
I'm curious now, if CsvFs!CsvFsCallDriverCallout is a metadata stack, to which I have to AVOID attaching my minifilter, or CsvFs just allocated wrong StackCount because the minifilter wasn't attached in time when it queues TopLevelIrp.
How can I detect if the DEVICE_OBJECT is a Csv metadata stack with purpose to avoid attaching to it ???