Access violation while calling IoVolumeDeviceToDosName

NTFSD
1

I’m writing a mini-filter and was trying to get the dos name for a volume,
using the volume’s opaque pointer (PFLT_VOLUME) as a starting point.

I call the following code from the InstanceSetup callback, using
PCFLT_RELATED_OBJECTS->Volume as the volume’s opaque pointer, and
calling FltGetDeviceObject() to get the volume device object.

PFLT_VOLUME volume;
NTSTATUS status;
PDEVICE_OBJECT pVolumeDeviceObject;
UNICODE_STRING dosDeviceName;

if(volume == NULL)
{
return NULL;
}

status = FltGetDeviceObject(volume, &pVolumeDeviceObject);
if(!NT_SUCCESS(status))
{
return NULL;
}

RtlInitUnicodeString(&dosDeviceName, NULL);
status = IoVolumeDeviceToDosName(pVolumeDeviceObject, &dosDeviceName);

This code access violates and crashes during execution of the last line. The
stack trace is below.

This stack trace is remarkably similar to this one I found on Google:
http://www.dumpanalysis.org/blog/index.php/2009/04/15/null-data-pointer-pattern-case-study/

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx
referenced memory at 0x%08lx. The memory could not be %s.

FAULTING_IP:
nt!IoIsOperationSynchronous+e
804ef920 f6412c02 test byte ptr [ecx+2Ch],2

EXCEPTION_RECORD: f7a3e6c0 – (.exr 0xfffffffff7a3e6c0)
ExceptionAddress: 804ef920 (nt!IoIsOperationSynchronous+0x0000000e)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 0000002c
Attempt to read from address 0000002c

CONTEXT: f7a3e3bc – (.cxr 0xfffffffff7a3e3bc)
eax=85f95008 ebx=85ec5498 ecx=00000000 edx=85f95008 esi=8648e030
edi=85ec5b08
eip=804ef920 esp=f7a3e788 ebp=f7a3e788 iopl=0 nv up ei ng nz na po
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010282
nt!IoIsOperationSynchronous+0xe:
804ef920 f6412c02 test byte ptr [ecx+2Ch],2
ds:0023:0000002c=??
Resetting default scope

PROCESS_NAME: System

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced
memory at 0x%08lx. The memory could not be %s.

EXCEPTION_PARAMETER1: 00000000

EXCEPTION_PARAMETER2: 0000002c

READ_ADDRESS: 0000002c

FOLLOWUP_IP:
MyClientCache32!fsUtilsGetDriveLetterForVolume+d1
f7b8965b 53 push ebx

BUGCHECK_STR: 0x7E

DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE

LAST_CONTROL_TRANSFER: from f72d5612 to 804ef920

STACK_TEXT:
f7a3e788 f72d5612 85f95008 f7a3e7ac 804ef19f nt!IoIsOperationSynchronous+0xe
f7a3e794 804ef19f 86467020 85f95008 864d2a80 Ntfs!NtfsFsdDispatch+0xe
f7a3e7a4 f7353459 f7a3e7e8 804ef19f 864689e8 nt!IopfCallDriver+0x31
f7a3e7ac 804ef19f 864689e8 85f95008 85f95008 sr!SrPassThrough+0x31
f7a3e7bc f736909e 00000000 864d3330 85ec5b08 nt!IopfCallDriver+0x31
f7a3e7e8 804ef19f 85ec5b08 85f95008 00000200 fltmgr!FltpDispatch+0x152
f7a3e7f8 804f3f0f f7b8975a f7b89704 f7b897dc nt!IopfCallDriver+0x31
f7a3ea48 f7b8965b 85ec5b08 f7a3ea64 80536146 nt!IoVolumeDeviceToDosName+0x89
f7a3ea70 f7b89a74 85ec5498 85ec5498 f7a3eab4
MyClientCache32!fsUtilsGetDriveLetterForVolume+0xd1
f7a3ea80 f73768ff f7a3ea9c 00000001 00000008
MyClientCache32!InstanceSetup+0x38
f7a3eab4 f7376e86 85fbb008 00000001 8054b968
fltmgr!FltpDoInstanceSetupNotification+0x4b
f7a3eb14 f7377211 8626a2b8 85ec5498 00000001 fltmgr!FltpInitInstance+0x272
f7a3eb84 f737731c 8626a2b8 85ec5498 00000001
fltmgr!FltpCreateInstanceFromName+0x295
f7a3ebec f737e1ed 8626a2b8 85ec5498 00000001
fltmgr!FltpEnumerateRegistryInstances+0xf4
f7a3ec38 f737d27f 8626a2b8 f7b89d0a f7b89d08
fltmgr!FltpDoVolumeNotificationForNewFilter+0xad
f7a3ec6c f7b89bd3 8626a2b8 862746a0 e1c82588 fltmgr!FltStartFiltering+0x35
f7a3ec84 80581377 862746a0 85ecd000 00000000
MyClientCache32!DriverEntry+0x4d
f7a3ed54 80581487 80000284 00000001 00000000 nt!IopLoadDriver+0x66d
f7a3ed7c 8053879d 80000284 00000000 865c2640 nt!IopLoadUnloadDriver+0x45
f7a3edac 805cff62 f63c2cf4 00000000 00000000 nt!ExpWorkerThread+0xef
f7a3eddc 8054612e 805386ae 00000001 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

2

You probably need to call FltGetDiskDeviceObject …

–
Rod Widdowson
Consulting Partner
Steading System Software LLP
+44 1368 850217 +1 508 915 4790

3

I tried that too but then it returns an empty string from
IoVolumeDeviceToDosName()

On Mon, Oct 4, 2010 at 4:05 AM, Rod Widdowson wrote:

> You probably need to call FltGetDiskDeviceObject …
>
> –
> Rod Widdowson
> Consulting Partner
> Steading System Software LLP
> +44 1368 850217 +1 508 915 4790
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars
> (including our new fs mini-filter seminar) 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
>

4

What volume is it? Please use “!fltkd.volume” command to see if volume
letter has even been assigned.

If you support XP, IoVolumeDeviceToDosName shouldn’t be called from
InstanceSetup callback, but from workitem (with referenced input volume/disk
objects).

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Deepak Kumar
Sent: Monday, October 04, 2010 2:30 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Access violation while calling IoVolumeDeviceToDosName

I tried that too but then it returns an empty string from
IoVolumeDeviceToDosName()

On Mon, Oct 4, 2010 at 4:05 AM, Rod Widdowson
wrote:

You probably need to call FltGetDiskDeviceObject …

–
Rod Widdowson
Consulting Partner
Steading System Software LLP
+44 1368 850217 +1 508 915 4790

—
NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) 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

— NTFSD is sponsored by OSR For our schedule of debugging and file system
seminars (including our new fs mini-filter seminar) 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

5

You need to call it with FltGetDiskDeviceObject.

The bugcheck you are seeing is because you are sending an IRP into NTFS and
I’m guessing NTFS is trying to see if the FO is synchronous:

Your bugcheck analysis says it’s trying to execute this:

nt!IoIsOperationSynchronous+0xe:

804ef920 f6412c02 test byte ptr [ecx+2Ch],2
ds:0023:0000002c=??

So on XP we have

0: kd> dt nt!_FILE_OBJECT

.

+0x02c Flags : Uint4B

.

And from wdm.h we have

#define FO_SYNCHRONOUS_IO 0x00000002

So what I’m guessing happens is that IoVolumeDeviceToDosName sends an IRP to
the device you specify and because you used FltGetDeviceObject instead of
FltGetDiskDeviceObject, the IRP was sent to NTFS. It also seems that the
IRP->FileObject is NULL, and then IoIsOperationSynchronous tries to
dereference a NULL FILE_OBJECT to check its flags.

Now, it is possible that a volume doesn’t have a dos device name. Run
mountvol.exe on the command line and see if the volume you’re interested in
does have a dos device name associated with it.

Thanks,

Alex.