In my filter driver on NT4, I process new mount requests by first trying to
find the drive letter associated with the deviceobject that’s being mounted.
The code does this by calling IoGetDeviceObjectPointer() with a device name
string of “??\C:”, “??\D:”, … until it finds the drive letter symbolic
link that matches the device object in question.
Most of the time this works. However, sometimes the call to
IoGetDeviceObjectPointer() fails with a STATUS_OBJECT_PATH_NOT_FOUND
(0xc000003a), even though there really IS an existing symbolic link to the
device. For instance ??\G: -> \Device\HarddiskDmVolumes\MyGroup\Volume1
exists, yet I get an error when calling IoGetDeviceObjectPointer() with
“??\G:” as the device name.
Not only does the symbolic link exist (proven by using WinObj), but the
device it points to exists, and is accessible from user mode. Doing "dir
G:" gives me good results.
Has anyone ever seen this type of failure, or would hazard a guess about its
cause?
Carl Appellof
I don’t think you can use the ??\ prefix here. Try using \DosDevices\
No kidding… /ted
-----Original Message-----
From: Carl Appellof [mailto:xxxxx@nospam.veritas.com]
Sent: Wednesday, September 11, 2002 3:29 PM
To: File Systems Developers
Subject: [ntfsd] IoGetDeviceObjectPointer failure
In my filter driver on NT4, I process new mount requests by first trying to
find the drive letter associated with the deviceobject that’s being mounted.
The code does this by calling IoGetDeviceObjectPointer() with a device name
string of “??\C:”, “??\D:”, … until it finds the drive letter symbolic
link that matches the device object in question.
Most of the time this works. However, sometimes the call to
IoGetDeviceObjectPointer() fails with a STATUS_OBJECT_PATH_NOT_FOUND
(0xc000003a), even though there really IS an existing symbolic link to the
device. For instance ??\G: -> \Device\HarddiskDmVolumes\MyGroup\Volume1
exists, yet I get an error when calling IoGetDeviceObjectPointer() with
“??\G:” as the device name.
Not only does the symbolic link exist (proven by using WinObj), but the
device it points to exists, and is accessible from user mode. Doing "dir
G:" gives me good results.
Has anyone ever seen this type of failure, or would hazard a guess about its
cause?
Carl Appellof
You are currently subscribed to ntfsd as: xxxxx@livevault.com
To unsubscribe send a blank email to %%email.unsub%%
“Ted Hess” wrote in message news:xxxxx@ntfsd…
>
> I don’t think you can use the ??\ prefix here. Try using \DosDevices<br>>
> No kidding… /ted
>
Bzzt! Wrong answer, Ted. I lied. The real code DOES use \DosDevices, which
is simply a symbolic link to ??\ in NT4. I’ve tried both prefixes with the
same effect. But thanks for trying.
Carl
“Carl Appellof” wrote in message
news:xxxxx@ntfsd…
>
…
>
> Most of the time this works. However, sometimes the call to
> IoGetDeviceObjectPointer() fails with a STATUS_OBJECT_PATH_NOT_FOUND
> (0xc000003a), even though there really IS an existing symbolic link to the
> device. For instance ??\G: -> \Device\HarddiskDmVolumes\MyGroup\Volume1
> exists, yet I get an error when calling IoGetDeviceObjectPointer() with
> “??\G:” as the device name.
>
> Not only does the symbolic link exist (proven by using WinObj), but the
> device it points to exists, and is accessible from user mode. Doing "dir
> G:" gives me good results.
>
> Has anyone ever seen this type of failure, or would hazard a guess about
its
> cause?
>
Well, I found a surprising answer to my problem. Apparently
IoGetDeviceObjectPointer() is case-sensitive in some ways. The REAL object
manager device name in my case was
\Device\HarddiskDmVolumes\MYGROUP\Volume1
while the symbolic link \DosDevices\G: pointed to
\Device\HarddiskDmVolumes\MyGroup\Volume1
On NT4 at least, IoGetDeviceObjectPointer() returned a
STATUS_OBJECT_PATH_NOT_FOUND when looking up \DosDevices\G:, indicating some
part of the path name was not found (duh!) Looks like it did a
case-sensitive comparison.
The surprising thing to me is that regular I/O to G:\ works fine, so the
main I/O manager object path parsing code seems to be case IN-sensitive. Go
figure.
Carl
IIRC, IoGetDeviceObjectPointer() works by sending an IRP_MJ_CREATE. Note that create IRP’s are case sensitive by default. Case insensitive behavior is requested by specifying OBJ_CASE_INSENSITIVE to InitializeObjectAttributes. IoGetDeviceObjectPointer() is probably a trivial function to re-implement with case insensitive behavior.
-----Original Message-----
From: Carl Appellof [mailto:xxxxx@nospam.veritas.com]
Sent: Wednesday, September 11, 2002 6:23 PM
To: File Systems Developers
Subject: [ntfsd] Re: IoGetDeviceObjectPointer failure
“Carl Appellof” wrote in message
news:xxxxx@ntfsd…
>
…
>
> Most of the time this works. However, sometimes the call to
> IoGetDeviceObjectPointer() fails with a STATUS_OBJECT_PATH_NOT_FOUND
> (0xc000003a), even though there really IS an existing symbolic link to the
> device. For instance ??\G: -> \Device\HarddiskDmVolumes\MyGroup\Volume1
> exists, yet I get an error when calling IoGetDeviceObjectPointer() with
> “??\G:” as the device name.
>
> Not only does the symbolic link exist (proven by using WinObj), but the
> device it points to exists, and is accessible from user mode. Doing "dir
> G:" gives me good results.
>
> Has anyone ever seen this type of failure, or would hazard a guess about
its
> cause?
>
Well, I found a surprising answer to my problem. Apparently
IoGetDeviceObjectPointer() is case-sensitive in some ways. The REAL object
manager device name in my case was
\Device\HarddiskDmVolumes\MYGROUP\Volume1
while the symbolic link \DosDevices\G: pointed to
\Device\HarddiskDmVolumes\MyGroup\Volume1
On NT4 at least, IoGetDeviceObjectPointer() returned a
STATUS_OBJECT_PATH_NOT_FOUND when looking up \DosDevices\G:, indicating some
part of the path name was not found (duh!) Looks like it did a
case-sensitive comparison.
The surprising thing to me is that regular I/O to G:\ works fine, so the
main I/O manager object path parsing code seems to be case IN-sensitive. Go
figure.
Carl
—
You are currently subscribed to ntfsd as: xxxxx@inin.com
To unsubscribe send a blank email to %%email.unsub%%