I apologize in advance if this is a stupid question. This is my first
windows driver.
The following ZwCreateFile call always returns STATUS_OBJECT_NAME_NOT_FOUND
or STATUS_OBJECT_PATH_NOT_FOUND. For example, when FileName = “\WINDOWS” I
get STATUS_OBJECT_NAME_NOT_FOUND and when FileName =
“\WINDOWS\SYSTEM32\NTDLL.DLL” I get STATUS_OBJECT_PATH_NOT_FOUND. Both
paths definitely exist on the volume I’m attached to.
This code is called from my dispatch routine for a MJ_CREATE, not the
completion routine, so it should be at passive irq level. Can someone tell
me what I’m doing wrong?
HANDLE fileHandle;
OBJECT_ATTRIBUTES attributes;
IO_STATUS_BLOCK statusBlock;
FILE_ATTRIBUTE_TAG_INFORMATION fileAttrTagInfo;
InitializeObjectAttributes( &attributes, FileName,
OBJ_KERNEL_HANDLE|OBJ_CASE_INSENSITIVE, NULL, NULL);
status = ZwCreateFile( &fileHandle, FILE_READ_ATTRIBUTES, &attributes,
&statusBlock, 0, 0, FILE_SHARE_READ|FILE_SHARE_WRITE|FILE_SHARE_DELETE,
FILE_OPEN, FILE_NON_DIRECTORY_FILE, NULL, 0 );
Try “??\C:\WINDOWS”
— Mark Hahn wrote:
> I apologize in advance if this is a stupid question.
> This is my first
> windows driver.
>
> The following ZwCreateFile call always returns
> STATUS_OBJECT_NAME_NOT_FOUND
> or STATUS_OBJECT_PATH_NOT_FOUND. For example, when
> FileName = “\WINDOWS” I
> get STATUS_OBJECT_NAME_NOT_FOUND and when FileName =
>
> “\WINDOWS\SYSTEM32\NTDLL.DLL” I get
> STATUS_OBJECT_PATH_NOT_FOUND. Both
> paths definitely exist on the volume I’m attached
> to.
>
> This code is called from my dispatch routine for a
> MJ_CREATE, not the
> completion routine, so it should be at passive irq
> level. Can someone tell
> me what I’m doing wrong?
>
> HANDLE fileHandle;
> OBJECT_ATTRIBUTES attributes;
> IO_STATUS_BLOCK statusBlock;
> FILE_ATTRIBUTE_TAG_INFORMATION fileAttrTagInfo;
>
> InitializeObjectAttributes( &attributes, FileName,
> OBJ_KERNEL_HANDLE|OBJ_CASE_INSENSITIVE, NULL, NULL);
>
> status = ZwCreateFile( &fileHandle,
> FILE_READ_ATTRIBUTES, &attributes,
> &statusBlock, 0, 0,
> FILE_SHARE_READ|FILE_SHARE_WRITE|FILE_SHARE_DELETE,
> FILE_OPEN, FILE_NON_DIRECTORY_FILE, NULL, 0 );
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as:
> xxxxx@yahoo.com
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
>I apologize in advance if this is a stupid question. This is my first
windows driver.
The following ZwCreateFile call always returns
STATUS_OBJECT_NAME_NOT_FOUND
Well, if this is your first Windows driver, you should know
a few things about fs filters programming. Using ZwCreateFile
within the create handler is generally a bad idea, which leads
to recursion problems (one exception could be using a shadow
device, which is apparently not your case, however).
Remember that your call or ZwCreate inside the create handler
will invoke another create request, which you have to
handle in your filter (how you will know which create
is “yours” and which is “system’s” ?).
And even more, using ZwCreate within create handler
slows the system down. I think you should study
the IoCreateFileSpecifyDeviceObjectHint function,
which is unfortunately available on WinXP only (yet).
L.
> This code is called from my dispatch routine for a MJ_CREATE, not the
completion routine, so it should be at passive irq level. Can someone tell
me what I’m doing wrong?
Malformed name maybe.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
Thanks.
I keep thinking I’m back in user mode with a default directory and volume.
It takes some serious mind shifting to think in the kernel.
----- Original Message -----
From: “Randy Cook”
Newsgroups: ntfsd
To: “Windows File Systems Devs Interest List”
Sent: Tuesday, January 04, 2005 5:49 PM
Subject: Re: fs filter: ZwCreateFile in MJ_CREATE
> Try “??\C:\WINDOWS”
>
> — Mark Hahn wrote:
>
>> I apologize in advance if this is a stupid question.
>> This is my first
>> windows driver.
>>
>> The following ZwCreateFile call always returns
>> STATUS_OBJECT_NAME_NOT_FOUND
>> or STATUS_OBJECT_PATH_NOT_FOUND. For example, when
>> FileName = “\WINDOWS” I
>> get STATUS_OBJECT_NAME_NOT_FOUND and when FileName =
>>
>> “\WINDOWS\SYSTEM32\NTDLL.DLL” I get
>> STATUS_OBJECT_PATH_NOT_FOUND. Both
>> paths definitely exist on the volume I’m attached
>> to.
>>
>> This code is called from my dispatch routine for a
>> MJ_CREATE, not the
>> completion routine, so it should be at passive irq
>> level. Can someone tell
>> me what I’m doing wrong?
>>
>> HANDLE fileHandle;
>> OBJECT_ATTRIBUTES attributes;
>> IO_STATUS_BLOCK statusBlock;
>> FILE_ATTRIBUTE_TAG_INFORMATION fileAttrTagInfo;
>>
>> InitializeObjectAttributes( &attributes, FileName,
>> OBJ_KERNEL_HANDLE|OBJ_CASE_INSENSITIVE, NULL, NULL);
>>
>> status = ZwCreateFile( &fileHandle,
>> FILE_READ_ATTRIBUTES, &attributes,
>> &statusBlock, 0, 0,
>> FILE_SHARE_READ|FILE_SHARE_WRITE|FILE_SHARE_DELETE,
>> FILE_OPEN, FILE_NON_DIRECTORY_FILE, NULL, 0 );
>>
>>
>>
>> —
>> Questions? First check the IFS FAQ at
>> https://www.osronline.com/article.cfm?id=17
>>
>> You are currently subscribed to ntfsd as:
>> xxxxx@yahoo.com
>> To unsubscribe send a blank email to
>> xxxxx@lists.osr.com
>>
>
>
Ladislav Zezula wrote:
>I apologize in advance if this is a stupid question. This is my first
>windows driver.
>
> The following ZwCreateFile call always returns
> STATUS_OBJECT_NAME_NOT_FOUND
Well, if this is your first Windows driver, you should know
a few things about fs filters programming. Using ZwCreateFile
within the create handler is generally a bad idea, which leads
to recursion problems (one exception could be using a shadow
device, which is apparently not your case, however).
This is a driver for open-read backups so I was planning on a shadow device.
I’ll implement the shadow right away so I can use it in this call.
Remember that your call or ZwCreate inside the create handler
will invoke another create request, which you have to
handle in your filter (how you will know which create
is “yours” and which is “system’s” ?).
And even more, using ZwCreate within create handler
slows the system down. I think you should study
the IoCreateFileSpecifyDeviceObjectHint function,
which is unfortunately available on WinXP only (yet).
Unfortunately this needs to work on win2k also. I was hoping that since I
was opening and closing a file that was going to be opened again
immediately, the file system internals would already have the needed data
laying around so the second open would be fast. Is this a reasonable
expectation?
P.S. I looked all over for a driver that freezes the state of the file
system and allows a backup program to read the frozen state while the system
continues to read/write files with the new data going to an alternate
storage file. I was surprised to find nothing. Has anyone else ever seen
one of these? I’d hate to write something this hard that already exists.
There will soon be a “security” fix for w2k that will
provide the CreateWithHint API. If you can require
this fix, CreateWithHint is better than shadow
devices.
Opening a file that has recently been opened (or is
already open) is faster, at least from what I’ve seen.
Look at Volume Copy Shadow Service (only XP and 2003):
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vss/base/the_volume_shadow_copy_service.asp
Is this what you are talking about?
Unfortunately this needs to work on win2k also. I
was hoping that since I
was opening and closing a file that was going to be
opened again
immediately, the file system internals would already
have the needed data
laying around so the second open would be fast. Is
this a reasonable
expectation?
P.S. I looked all over for a driver that freezes
the state of the file
system and allows a backup program to read the
frozen state while the system
continues to read/write files with the new data
going to an alternate
storage file. I was surprised to find nothing. Has
anyone else ever seen
one of these? I’d hate to write something this hard
that already exists.
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as:
xxxxx@yahoo.com
To unsubscribe send a blank email to
xxxxx@lists.osr.com
Randy Cook wrote:
There will soon be a “security” fix for w2k that will
provide the CreateWithHint API. If you can require
this fix, CreateWithHint is better than shadow
devices.
If I have a speed problem I will look into that. For now I can see no way
around using a shadow device object for each mounted volume I am filtering.
Opening a file that has recently been opened (or is
already open) is faster, at least from what I’ve seen.
That is good. It may save my butt. 
Look at Volume Copy Shadow Service (only XP and 2003):
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vss/base/the_volume_shadow_copy_service.asp
Is this what you are talking about?
Yes, but that service makes a complete duplicate of all files. This
requires your disks to be less than 50% full at all times. My service will
only store the actual data written while the disk is frozen, which is much
smaller.
Thanks for your feedback. It makes me much more comfortable knowing there
are people like you out there to help. I’m about to try my shadow device so
I’m sure I’ll need help.
> > Look at Volume Copy Shadow Service (only XP and 2003):
> http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/vss/base/the_volume_shadow_copy_service.asp
> Is this what you are talking about?
Yes, but that service makes a complete duplicate of all files. This
requires your disks to be less than 50% full at all times.
No, it duplicates only the dirty blocks.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
> Opening a file that has recently been opened (or is
already open) is faster, at least from what I’ve seen.
But only if something has been loaded into the cache
(so if an IRP_MJ_READ or IRP_MJ_WRITE
has been called). Then the file FCB will survive the
file closing.
L.
> If I have a speed problem I will look into that. For now I can see no way
around using a shadow device object for each mounted volume I am
filtering.
In our filter, we use the original create IRP with the newly created file
object. Or, you can create a new IRP and copy the original one
into the new one (except for LIST_ENTRYs), it should work too.
As far as I know, this approach works faster than calling ZwCreateFile
with shadow volume.
L.
So you send the original IRP before you close your file object? Wouldn’t
this have sharing problems?
This may work well since my open-read driver will need to change the sharing
anyway.
“Ladislav Zezula” wrote in message news:xxxxx@ntfsd…
>> If I have a speed problem I will look into that. For now I can see no
>> way
>> around using a shadow device object for each mounted volume I am
>> filtering.
>
> In our filter, we use the original create IRP with the newly created file
> object. Or, you can create a new IRP and copy the original one
> into the new one (except for LIST_ENTRYs), it should work too.
>
> As far as I know, this approach works faster than calling ZwCreateFile
> with shadow volume.
>
> L.
>
>
So doing a dummy read before closing my file may actually speed things up?
“Ladislav Zezula” wrote in message news:xxxxx@ntfsd…
>> Opening a file that has recently been opened (or is
>> already open) is faster, at least from what I’ve seen.
>
> But only if something has been loaded into the cache
> (so if an IRP_MJ_READ or IRP_MJ_WRITE
> has been called). Then the file FCB will survive the
> file closing.
>
> L.
>
>
Great. Now if it was only available on XP and win2k I could use it.
“Maxim S. Shatskih” wrote in message
news:xxxxx@ntfsd…
>> > Look at Volume Copy Shadow Service (only XP and 2003):
>> > http://msdn.microsoft.com/library/default.asp?url=/library/en-
> us/vss/base/the_volume_shadow_copy_service.asp
>> > Is this what you are talking about?
>>
>> Yes, but that service makes a complete duplicate of all files. This
>> requires your disks to be less than 50% full at all times.
>
> No, it duplicates only the dirty blocks.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
I decided to use the OSR routine OsrFilterForwardCreateIrp to make life
easy. It calculates the needed string for ZwCreateFile when in win2k and
calls IoCreateFileSpecifyDeviceObjectHint when in XP. Now I am trying to
get IoCreateFileSpecifyDeviceObjectHint to work.
I assumed that I would just pass the filename from the IRP to
IoCreateFileSpecifyDeviceObjectHint since the routine is just going down the
stack, not back to the IOManager. I have been going crazy trying to get a
name accepted. Here are my results so far:
"" -> STATUS_OBJECT_TYPE_MISMATCH
“\WINDOWS” -> STATUS_OBJECT_NAME_NOT_FOUND
“\WINDOWS\LASTGOOD” -> STATUS_OBJECT_PATH_NOT_FOUND
“\Device\HarddiskVolume1\WINDOWS\LASTGOOD” ->
STATUS_OBJECT_PATH_SYNTAX_BAD
The first result is probably correct since I have FILE_OPEN,
FILE_NON_DIRECTORY_FILE set. The others make no sense to me.
Am I still supposed to use “??\C:\WINDOWS” even when calling
IoCreateFileSpecifyDeviceObjectHint? If so, how do I find out the volume is
“C:” ?
“Randy Cook” wrote in message news:xxxxx@ntfsd…
> Try “??\C:\WINDOWS”
>
> — Mark Hahn wrote:
>
>> I apologize in advance if this is a stupid question.
>> This is my first
>> windows driver.
>>
>> The following ZwCreateFile call always returns
>> STATUS_OBJECT_NAME_NOT_FOUND
>> or STATUS_OBJECT_PATH_NOT_FOUND. For example, when
>> FileName = “\WINDOWS” I
>> get STATUS_OBJECT_NAME_NOT_FOUND and when FileName =
>>
>> “\WINDOWS\SYSTEM32\NTDLL.DLL” I get
>> STATUS_OBJECT_PATH_NOT_FOUND. Both
>> paths definitely exist on the volume I’m attached
>> to.
>>
>> This code is called from my dispatch routine for a
>> MJ_CREATE, not the
>> completion routine, so it should be at passive irq
>> level. Can someone tell
>> me what I’m doing wrong?
>>
>> HANDLE fileHandle;
>> OBJECT_ATTRIBUTES attributes;
>> IO_STATUS_BLOCK statusBlock;
>> FILE_ATTRIBUTE_TAG_INFORMATION fileAttrTagInfo;
>>
>> InitializeObjectAttributes( &attributes, FileName,
>> OBJ_KERNEL_HANDLE|OBJ_CASE_INSENSITIVE, NULL, NULL);
>>
>> status = ZwCreateFile( &fileHandle,
>> FILE_READ_ATTRIBUTES, &attributes,
>> &statusBlock, 0, 0,
>> FILE_SHARE_READ|FILE_SHARE_WRITE|FILE_SHARE_DELETE,
>> FILE_OPEN, FILE_NON_DIRECTORY_FILE, NULL, 0 );
>>
>>
>>
>> —
>> Questions? First check the IFS FAQ at
>> https://www.osronline.com/article.cfm?id=17
>>
>> You are currently subscribed to ntfsd as:
>> xxxxx@yahoo.com
>> To unsubscribe send a blank email to
>> xxxxx@lists.osr.com
>>
>
>
Surely, it will cause CcInitializeCacheMap.
Uninitialize will be done by a garbage collector, which means - much later.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “Mark Hahn”
Newsgroups: ntfsd
To: “Windows File Systems Devs Interest List”
Sent: Thursday, January 06, 2005 10:07 PM
Subject: Re:[ntfsd] Re:fs filter: ZwCreateFile in MJ_CREATE
> So doing a dummy read before closing my file may actually speed things up?
>
> “Ladislav Zezula” wrote in message news:xxxxx@ntfsd…
> >> Opening a file that has recently been opened (or is
> >> already open) is faster, at least from what I’ve seen.
> >
> > But only if something has been loaded into the cache
> > (so if an IRP_MJ_READ or IRP_MJ_WRITE
> > has been called). Then the file FCB will survive the
> > file closing.
> >
> > L.
> >
> >
>
>
>
> —
> Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
I have fixed everything now. It was a stupid string bug (I’ve yet to meet a
smart bug ).
“Thank You” to everyone…
“Mark Hahn” wrote in message news:xxxxx@ntfsd…
>I decided to use the OSR routine OsrFilterForwardCreateIrp to make life
>easy. It calculates the needed string for ZwCreateFile when in win2k and
>calls IoCreateFileSpecifyDeviceObjectHint when in XP. Now I am trying to
>get IoCreateFileSpecifyDeviceObjectHint to work.
>
> I assumed that I would just pass the filename from the IRP to
> IoCreateFileSpecifyDeviceObjectHint since the routine is just going down
> the stack, not back to the IOManager. I have been going crazy trying to
> get a name accepted. Here are my results so far:
>
> "" -> STATUS_OBJECT_TYPE_MISMATCH
> “\WINDOWS” -> STATUS_OBJECT_NAME_NOT_FOUND
> “\WINDOWS\LASTGOOD” -> STATUS_OBJECT_PATH_NOT_FOUND
> “\Device\HarddiskVolume1\WINDOWS\LASTGOOD” ->
> STATUS_OBJECT_PATH_SYNTAX_BAD
>
> The first result is probably correct since I have FILE_OPEN,
> FILE_NON_DIRECTORY_FILE set. The others make no sense to me.
>
> Am I still supposed to use “??\C:\WINDOWS” even when calling
> IoCreateFileSpecifyDeviceObjectHint? If so, how do I find out the volume
> is “C:” ?
>
> “Randy Cook” wrote in message news:xxxxx@ntfsd…
>> Try “??\C:\WINDOWS”
>>
>> — Mark Hahn wrote:
>>
>>> I apologize in advance if this is a stupid question.
>>> This is my first
>>> windows driver.
>>>
>>> The following ZwCreateFile call always returns
>>> STATUS_OBJECT_NAME_NOT_FOUND
>>> or STATUS_OBJECT_PATH_NOT_FOUND. For example, when
>>> FileName = “\WINDOWS” I
>>> get STATUS_OBJECT_NAME_NOT_FOUND and when FileName =
>>>
>>> “\WINDOWS\SYSTEM32\NTDLL.DLL” I get
>>> STATUS_OBJECT_PATH_NOT_FOUND. Both
>>> paths definitely exist on the volume I’m attached
>>> to.
>>>
>>> This code is called from my dispatch routine for a
>>> MJ_CREATE, not the
>>> completion routine, so it should be at passive irq
>>> level. Can someone tell
>>> me what I’m doing wrong?
>>>
>>> HANDLE fileHandle;
>>> OBJECT_ATTRIBUTES attributes;
>>> IO_STATUS_BLOCK statusBlock;
>>> FILE_ATTRIBUTE_TAG_INFORMATION fileAttrTagInfo;
>>>
>>> InitializeObjectAttributes( &attributes, FileName,
>>> OBJ_KERNEL_HANDLE|OBJ_CASE_INSENSITIVE, NULL, NULL);
>>>
>>> status = ZwCreateFile( &fileHandle,
>>> FILE_READ_ATTRIBUTES, &attributes,
>>> &statusBlock, 0, 0,
>>> FILE_SHARE_READ|FILE_SHARE_WRITE|FILE_SHARE_DELETE,
>>> FILE_OPEN, FILE_NON_DIRECTORY_FILE, NULL, 0 );
>>>
>>>
>>>
>>> —
>>> Questions? First check the IFS FAQ at
>>> https://www.osronline.com/article.cfm?id=17
>>>
>>> You are currently subscribed to ntfsd as:
>>> xxxxx@yahoo.com
>>> To unsubscribe send a blank email to
>>> xxxxx@lists.osr.com
>>>
>>
>>
>
>
>