Hello,
I am writing a mini-filter driver that performs encryption on NTFS
volumes on Windows 7. The altitude of the filter is 141000. The
driver registers callbacks for IRP_MJ_WRITE (plus sevel others) as
follows:
CONST FLT_OPERATION_REGISTRATION Callbacks = {
…
{ IRP_MJ_WRITE,
0, // no flags
NLFSEOpCallbackPreWrite,
NLFSEOpCallbackPostWrite },
…
};
CONST FLT_REGISTRATION FilterRegistration = {
sizeof( FLT_REGISTRATION ), // Size
FLT_REGISTRATION_VERSION, // Version
0, // Flags
ContextNotifications, // Context
Callbacks, // Operation callbacks
FilterUnload, // MiniFilterUnload
InstanceSetup, // InstanceSetup
NULL, // InstanceQueryTeardown
InstanceTeardownStart, // InstanceTeardownStart
NULL, // InstanceTeardownComplete
NULL, // GenerateFileName
NULL, // GenerateDestinationFileName
NULL // NormalizeNameComponent
};
// Register with FltMgr
status = FltRegisterFilter( DriverObject,
&FilterRegistration,
&nlfseGlobal.filterHandle );
NLFSEOpCallbackPreWrite() encrypts the data before it is written to
disk. It does so in the following manner:
try{
…
if (!(iopb->IrpFlags &
(IRP_NOCACHE | IRP_PAGING_IO | IRP_SYNCHRONOUS_PAGING_IO)))
{
//we only care about these IO operation
leave;
}
… encrypt the data here …
}
finally
{
}
The driver mostly works. When testing with user “apps” like IE,
Notepad, cmd.exe, The data written by the user app reaches the
encryption code in NLFSEOpCallbackPreWrite(), and the disk content
ends up being is encrypted.
However, when we test it with p4v.exe (Perforce Visual
Client/NTX86/2008.1/164135) as the user application (i.e. encrypting
the source code that p4v.exe retrieves to local disk), sometimes
encryption doesn’t occur. When the user tries to retrieve a certain
revision of a file from Perforce server, the file data never reaches
the encryption code in NLFSEOpCallbackPreWrite(). As a result, the
file on disk is not encrypted.
The problem only happens to some files in a directory, but not other
files in the same directory. It also only happens to some Perforce
revisions of a file, but not to other revisions of the same file.
(E.g. the problem happens to Makefile#6 (518 bytes), but not
Makefile#7 (527 bytes).) It is 100% reproducible for the same files
and revisions that experience the problem. It happens even when the
user retrieves the file one at a time.
I used Process Monitor v2.91 to watch the IO on the local file. For
files/revisions that don’t have the problem, Process Monitor shows
FASTIO_ACQUIRE_FOR_CC_FLUSH and FASTIO_RELEASE_FOR_CC_FLUSH for the
file. For files/revisions that have the problem, Process Monitor
doesn’t display such operations. However, I’m not sure whether this
is the cause of the problem, or the effect of some bad code in my
filter driver.
Any suggestion on how I can debug this? Thanks in advance for any
info!
— Allen Yuen
This email has been inspected by NextLabs’ Outlook Policy Enforcerhttp: to ensure compliance
- --------------------------------------------------------------------
STATEMENT OF CONFIDENTIALITY
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. No representation is made on its accuracy or completeness of the information contained in this electronic message. Certain assumptions may have been made in the preparation of this material as at this date, and are subject to change without notice. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. Please reply to the sender at NextLabs Inc and destroy all copies of this message and any attachments from your system. ======================================================================</http:>