IRP_MN_MOUNT_VOLUME and ObQueryNameString

NTFSD
1

Hi all,

My filter driver attaches itself via the IRP_MN_MOUNT_VOLUME call. I’ve
used ObQueryNameString on the DeviceObject sent in the call parameters to
get the volume guid and I use this to identify which volumes to filter.

My IRP_MN_MOUNT_VOLUME handler look like this:

unsigned char nameInfo[(512];

OBJECT_NAME_INFORMATION * pNameInfo =
reinterpret_cast<object_name_information>
(nameInfo);

ULONG nLength = 0;

ObQueryNameString(
pCurrentStackLocation->Parameters.
MountVolume.DeviceObject,
pNameInfo, sizeof(nameInfo),
&nLength );

bool const bMapDrive =
( pNameInfo->Name.Buffer ) ?
TestForDriveToMap( pNameInfo->Name ) : false;

if ( bMapDrive )
{
// Forward the original request

if ( STATUS_SUCCESS == rc )
// Attach the filter to the target device
}

This all worked fine in Windows 2000 but fails in XP, with
ObQueryNameString returning an empty string.

Can any one tell me if this should work in XP. If not, how can I determine
which volume is being mounted?

Many thanks,

Andy</object_name_information>

2

Andy,

The I suspect the reason that this is not working on XP is that
pCurrentStackLocation->Parameters.MountVolume.DeviceObject contains a
pointer to VolSnap.sys by default (the MS shadow copy driver attaches to the
logical volume). This device is unnamed. What I think you mean to do is
query Vpb->RealDevice.

Note that VolSnap.sys is new to XP, which is why the code will work fine on
W2K.

-----Original Message-----
From: xxxxx@ArmourSoft.com [mailto:xxxxx@ArmourSoft.com]
Sent: Wednesday, March 20, 2002 10:20 AM
To: File Systems Developers
Subject: [ntfsd] IRP_MN_MOUNT_VOLUME and ObQueryNameString

Hi all,

My filter driver attaches itself via the IRP_MN_MOUNT_VOLUME call. I’ve used
ObQueryNameString on the DeviceObject sent in the call parameters to get the
volume guid and I use this to identify which volumes to filter.

My IRP_MN_MOUNT_VOLUME handler look like this:

unsigned char nameInfo[(512];

OBJECT_NAME_INFORMATION * pNameInfo =
reinterpret_cast<object_name_information>
(nameInfo);

ULONG nLength = 0;

ObQueryNameString(
pCurrentStackLocation->Parameters.
MountVolume.DeviceObject,
pNameInfo, sizeof(nameInfo),
&nLength );

bool const bMapDrive =
( pNameInfo->Name.Buffer ) ?
TestForDriveToMap( pNameInfo->Name ) : false;

if ( bMapDrive )
{
// Forward the original request

if ( STATUS_SUCCESS == rc )
// Attach the filter to the target device
}

This all worked fine in Windows 2000 but fails in XP, with ObQueryNameString
returning an empty string.

Can any one tell me if this should work in XP. If not, how can I determine
which volume is being mounted?

Many thanks,

Andy

—
You are currently subscribed to ntfsd as: xxxxx@stbernard.com To
unsubscribe send a blank email to %%email.unsub%%</object_name_information>

3

Hi Chris,

Yep, this was the solution.

Many, many, many thanks.

4

Hi. I’m using ObQueryNameString like this.

{
ULONG ReturnLength;
WCHAR Buffer[256];
OBJECT_NAME_INFORMATION ObjectNameInfo;
ObjectNameInfo.Name.MaximumLength = 256*sizeof(WCHAR);
ObjectNameInfo.Name.Buffer = Buffer;
ObQueryNameString(pDeviceObject, &ObjectNameInfo, 256*sizeof(WCHAR), &ReturnLength);
}

And I get a blue screen (Exception not handle). I don’t know why this happens but I don’t think it is the IRQL. I tried allocating the buffer in non paged memory and the same thing happened.

5

Your problem is because the ObQueryNameString routine sets up the unicode string (not you) and it assumes the buffer for the Unicode string is immediately after the OBJECT_NAME_INFORMATION structure. You need to do this:

{
ULONG ReturnLength;
UCHAR Buffer[sizeof(OBJECT_NAME_INFORMATION)+(256*sizeof(WCHAR))];
POBJECT_NAME_INFORMATION ObjectNameInfo = (POBJECT_NAME_INFORMATION)Buffer;

ObQueryNameString(pDeviceObject, ObjectNameInfo, sizeof(Buffer), &ReturnLength);
}

Neal Christiansen

This posting is provided “AS IS” with no warranties, and confers no rights.

-----Original Message-----
From: Ratmil Torres [mailto:ratmil@ec.minbas.cu]
Sent: Tuesday, March 26, 2002 05:19 PM
To: File Systems Developers
Subject: [ntfsd] ObQueryNameString

Hi. I’m using ObQueryNameString like this.
?
?{
???ULONG ReturnLength;
???WCHAR Buffer[256];
???OBJECT_NAME_INFORMATION ObjectNameInfo;
???ObjectNameInfo.Name.MaximumLength = 256*sizeof(WCHAR);
???ObjectNameInfo.Name.Buffer = Buffer;
???ObQueryNameString(pDeviceObject,?&ObjectNameInfo, 256*sizeof(WCHAR), &ReturnLength);
??}
?
And I get a blue screen (Exception not handle). I don’t know why this happens but I don’t think it is the IRQL. I tried allocating the buffer in non paged memory and?the same thing happened.?

You are currently subscribed to ntfsd as: xxxxx@Windows.Microsoft.com
To unsubscribe send a blank email to %%email.unsub%%

6

THANK YOU VERY MUCH.
----- Original Message -----
From: “Neal Christiansen”
To: “File Systems Developers”
Sent: Wednesday, March 27, 2002 4:58 PM
Subject: [ntfsd] RE: ObQueryNameString

Your problem is because the ObQueryNameString routine sets up the
unicode string (not you) and it assumes the buffer for the Unicode
string is immediately after the OBJECT_NAME_INFORMATION structure. You
need to do this:

{
ULONG ReturnLength;
UCHAR Buffer[sizeof(OBJECT_NAME_INFORMATION)+(256sizeof(WCHAR))];
POBJECT_NAME_INFORMATION ObjectNameInfo =
(POBJECT_NAME_INFORMATION)Buffer;

ObQueryNameString(pDeviceObject, ObjectNameInfo, sizeof(Buffer),
&ReturnLength);
}

Neal Christiansen

This posting is provided “AS IS” with no warranties, and confers no
rights.

-----Original Message-----
From: Ratmil Torres [mailto:ratmil@ec.minbas.cu]
Sent: Tuesday, March 26, 2002 05:19 PM
To: File Systems Developers
Subject: [ntfsd] ObQueryNameString

Hi. I’m using ObQueryNameString like this.

{
ULONG ReturnLength;
WCHAR Buffer[256];
OBJECT_NAME_INFORMATION ObjectNameInfo;
ObjectNameInfo.Name.MaximumLength = 256sizeof(WCHAR);
ObjectNameInfo.Name.Buffer = Buffer;
ObQueryNameString(pDeviceObject, &ObjectNameInfo, 256*sizeof(WCHAR),
&ReturnLength);
}

And I get a blue screen (Exception not handle). I don’t know why this
happens but I don’t think it is the IRQL. I tried allocating the buffer
in non paged memory and the same thing happened.
—
You are currently subscribed to ntfsd as: xxxxx@Windows.Microsoft.com
To unsubscribe send a blank email to %%email.unsub%%

—
You are currently subscribed to ntfsd as: ratmil@ec.minbas.cu
To unsubscribe send a blank email to %%email.unsub%%

7

Hello, All!

Why ObQueryNameString may freeze the thread?

Thanks.
Eugene.

8

It depends on what type of object do you query.
Please tell us more information.
Paul

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Eugene Lomovsky
Sent: Friday, April 12, 2002 2:14 PM
To: File Systems Developers
Subject: [ntfsd] ObQueryNameString

Hello, All!

Why ObQueryNameString may freeze the thread?

Thanks.
Eugene.

You are currently subscribed to ntfsd as: xxxxx@compelson.com
To unsubscribe send a blank email to %%email.unsub%%

9

The thread is probably waiting for a lock of some sort. In the debugger,
you can look at the thread using the “!thread” command and the address of
the ETHREAD structure. You can find all of the threads in the system by
using the “!process 0 7” command.

The stack trace of the “frozen” thread will tell you for what it is waiting.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Hope to see you at the next OSR file systems class October 7, 2002!

-----Original Message-----
From: Eugene Lomovsky [mailto:xxxxx@mail.ru]
Sent: Friday, April 12, 2002 8:14 AM
To: File Systems Developers
Subject: [ntfsd] ObQueryNameString

Hello, All!

Why ObQueryNameString may freeze the thread?

Thanks.
Eugene.

You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to %%email.unsub%%

10

RE: [ntfsd] ObQueryNameStringHi, Pavel.

It is a FileObject. I call ObQueryNameString in CleanUp dispatcher. I saw
such behavior only for one file (\NTDir\Temp~) that was created (or
modified) during some installation process… Oh, all testings is done under
win2k by my file system filter, system partition is NTFS.

Thanks.
Eugene.

It depends on what type of object do you query.
Please tell us more information.

11

This will probably be some misuse of FSD resource
acquision rules. Try to follow Tony’s suggestions
and find out what lock cannot be acquired.

Note that ObQueryNameString on file objects results
in IRP_MJ_QUERY_INFORMATION/FileNameInformation call
into the FSD.

Paul

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Eugene Lomovsky
Sent: Friday, April 12, 2002 4:46 PM
To: File Systems Developers
Subject: [ntfsd] Re: ObQueryNameString

RE: [ntfsd] ObQueryNameStringHi, Pavel.

It is a FileObject. I call ObQueryNameString in CleanUp dispatcher. I saw
such behavior only for one file (\NTDir\Temp~) that was created (or
modified) during some installation process… Oh, all testings is done under
win2k by my file system filter, system partition is NTFS.

Thanks.
Eugene.

It depends on what type of object do you query.
Please tell us more information.

You are currently subscribed to ntfsd as: xxxxx@compelson.com
To unsubscribe send a blank email to %%email.unsub%%

12

This is a common problem for filter drivers trying to query the name of a file object.

IIRC, when you call ObQueryNameString for a file object, it calls the query name method on the file object type. That method is implemented by the function IopQueryName which in turn calls IopQueryXxxInformation. If the file was opened for non-overlapped IO, the default for WIN32, IopQueryXxxInformation tries to synchronize the name query–IRP_MJ_QUERY_INFORMATION–with other operations on the file object, such as the IRP_MJ_CLEANUP you are filtering. This synchronization is done by treating the KEVENT Lock field of the file object like a mutex. Because ZwClose already locked the file object prior to your filter receiving the IRP_MJ_CLEANUP, and a KEVENT has no concept of recursive acquisition, you are experiencing a deadlock in IopQueryXxxInformation when it tries to lock the file object.

I suggest you build the IRP_MJ_QUERY_INFORMATION with a FileInformationClass of FileNameInformation, and send it yourself. This will bypass acquiring the file object’s lock, and the FSD will do the necessary synchronization using its FCB resources.

-----Original Message-----
From: Eugene Lomovsky [mailto:xxxxx@mail.ru]
Sent: Friday, April 12, 2002 9:46 AM
To: File Systems Developers
Subject: [ntfsd] Re: ObQueryNameString

RE: [ntfsd] ObQueryNameStringHi, Pavel.

It is a FileObject. I call ObQueryNameString in CleanUp dispatcher. I saw
such behavior only for one file (\NTDir\Temp~) that was created (or
modified) during some installation process… Oh, all testings is done under
win2k by my file system filter, system partition is NTFS.

Thanks.
Eugene.

It depends on what type of object do you query.
Please tell us more information.

You are currently subscribed to ntfsd as: xxxxx@inin.com
To unsubscribe send a blank email to %%email.unsub%%

13

Hi, Fuller,!
You wrote on Fri, 12 Apr 2002 10:11:18 -0500:

FR> I suggest you build the IRP_MJ_QUERY_INFORMATION with a
FR> FileInformationClass of FileNameInformation, and send it yourself.
FR> This will bypass acquiring the file object’s lock, and the FSD will
FR> do the necessary synchronization using its FCB resources.

Thanks to all! I understand a problem. I’ll rewrite my code.

Eugene.

14

> Why ObQueryNameString may freeze the thread?

ObQueryNameString calls type-specific method. For file objects, this will send an IRP to the filesystem, and this path can block.

Max