I am working on a virtual drive with its own file system driver. I Have mounted the volume. it is accessible from CMD and but in explorer it is giving error F:\ not accessible. Access Denied!! I don’t know why. (There is only one volume and one disk device that my driver is currently handling.)
Other then that i am facing bombarding of the device control request of IOCTL_MOUNTDEV_QUERY_DEVICE_NAME and I am completing this request with following code.
case IOCTL_MOUNTDEV_QUERY_DEVICE_NAME:
{
PMOUNTDEV_NAME PtrMountedDeviceName;
UNICODE_STRING DeviceName;
PtrMountedDeviceName = Irp->AssociatedIrp.SystemBuffer;
RtlInitUnicodeString(&ProcessedIOCTLStr, L"IOCTL_MOUNTDEV_QUERY_DEVICE_NAME");
if (OutBufferLen < sizeof(MOUNTDEV_NAME))
{
Status = STATUS_INVALID_PARAMETER;
break;
}
RtlInitUnicodeString(&DeviceName, L"\Device\AFSDisk");
PtrMountedDeviceName->NameLength = DeviceName.Length;
if (OutBufferLenNameLength)
{
Information = sizeof(MOUNTDEV_NAME);
//RtlCopyMemory(PtrMountedDeviceName->Name, DeviceName.Buffer,OutBufferLen);
Status = STATUS_BUFFER_OVERFLOW;
break;
}
RtlCopyMemory(PtrMountedDeviceName->Name, DeviceName.Buffer, PtrMountedDeviceName->NameLength);
Status = STATUS_SUCCESS;
Information = sizeof(USHORT)+PtrMountedDeviceName->NameLength;
break;
}
Can any one suggest why windows explorer behaving like this.I used the code that is provided in NT insider to complete IOCTL_MOUNTDEV_QUERY_DEVICE_NAME.
thanks in Advance.
Hi,
Maybe you need to take care the case if the output is too small with the
description on MSDN,
If the output buffer is too small to hold the device name, the mount
manager client must set the *Information*field to *sizeof*(MOUNTDEV_NAME)
and the *Status* field to STATUS_BUFFER_OVERFLOW. In addition, the mount
manager client fills in the NameLength member of the *MOUNTDEV_NAME*
https:
structure.
Regards,
Douglas C
On Sun, Feb 1, 2015 at 9:26 PM, wrote:
> I am working on a virtual drive with its own file system driver. I Have
> mounted the volume. it is accessible from CMD and but in explorer it is
> giving error F:\ not accessible. Access Denied!! I don’t know why. (There
> is only one volume and one disk device that my driver is currently
> handling.)
>
> Other then that i am facing bombarding of the device control request of
> IOCTL_MOUNTDEV_QUERY_DEVICE_NAME and I am completing this request with
> following code.
> case IOCTL_MOUNTDEV_QUERY_DEVICE_NAME:
> {
> PMOUNTDEV_NAME
> PtrMountedDeviceName;
> UNICODE_STRING DeviceName;
> PtrMountedDeviceName =
> Irp->AssociatedIrp.SystemBuffer;
>
> RtlInitUnicodeString(&ProcessedIOCTLStr,
> L"IOCTL_MOUNTDEV_QUERY_DEVICE_NAME");
> if (OutBufferLen <
> sizeof(MOUNTDEV_NAME))
> {
> Status =
> STATUS_INVALID_PARAMETER;
> break;
> }
> RtlInitUnicodeString(&DeviceName,
> L"\Device\AFSDisk");
>
> PtrMountedDeviceName->NameLength =
> DeviceName.Length;
> if
> (OutBufferLenNameLength)
> {
> Information =
> sizeof(MOUNTDEV_NAME);
>
> //RtlCopyMemory(PtrMountedDeviceName->Name, DeviceName.Buffer,OutBufferLen);
> Status =
> STATUS_BUFFER_OVERFLOW;
> break;
> }
>
> RtlCopyMemory(PtrMountedDeviceName->Name, DeviceName.Buffer,
> PtrMountedDeviceName->NameLength);
> Status = STATUS_SUCCESS;
> Information =
> sizeof(USHORT)+PtrMountedDeviceName->NameLength;
> break;
> }
>
>
> Can any one suggest why windows explorer behaving like this.I used the
> code that is provided in NT insider to complete
> IOCTL_MOUNTDEV_QUERY_DEVICE_NAME.
>
> thanks in Advance.
>
>
> —
> NTFSD is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> 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
></https:>
Notice that it has done in the block … Please read the code…
if (OutBufferLenNameLength)
{
Information = sizeof(MOUNTDEV_NAME);
//RtlCopyMemory(PtrMountedDeviceName->Name,
DeviceName.Buffer,OutBufferLen);
Status = STATUS_BUFFER_OVERFLOW;
break;
}
Hi,
Is it possible that don’t need to return any status except
STATUS_BUFFER_OVERFLOW if buffer is too small? Maybe someone who sends the
IOCTL_MOUNTDEV_QUERY_DEVICE_NAME to you but it doesn’t take other error
status, then it relinquishs.
Another case, in the case (OutBufferLen < sizeof(MOUNTDEV_NAME)), it needs
to set Information = sizeof(MOUNTDEV_NAME) and use STATUS_BUFFER_TOO_SMALL
instead.
I am not sure with above, but if it was I, I will have it a try 
Regards,
Douglas C
On Sun, Feb 1, 2015 at 10:17 PM, wrote:
> Notice that it has done in the block … Please read the code…
>
> if (OutBufferLenNameLength)
> {
> Information =
> sizeof(MOUNTDEV_NAME);
>
> //RtlCopyMemory(PtrMountedDeviceName->Name,
> DeviceName.Buffer,OutBufferLen);
> Status =
> STATUS_BUFFER_OVERFLOW;
> break;
> }
>
> —
> NTFSD is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> 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
>
Changed code is here but it is not working if anyone having any idea why it is getting error please tell me…
PMOUNTDEV_NAME PtrMountedDeviceName;
UNICODE_STRING DeviceName;
PtrMountedDeviceName = Irp->AssociatedIrp.SystemBuffer;
RtlInitUnicodeString(&ProcessedIOCTLStr, L"IOCTL_MOUNTDEV_QUERY_DEVICE_NAME");
RtlInitUnicodeString(&DeviceName, L"\Device\AFSDisk");
PtrMountedDeviceName->NameLength = DeviceName.Length;
if (PtrIoStackLocation->Parameters.DeviceIoControl.OutputBufferLength {
Information = sizeof(MOUNTDEV_NAME);
Status = STATUS_BUFFER_TOO_SMALL;
break;
}
if (PtrIoStackLocation->Parameters.DeviceIoControl.OutputBufferLengthNameLength)
{
Information = sizeof(MOUNTDEV_NAME);
Status = STATUS_BUFFER_OVERFLOW;
break;
}
RtlCopyMemory(PtrMountedDeviceName->Name, DeviceName.Buffer, PtrMountedDeviceName->NameLength);
Status = STATUS_SUCCESS;
Information = sizeof(USHORT)+PtrMountedDeviceName->NameLength;
break;
This is the DebugTrace(Device 2 is for Disk Device)
Create : Open For Other Device 2
CREATE NULL 0 0x0000000000
CLEAN (null) 0 0x0000000000
DISKCNTRL (null) 4 0x0080000005
DISKCNTRL (null) 32 0x0000000000
CLOSE (null) 0 0x0000000000
Create : Open For Other Device 2
CREATE NULL 0 0x0000000000
DISKCNTRL (null) 32 0x0000000000
CLEAN (null) 0 0x0000000000
CLOSE (null) 0 0x0000000000
Create : Open For Other Device 2
CREATE NULL 0 0x0000000000
CLEAN (null) 0 0x0000000000
DISKCNTRL (null) 4 0x0080000005
DISKCNTRL (null) 32 0x0000000000
CLOSE (null) 0 0x0000000000
CLEAN \ 0 0x0000000000
CLOSE \ 0 0x0000000000
Create : Open For Other Device 2
CREATE NULL 0 0x0000000000
DISKCNTRL (null) 32 0x0000000000
CLEAN (null) 0 0x0000000000
CLOSE (null) 0 0x0000000000
Create : Open For Other Device 2
CREATE NULL 0 0x0000000000
CLEAN (null) 0 0x0000000000
DISKCNTRL (null) 4 0x0080000005
DISKCNTRL (null) 32 0x0000000000
CLOSE (null) 0 0x0000000000
Create : Open For Other Device 2
CREATE NULL 0 0x0000000000
DISKCNTRL (null) 32 0x0000000000
CLEAN (null) 0 0x0000000000
CLOSE (null) 0 0x0000000000
Create : Open For Other Device 2
CREATE NULL 0 0x0000000000
CLEAN (null) 0 0x0000000000
DISKCNTRL (null) 4 0x0080000005
DISKCNTRL (null) 32 0x0000000000
CLOSE (null) 0 0x0000000000
Same pattern is noticed when explorer is opened and drive is still inaccessible…Please suggest solution…
> . Access Denied!! I don’t know why.
I suggest you find out. What does filespy say ? Which operations are
returning ACCESS denied? When you locate the operation set a breakpoint and
see why you are returning it.
As for the IOCTL issue, it could well be that fixing the access denied will
cure it. Consider a codepath in explorer which could go:
status = getDeviceName()
if (!SUCCEEDED(status)) break;
status = doSomethingWhichYouFailAccessDenied()
if (!SUCCEEDED(status)) break;
CacheDeviceName()’
Explorer is not noted amongst file system people for the apparent
rationality of its behaviour so that above would not be exceptional.
/R
@rod widdowson thanks for filespy
Ok problem resolved…
-
I completed device request IOCTL_MOUNTDEV_QUERY_DEVICE_NAME with STATUS_INVALID_DEVICE_REQUEST that stoped bombarding.
-
The root directory enumration function was returning STATUS_SUCCESS instead of STATUS_NO_MORE_FILES.Due to that it was making request again and again. And result was drive is not accessible.
> @rod widdowson thanks for filespy
Its Ladislav we need to thank for that (and filetest and bellavista and…)
/R