STATUS_OBJECT_NAME_NOT_FOUND from ZwCreateFile()

OK, I’m grasping at straws here. I’m a novice FS driver developer, and I’m anxiously awaiting the arrival of my ifskit upgrade. In the meantime…

In the Win2K DDK docs on ZwCreateFile(), it says “The FILE_READ_DATA, FILE_WRITE_DATA, FILE_EXECUTE, and FILE_APPEND_DATA DesiredAccess flags are incompatible with creating or opening a directory file”. It also says “To open or create a directory file, as also indicated with the CreateOptions parameter, callers of ZwCreateFile can specify one or a combination of the following … FILE_LIST_DIRECTORY”. But both FILE_READ_DATA and FILE_LIST_DIRECTORY are #defined as ( 0x0001 ) in ntifs.h. If they are both the same value, how can one be OK and the other be “incompatible”?

I’m still trying to solve the problem I asked about several weeks ago. While processing an MN_QUERY_DIRECTORY request, I am opening the root directory on a different Netware volume using ZwCreateFile(). (‘Why’ is a long story that I don’t think is relevant to this issue.) When I click on ‘F:’ (my file system device) in the ‘source selections’ window in Veritas Backup Exec the resulting call to ZwCreateFile() returns STATUS_OBJECT_NAME_NOT_FOUND (0xC0000034). When I click on ‘F:’ in Windows Explorer, ZwCreateFile() succeeded, and all is well with the world. The IRQL is the same for both calls, and as far as I can tell, all the parameters passed in to the function are identical.

Can anyone give me a clue what might be causing this problem?

Jeff Nygren

> In the Win2K DDK docs on ZwCreateFile(), it says "The

FILE_READ_DATA, FILE_WRITE_DATA, FILE_EXECUTE, and
FILE_APPEND_DATA DesiredAccess flags are incompatible with
creating or opening a directory file". It also says “To open
or create a directory file, as also indicated with the
CreateOptions parameter, callers of ZwCreateFile can specify
one or a combination of the following …
FILE_LIST_DIRECTORY”. But both FILE_READ_DATA and
FILE_LIST_DIRECTORY are #defined as ( 0x0001 ) in ntifs.h. If
they are both the same value, how can one be OK and the other
be “incompatible”?

TODAY, FILE_READ_DATA and FILE_LIST_DIRECTORY may be defined to be the
same, but TOMORROW, that may not be the case. Your code should assume
they are defined differently and you will have nothing to worry about.

I’m still trying to solve the problem I asked about several
weeks ago. While processing an MN_QUERY_DIRECTORY request, I
am opening the root directory on a different Netware volume
using ZwCreateFile(). (‘Why’ is a long story that I don’t
think is relevant to this issue.) When I click on ‘F:’ (my
file system device) in the ‘source selections’ window in
Veritas Backup Exec the resulting call to ZwCreateFile()
returns STATUS_OBJECT_NAME_NOT_FOUND (0xC0000034). When I
click on ‘F:’ in Windows Explorer, ZwCreateFile() succeeded,
and all is well with the world. The IRQL is the same for both
calls, and as far as I can tell, all the parameters passed in
to the function are identical.

Can anyone give me a clue what might be causing this problem?

It sounds like a user impersonation problem to me. Are you calling
ZwCreateFile in the context of the original thread (after checking that
IRQL is PASSIVE_LEVEL, of course), and is Backup Exec running in the
context of the same user as Explorer?

Thanks.

So, as long as I’m using DesiredAccess flag ‘FILE_LIST_DIRECTORY’, this is not causing my problem.

RE: user impersonation problem
“> Are you calling ZwCreateFile in the context of the original thread…”
If you are asking ‘as opposed to starting another thread within my driver’, I have no other threads, so Yes, I’m calling in the context of the original thread.

“> and is Backup Exec running in the context of the same user as Explorer?”
I’m in way over my head, here! (Guys, no more snide ‘McDonalds’ comments, please. I’m definitely a beginner, tho’ possibly the most ‘experienced’ beginner on the planet!) How do I determine what user context each app is running in? They are (or can be) running on the same machine simultaneously.

How can I tell if this is a user impersonation problem? And if it is, what do I need to do to solve it? On the advice of another driver developer here, I tried ensuring I was in the same process as when the driver was launched.
In earlier initialization code: pMainProcess = PsGetCurrentProcess(); // Get process
Before ZwCreatFile() call: pNewProcess = PsGetCurrentProcess(); // Save new process
KeAttachProcess(pMainProcess); // Switch to original process
After ZwCreatFile() returns: KeAttachProcess(pNewProcess ); // Restore new process

This didn’t work, and generally caused the PC to spontaneously reboot. Might this be on the right track? If so, what else do I need to consider to make this work?

All of you: your advice is greatly appreciated. Please help if you can.

Thank you.

Jeff Nygren

-----Original Message-----
Subject: RE: STATUS_OBJECT_NAME_NOT_FOUND from ZwCreateFile()
From: “Nicholas Ryan”
> Date: Wed, 30 Apr 2003 13:29:56 -0700
> X-Message-Number: 22
>
> > In the Win2K DDK docs on ZwCreateFile(), it says "The
> > FILE_READ_DATA, FILE_WRITE_DATA, FILE_EXECUTE, and
> > FILE_APPEND_DATA DesiredAccess flags are incompatible with

> > they are both the same value, how can one be OK and the other
> > be “incompatible”?
>
> TODAY, FILE_READ_DATA and FILE_LIST_DIRECTORY may be defined to be the
> same, but TOMORROW, that may not be the case. Your code should assume
> they are defined differently and you will have nothing to worry about.
>
> > I’m still trying to solve the problem I asked about several
> > weeks ago. While processing an MN_QUERY_DIRECTORY request, I
> > am opening the root directory on a different Netware volume
> > using ZwCreateFile(). (‘Why’ is a long story that I don’t
> > think is relevant to this issue.) When I click on ‘F:’ (my
> > file system device) in the ‘source selections’ window in
> > Veritas Backup Exec the resulting call to ZwCreateFile()
> > returns STATUS_OBJECT_NAME_NOT_FOUND (0xC0000034). When I
> > click on ‘F:’ in Windows Explorer, ZwCreateFile() succeeded,
> > and all is well with the world. The IRQL is the same for both
> > calls, and as far as I can tell, all the parameters passed in
> > to the function are identical.
> >
> > Can anyone give me a clue what might be causing this problem?
>
> It sounds like a user impersonation problem to me. Are you calling
> ZwCreateFile in the context of the original thread (after
> checking that
> IRQL is PASSIVE_LEVEL, of course), and is Backup Exec running in the
> context of the same user as Explorer?
> ----------------------------------------------------------------------

The set of visible mapped network drives is maintained on a per-logon
session basis by the Object Manager, and the stored credentials needed
for filesystem network access is maintained on a per-logon session by
the LSA. If you’re a driver, and you want to access to the same set of
network resources as a given user, you can achieve this by via
impersonation. First, be sure you’re in the context of the desired user,
then call SeCreateClientSecurity to save the security context of the
current thread. Now you can use this context to impersonate this user in
any other thread by calling SeImpersonateClientEx.

The best way to be sure you’re saving the appropriate security context
is to have a process launched by the user call into your driver with an
IOCTL, then save the security context as part of the processing of that
IOCTL.

Is Backup Exec running as a LocalSystem, background service? If so,
that’s your problem. You can’t use LocalSystem’s security context to
access filesystem network resources of any kind.

  • Nick Ryan

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@KrollOntrack.com
Sent: Friday, May 02, 2003 7:42 AM
To: File Systems Developers
Subject: [ntfsd] RE: STATUS_OBJECT_NAME_NOT_FOUND from ZwCreateFile()

Thanks.

So, as long as I’m using DesiredAccess flag
‘FILE_LIST_DIRECTORY’, this is not causing my problem.

RE: user impersonation problem
“> Are you calling ZwCreateFile in the context of the
original thread…” If you are asking ‘as opposed to starting
another thread within my driver’, I have no other threads, so
Yes, I’m calling in the context of the original thread.

“> and is Backup Exec running in the context of the same
user as Explorer?” I’m in way over my head, here! (Guys, no
more snide ‘McDonalds’ comments, please. I’m definitely a
beginner, tho’ possibly the most ‘experienced’ beginner on
the planet!) How do I determine what user context each app is
running in? They are (or can be) running on the same machine
simultaneously.

How can I tell if this is a user impersonation problem? And
if it is, what do I need to do to solve it? On the advice of
another driver developer here, I tried ensuring I was in the
same process as when the driver was launched.
In earlier initialization code: pMainProcess =
PsGetCurrentProcess(); // Get process
Before ZwCreatFile() call: pNewProcess =
PsGetCurrentProcess(); // Save new process

KeAttachProcess(pMainProcess); // Switch to
original process
After ZwCreatFile() returns:
KeAttachProcess(pNewProcess ); // Restore new process

This didn’t work, and generally caused the PC to
spontaneously reboot. Might this be on the right track? If
so, what else do I need to consider to make this work?

All of you: your advice is greatly appreciated. Please help
if you can.

Thank you.

Jeff Nygren

> -----Original Message-----
> Subject: RE: STATUS_OBJECT_NAME_NOT_FOUND from ZwCreateFile()
> From: “Nicholas Ryan”
> > Date: Wed, 30 Apr 2003 13:29:56 -0700
> > X-Message-Number: 22
> >
> > > In the Win2K DDK docs on ZwCreateFile(), it says "The
> > > FILE_READ_DATA, FILE_WRITE_DATA, FILE_EXECUTE, and
> > > FILE_APPEND_DATA DesiredAccess flags are incompatible with
> …
> > > they are both the same value, how can one be OK and the other
> > > be “incompatible”?
> >
> > TODAY, FILE_READ_DATA and FILE_LIST_DIRECTORY may be
> defined to be the
> > same, but TOMORROW, that may not be the case. Your code
> should assume
> > they are defined differently and you will have nothing to
> worry about.
> >
> > > I’m still trying to solve the problem I asked about several
> > > weeks ago. While processing an MN_QUERY_DIRECTORY request, I
> > > am opening the root directory on a different Netware volume
> > > using ZwCreateFile(). (‘Why’ is a long story that I don’t
> > > think is relevant to this issue.) When I click on ‘F:’ (my
> > > file system device) in the ‘source selections’ window in
> > > Veritas Backup Exec the resulting call to ZwCreateFile()
> > > returns STATUS_OBJECT_NAME_NOT_FOUND (0xC0000034). When I
> > > click on ‘F:’ in Windows Explorer, ZwCreateFile() succeeded,
> > > and all is well with the world. The IRQL is the same for both
> > > calls, and as far as I can tell, all the parameters passed in
> > > to the function are identical.
> > >
> > > Can anyone give me a clue what might be causing this problem?
> >
> > It sounds like a user impersonation problem to me. Are you calling
> > ZwCreateFile in the context of the original thread (after checking
> > that IRQL is PASSIVE_LEVEL, of course), and is Backup Exec
> running in
> > the context of the same user as Explorer?
> >
> ----------------------------------------------------------------------
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@nryan.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

“Nicholas Ryan” wrote in message news:xxxxx@ntfsd…
>
> TODAY, FILE_READ_DATA and FILE_LIST_DIRECTORY may be defined to be the
> same, but TOMORROW, that may not be the case. Your code should assume
> they are defined differently and you will have nothing to worry about.
>

Changing those definitions to be different would sure destroy binary
compatibility of old applications! Might that be MS’s sly way of getting us
all to upgrade to Visual Studio.NET and recompile all applications that
have worked since NT 3.51 ?-)

Carl