Re[2]: Why ZwCreateFile ALWAYS return STATUS_INVALID_PARAMETER?

OSR_Community_User · June 10, 2008, 5:42am

Hi Ayush
Thank you very much!

I did that in DriverEntry.
When I used L"\DEVICE\HARDDISKVOLUME0\windows\system32\pro.dat", it
returned STATUS_OBJECT_PATH_NOT_FOUND.
When I used L"\??\c:\windows\system32\pro.dat", it returned
STATUS_INVALID_PARAMETER.

So I guess maybe no FSD is up, thus it cause the error. I think you’re
right.

I’ll move the source to other place. Thanks again~

cxun

From: “Ayush Gupta”
Sent: Tuesday, June 10, 2008 4:52 PM
To: “Windows File Systems Devs Interest List”
Subject: RE: [ntfsd] Why ZwCreateFile ALWAYS return
STATUS_INVALID_PARAMETER?

> Is the file system up when you are making this call?
> Since you are making this call from DriverEntry, there is a good chance
> that
> the volume has actually not been mounted by any FSD.
> And if there is no FSD to service your request, you will get this error.
>
> Regards,
> Ayush Gupta
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of cxun
> Sent: Tuesday, June 10, 2008 2:19 PM
> To: Windows File Systems Devs Interest List
> Subject: Re: [ntfsd] Why ZwCreateFile ALWAYS return
> STATUS_INVALID_PARAMETER?
>
> Yes, the file “pro.dat” is in here: c:\windows\system32<br>>
> And I call ZwCreateFile at the beginning of DriverEntry function.
>
> Thank you for the patience. I really appreciate it.
>
> cxun
>
> --------------------------------------------------
> From: “Ayush Gupta”
> Sent: Tuesday, June 10, 2008 4:29 PM
> To: “Windows File Systems Devs Interest List”
> Subject: RE: [ntfsd] Why ZwCreateFile ALWAYS return
> STATUS_INVALID_PARAMETER?
>
>>>I tried L"\\SystemRoot\System32\pro.dat" but it returned:
>>>STATUS_OBJECT_NAME_INVALID
>>
>> Why would you use this?
>>
>>>And when I used L"\SystemRoot\System32\pro.dat" it returned:
>>>STATUS_OBJECT_PATH_NOT_FOUND
>>
>> Is the file ACTUALLY present there?
>>
>> Regards,
>> Ayush Gupta
>>
>>
>> —
>> NTFSD is sponsored by OSR
>>
>> For our schedule debugging and file system seminars
>> (including our new fs mini-filter seminar) visit:
>> http://www.osr.com/seminars
>>
>> You are currently subscribed to ntfsd as: xxxxx@live.com
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> You are currently subscribed to ntfsd as: xxxxx@yahoo.co.in
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> You are currently subscribed to ntfsd as: xxxxx@live.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

Daniel_Terhell · June 10, 2008, 5:45am

Another guess: maybe you are running on x64 and your file in system32 is
actually located in SysWow64 ? Anyway I would first suggest removing all
exotic parameters such as SYNCHRONIZE and stuff, open with GENERIC_READ as
Desired Access. Try to open a file in your root directory first, lookup
with WinObj what your C: symbolic link actually maps to so you do not need
to guess. Eliminate as many uncertain factors in order to make sure that
this call is going to succeed. Then start moving step by step towards your
goal so you can see where it actually goes wrong. There are too many
combinations of parameters and factors possible here so even if somebody
gives you the right suggestion you may be able to miss it because of
something else.

//Daniel

“cxun” wrote in message news:xxxxx@ntfsd…
> Hi Daniel
>
> This time I used L"\DEVICE\HARDDISKVOLUME0\windows\system32\pro.dat",
> it returned STATUS_OBJECT_PATH_NOT_FOUND, which means “The path %hs does
> not exist.” If I tried HARDDISKVOLUME1, it’s the same result…
>
> Thank you so much~
>
> --------------------------------------------------
> From:
> Sent: Tuesday, June 10, 2008 5:05 PM
> Newsgroups: ntfsd
> To: “Windows File Systems Devs Interest List”
> Subject: Re:[ntfsd] Re:Why ZwCreateFile ALWAYS return
> STATUS_INVALID_PARAMETER?
>
>> Right, I suggest stop using these symbolic links but specifying the
>> target device name instead (“\Device\Harddiskvolume…
>>
>> //Daniel
>>
>>
>> “cxun” wrote in message news:xxxxx@ntfsd…
>>> Hi Daniel
>>> When I used L”\\??\c:\Windows\System32\pro.dat" ZwCreate returned
>>> STATUS_OBJECT_NAME_INVALID
>>>
>>> Thank you!
>>>
>>> cxun
>>>
>>> --------------------------------------------------
>>> From:
>>> Sent: Tuesday, June 10, 2008 4:16 PM
>>> Newsgroups: ntfsd
>>> To: “Windows File Systems Devs Interest List”
>>> Subject: Re:[ntfsd] Why ZwCreateFile ALWAYS return
>>> STATUS_INVALID_PARAMETER?
>>>
>>>> “cxun” wrote in message news:xxxxx@ntfsd…
>>>>> pFilePath is: L"\??\c:\windows\system32\pro.dat"
>>>>>
>>>>> Please help me… Thank you…
>>>>>
>>>>
>>>> That’s one slash too little, make that
>>>> L"\\??\c:\windows\system32\pro.dat"
>>>>
>>>>
>>>>>>BTW, when exactly are you calling ZwCreateFile? If it is being called
>>>>>>very
>>>>>>early in boot phase, then you need to give the path name as
>>>>>>\SystemRoot\System32\pro.dat.
>>>>
>>>> That’s one slash too many at the beginning.
>>>>
>>>> //Daniel
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> “cxun” wrote in message news:xxxxx@ntfsd…
>>>>> Why ZwCreateFile ALWAYS return STATUS_INVALID_PARAMETER?
>>>>>
>>>>> I just added sth on the sample of DDK, sfilter. Now I faced the
>>>>> problem: When I used ZwCreateFile, the function always return
>>>>> 0xC000000D, which is STATUS_INVALID_PARAMETER. No matter where I put
>>>>> the source, at the beginning of the DriverEntry, or in other .c file,
>>>>> it’s the same result.
>>>>>
>>>>> The source is below:
>>>>>
>>>>> HANDLE hFileHandle;
>>>>> NTSTATUS ntStatus;
>>>>> UNICODE_STRING uszFileName;
>>>>> OBJECT_ATTRIBUTES objAttributes;
>>>>> IO_STATUS_BLOCK isbCreateReadStatus;
>>>>>
>>>>> if(KeGetCurrentIrql() >= DISPATCH_LEVEL)
>>>>> return STATUS_UNSUCCESSFUL;
>>>>> RtlInitUnicodeString(&uszFileName,
>>>>> pFilePath);
>>>>> InitializeObjectAttributes(&objAttributes,
>>>>> &uszFileName,
>>>>> OBJ_CASE_INSENSITIVE|OBJ_KERNEL_HANDLE,
>>>>> NULL,
>>>>> NULL);
>>>>> ntStatus = ZwCreateFile(&hFileHandle,
>>>>> SYNCHRONIZE|FILE_READ_DATA,
>>>>> &objAttributes,
>>>>> &isbCreateReadStatus,
>>>>> NULL,
>>>>> 0,
>>>>> FILE_SHARE_READ|FILE_SHARE_WRITE,
>>>>> FILE_OPEN,
>>>>>
>>>>> FILE_SYNCHRONOUS_IO_NONALERT|FILE_NON_DIRECTORY_FILE,
>>>>> NULL,
>>>>> 0); // always return
>>>>> STATUS_INVALID_PARAMETER
>>>>> if(!NT_SUCCESS(ntStatus))
>>>>> {
>>>>> KdPrint((“KmdReadWholeFile: Failed to open %ws. Error Code:
>>>>> 0x%xL\n”, pFilePath, ntStatus));
>>>>> return ntStatus;
>>>>> }
>>>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> —
>>>> NTFSD is sponsored by OSR
>>>>
>>>> For our schedule debugging and file system seminars
>>>> (including our new fs mini-filter seminar) visit:
>>>> http://www.osr.com/seminars
>>>>
>>>> You are currently subscribed to ntfsd as: xxxxx@live.com
>>>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>>>
>>>
>>
>> —
>> NTFSD is sponsored by OSR
>>
>> For our schedule debugging and file system seminars
>> (including our new fs mini-filter seminar) visit:
>> http://www.osr.com/seminars
>>
>> You are currently subscribed to ntfsd as: xxxxx@live.com
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>

OSR_Community_User · June 10, 2008, 5:49am

Thanks for everyone who have helped me.

The problem is if I ZwCreateFile right in the DriverEntry function, I cannot
access the file in these ways:
L"\??\c:\windows\system32\pro.dat"
L"\DEVICE\HARDDISKVOLUME0\windows\system32\pro.dat"

So I’ll access the file later after the volume is mounted by the FSD.

Thanks again for everyone~

I hope the problem will be solved later.

OSR_Community_User · June 10, 2008, 5:51am

Thank you~ But I’m not running on x64 machine.
But you teach me a lot. thanks~

From:
Sent: Tuesday, June 10, 2008 5:44 PM
Newsgroups: ntfsd
To: “Windows File Systems Devs Interest List”
Subject: Re:[ntfsd] Re:Re:Why ZwCreateFile ALWAYS return
STATUS_INVALID_PARAMETER?

> Another guess: maybe you are running on x64 and your file in system32 is
> actually located in SysWow64 ? Anyway I would first suggest removing all
> exotic parameters such as SYNCHRONIZE and stuff, open with GENERIC_READ as
> Desired Access. Try to open a file in your root directory first, lookup
> with WinObj what your C: symbolic link actually maps to so you do not need
> to guess. Eliminate as many uncertain factors in order to make sure that
> this call is going to succeed. Then start moving step by step towards your
> goal so you can see where it actually goes wrong. There are too many
> combinations of parameters and factors possible here so even if somebody
> gives you the right suggestion you may be able to miss it because of
> something else.
>
> //Daniel
>
>
>
> “cxun” wrote in message news:xxxxx@ntfsd…
>> Hi Daniel
>>
>> This time I used
>> L"\DEVICE\HARDDISKVOLUME0\windows\system32\pro.dat", it returned
>> STATUS_OBJECT_PATH_NOT_FOUND, which means “The path %hs does not exist.”
>> If I tried HARDDISKVOLUME1, it’s the same result…
>>
>> Thank you so much~
>>
>> --------------------------------------------------
>> From:
>> Sent: Tuesday, June 10, 2008 5:05 PM
>> Newsgroups: ntfsd
>> To: “Windows File Systems Devs Interest List”
>> Subject: Re:[ntfsd] Re:Why ZwCreateFile ALWAYS return
>> STATUS_INVALID_PARAMETER?
>>
>>> Right, I suggest stop using these symbolic links but specifying the
>>> target device name instead (“\Device\Harddiskvolume…
>>>
>>> //Daniel
>>>
>>>
>>> “cxun” wrote in message news:xxxxx@ntfsd…
>>>> Hi Daniel
>>>> When I used L”\\??\c:\Windows\System32\pro.dat" ZwCreate returned
>>>> STATUS_OBJECT_NAME_INVALID
>>>>
>>>> Thank you!
>>>>
>>>> cxun
>>>>
>>>> --------------------------------------------------
>>>> From:
>>>> Sent: Tuesday, June 10, 2008 4:16 PM
>>>> Newsgroups: ntfsd
>>>> To: “Windows File Systems Devs Interest List”
>>>> Subject: Re:[ntfsd] Why ZwCreateFile ALWAYS return
>>>> STATUS_INVALID_PARAMETER?
>>>>
>>>>> “cxun” wrote in message news:xxxxx@ntfsd…
>>>>>> pFilePath is: L"\??\c:\windows\system32\pro.dat"
>>>>>>
>>>>>> Please help me… Thank you…
>>>>>>
>>>>>
>>>>> That’s one slash too little, make that
>>>>> L"\\??\c:\windows\system32\pro.dat"
>>>>>
>>>>>
>>>>>>>BTW, when exactly are you calling ZwCreateFile? If it is being called
>>>>>>>very
>>>>>>>early in boot phase, then you need to give the path name as
>>>>>>>\SystemRoot\System32\pro.dat.
>>>>>
>>>>> That’s one slash too many at the beginning.
>>>>>
>>>>> //Daniel
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> “cxun” wrote in message news:xxxxx@ntfsd…
>>>>>> Why ZwCreateFile ALWAYS return STATUS_INVALID_PARAMETER?
>>>>>>
>>>>>> I just added sth on the sample of DDK, sfilter. Now I faced the
>>>>>> problem: When I used ZwCreateFile, the function always return
>>>>>> 0xC000000D, which is STATUS_INVALID_PARAMETER. No matter where I put
>>>>>> the source, at the beginning of the DriverEntry, or in other .c file,
>>>>>> it’s the same result.
>>>>>>
>>>>>> The source is below:
>>>>>>
>>>>>> HANDLE hFileHandle;
>>>>>> NTSTATUS ntStatus;
>>>>>> UNICODE_STRING uszFileName;
>>>>>> OBJECT_ATTRIBUTES objAttributes;
>>>>>> IO_STATUS_BLOCK isbCreateReadStatus;
>>>>>>
>>>>>> if(KeGetCurrentIrql() >= DISPATCH_LEVEL)
>>>>>> return STATUS_UNSUCCESSFUL;
>>>>>> RtlInitUnicodeString(&uszFileName,
>>>>>> pFilePath);
>>>>>> InitializeObjectAttributes(&objAttributes,
>>>>>> &uszFileName,
>>>>>> OBJ_CASE_INSENSITIVE|OBJ_KERNEL_HANDLE,
>>>>>> NULL,
>>>>>> NULL);
>>>>>> ntStatus = ZwCreateFile(&hFileHandle,
>>>>>> SYNCHRONIZE|FILE_READ_DATA,
>>>>>> &objAttributes,
>>>>>> &isbCreateReadStatus,
>>>>>> NULL,
>>>>>> 0,
>>>>>> FILE_SHARE_READ|FILE_SHARE_WRITE,
>>>>>> FILE_OPEN,
>>>>>>
>>>>>> FILE_SYNCHRONOUS_IO_NONALERT|FILE_NON_DIRECTORY_FILE,
>>>>>> NULL,
>>>>>> 0); // always return
>>>>>> STATUS_INVALID_PARAMETER
>>>>>> if(!NT_SUCCESS(ntStatus))
>>>>>> {
>>>>>> KdPrint((“KmdReadWholeFile: Failed to open %ws. Error Code:
>>>>>> 0x%xL\n”, pFilePath, ntStatus));
>>>>>> return ntStatus;
>>>>>> }
>>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> —
>>>>> NTFSD is sponsored by OSR
>>>>>
>>>>> For our schedule debugging and file system seminars
>>>>> (including our new fs mini-filter seminar) visit:
>>>>> http://www.osr.com/seminars
>>>>>
>>>>> You are currently subscribed to ntfsd as: xxxxx@live.com
>>>>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>>>>
>>>>
>>>
>>> —
>>> NTFSD is sponsored by OSR
>>>
>>> For our schedule debugging and file system seminars
>>> (including our new fs mini-filter seminar) visit:
>>> http://www.osr.com/seminars
>>>
>>> You are currently subscribed to ntfsd as: xxxxx@live.com
>>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>>
>>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> You are currently subscribed to ntfsd as: xxxxx@live.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

Ayush_Gupta-2 · June 10, 2008, 5:53am

It’s not about the volume being mounted. The volume will get mounted anyways
on the first create sent to that volume.
It’s about the file system being ready to service your request.

Regards,
Ayush Gupta

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of cxun
Sent: Tuesday, June 10, 2008 3:19 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Why ZwCreateFile ALWAYS return
STATUS_INVALID_PARAMETER?

Thanks for everyone who have helped me.

The problem is if I ZwCreateFile right in the DriverEntry function, I cannot

access the file in these ways:
L"\??\c:\windows\system32\pro.dat"
L"\DEVICE\HARDDISKVOLUME0\windows\system32\pro.dat"

So I’ll access the file later after the volume is mounted by the FSD.

Thanks again for everyone~

I hope the problem will be solved later.

NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: xxxxx@yahoo.co.in
To unsubscribe send a blank email to xxxxx@lists.osr.com

OSR_Community_User · June 10, 2008, 11:40am

Hi Ayush

It’s about the file system being ready to service your request.
What does this mean? I tried another method. In DriverEntry I create a new
thread. In the thread the operation ZwCreateFile finally succeed. But what’s
the differences? Do you know that?

Thank you~

cxun

From: “Ayush Gupta”
Sent: Tuesday, June 10, 2008 5:52 PM
To: “Windows File Systems Devs Interest List”
Subject: RE: [ntfsd] Why ZwCreateFile ALWAYS return
STATUS_INVALID_PARAMETER?

> It’s not about the volume being mounted. The volume will get mounted
> anyways
> on the first create sent to that volume.
> It’s about the file system being ready to service your request.
>
> Regards,
> Ayush Gupta
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of cxun
> Sent: Tuesday, June 10, 2008 3:19 PM
> To: Windows File Systems Devs Interest List
> Subject: Re: [ntfsd] Why ZwCreateFile ALWAYS return
> STATUS_INVALID_PARAMETER?
>
> Thanks for everyone who have helped me.
>
> The problem is if I ZwCreateFile right in the DriverEntry function, I
> cannot
>
> access the file in these ways:
> L"\??\c:\windows\system32\pro.dat"
> L"\DEVICE\HARDDISKVOLUME0\windows\system32\pro.dat"
>
> So I’ll access the file later after the volume is mounted by the FSD.
>
> Thanks again for everyone~
>
> I hope the problem will be solved later.
>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> You are currently subscribed to ntfsd as: xxxxx@yahoo.co.in
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> You are currently subscribed to ntfsd as: xxxxx@live.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

Ayush_Gupta-2 · June 10, 2008, 12:36pm

Hi!

I can’t comment on the difference between the two. But from my understanding, if you look at it from a very high level also, you will notice that the start type of file system recognizer is 1. If a driver with start type 0 tries to access a file from its DriverEntry, the file system recognizer won’t be up by then. And if the FS recognizer is not present, the FSD that can understand the file system present on that particular volume cannot be loaded.
Hence, your request to open a file fails.

My guess on thread creation trick: Maybe thread creation gives sufficient time for the kernel to enter in later phase and a chance to load the FS recognizer. So, when you call ZwCreateFile, FS recognizer is present ( or maybe even the FSD has also been loaded ) that will handle this call.

Regards,
Ayush Gupta

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of ??
Sent: Tuesday, June 10, 2008 9:10 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Why ZwCreateFile ALWAYS return STATUS_INVALID_PARAMETER?

Hi Ayush

It’s about the file system being ready to service your request.
What does this mean? I tried another method. In DriverEntry I create a new
thread. In the thread the operation ZwCreateFile finally succeed. But what’s
the differences? Do you know that?

Thank you~

cxun

From: “Ayush Gupta”
Sent: Tuesday, June 10, 2008 5:52 PM
To: “Windows File Systems Devs Interest List”
Subject: RE: [ntfsd] Why ZwCreateFile ALWAYS return
STATUS_INVALID_PARAMETER?

> It’s not about the volume being mounted. The volume will get mounted
> anyways
> on the first create sent to that volume.
> It’s about the file system being ready to service your request.
>
> Regards,
> Ayush Gupta
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of cxun
> Sent: Tuesday, June 10, 2008 3:19 PM
> To: Windows File Systems Devs Interest List
> Subject: Re: [ntfsd] Why ZwCreateFile ALWAYS return
> STATUS_INVALID_PARAMETER?
>
> Thanks for everyone who have helped me.
>
> The problem is if I ZwCreateFile right in the DriverEntry function, I
> cannot
>
> access the file in these ways:
> L"\??\c:\windows\system32\pro.dat"
> L"\DEVICE\HARDDISKVOLUME0\windows\system32\pro.dat"
>
> So I’ll access the file later after the volume is mounted by the FSD.
>
> Thanks again for everyone~
>
> I hope the problem will be solved later.
>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> You are currently subscribed to ntfsd as: xxxxx@yahoo.co.in
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> You are currently subscribed to ntfsd as: xxxxx@live.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

—
NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: xxxxx@yahoo.co.in
To unsubscribe send a blank email to xxxxx@lists.osr.com

Prokash_Sinha-1 · June 10, 2008, 1:52pm

Oh, I love this question(s) from cxun. Please someone answers these …

If a driver is set to have a start time X ( 0 … 3) under what
circumstances it could start earlier ( i.e. y < x )?. Any tine, Never
ever, sometime ?
Is it true that always FS recognizer starts at 1? If so, are there any
file systems that are beyond its control(s) in the sense that they get
started earlier and FS recognizer has any role in it.
DriverEntry() is invoked under systemProcess, and there is the thread
created here ( i.e by default under system process), then why is this
difference that one can open/create but on the other ( ie. the code path
in DriverEntry(). Is there there any state related information(s) …

Thanks in advance for englightment !

-pro

Hi!

I can’t comment on the difference between the two. But from my
understanding, if you look at it from a very high level also, you will
notice that the start type of file system recognizer is 1. If a driver
with start type 0 tries to access a file from its DriverEntry, the file
system recognizer won’t be up by then. And if the FS recognizer is not
present, the FSD that can understand the file system present on that
particular volume cannot be loaded.
Hence, your request to open a file fails.

My guess on thread creation trick: Maybe thread creation gives sufficient
time for the kernel to enter in later phase and a chance to load the FS
recognizer. So, when you call ZwCreateFile, FS recognizer is present ( or
maybe even the FSD has also been loaded ) that will handle this call.

Regards,
Ayush Gupta

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of ??
Sent: Tuesday, June 10, 2008 9:10 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Why ZwCreateFile ALWAYS return
STATUS_INVALID_PARAMETER?

Hi Ayush

> It’s about the file system being ready to service your request.
What does this mean? I tried another method. In DriverEntry I create a new
thread. In the thread the operation ZwCreateFile finally succeed. But
what’s
the differences? Do you know that?

Thank you~

cxun

From: “Ayush Gupta”
> Sent: Tuesday, June 10, 2008 5:52 PM
> To: “Windows File Systems Devs Interest List”
> Subject: RE: [ntfsd] Why ZwCreateFile ALWAYS return
> STATUS_INVALID_PARAMETER?
>
>> It’s not about the volume being mounted. The volume will get mounted
>> anyways
>> on the first create sent to that volume.
>> It’s about the file system being ready to service your request.
>>
>> Regards,
>> Ayush Gupta
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of cxun
>> Sent: Tuesday, June 10, 2008 3:19 PM
>> To: Windows File Systems Devs Interest List
>> Subject: Re: [ntfsd] Why ZwCreateFile ALWAYS return
>> STATUS_INVALID_PARAMETER?
>>
>> Thanks for everyone who have helped me.
>>
>> The problem is if I ZwCreateFile right in the DriverEntry function, I
>> cannot
>>
>> access the file in these ways:
>> L"\??\c:\windows\system32\pro.dat"
>> L"\DEVICE\HARDDISKVOLUME0\windows\system32\pro.dat"
>>
>> So I’ll access the file later after the volume is mounted by the FSD.
>>
>> Thanks again for everyone~
>>
>> I hope the problem will be solved later.
>>
>>
>> —
>> NTFSD is sponsored by OSR
>>
>> For our schedule debugging and file system seminars
>> (including our new fs mini-filter seminar) visit:
>> http://www.osr.com/seminars
>>
>> You are currently subscribed to ntfsd as: xxxxx@yahoo.co.in
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>> —
>> NTFSD is sponsored by OSR
>>
>> For our schedule debugging and file system seminars
>> (including our new fs mini-filter seminar) visit:
>> http://www.osr.com/seminars
>>
>> You are currently subscribed to ntfsd as: xxxxx@live.com
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> You are currently subscribed to ntfsd as: xxxxx@yahoo.co.in
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

anton_bassov · June 10, 2008, 4:05pm

> 2) Is it true that always FS recognizer starts at 1? If so, are there any file systems that

are beyond its control(s) in the sense that they get started earlier and FS recognizer
has any role in it.

Start type 0 means that the driver is loaded into RAM by ntldr *before* ntoskrnl.exe starts execution. The only reason for doing so is avoiding loading inter-dependencies that would arise if ntoskrnl.exe had to load a given driver. However, their DriverEntry() routines are not called at this time, for understandable reasons - it may happen only after IO Manager has been initialized. All these drivers start their actual execution only in Phase 1 when the system boot loader progress bar is already set to 25%. At this point IO Manager starts executing their code, plus loads and executes loads drivers of start type 1 and executes their DriverEntry() routines (which, btw, takes 50% of the boot time). Therefore, for the practical purposes, there is no huge difference between start type 0 and start type 1 - in both cases you have to live with the fact that some calls cannot be made in their DriverEntry() routines, because drivers that are required for this call to be successful are, probably, not yet ready…

DriverEntry() is invoked under systemProcess, and there is the thread created here
( i.e by default under system process), then why is this difference that one can open/create but on the > other ( ie. the code path in DriverEntry(). Is there there any state related information(s) …

I think it happens because driver-created threads start their *actual*execution at a later stage, i.e. after DriverEntry() points of all drivers of start types 0 and 1 have been invoked, so that all necessary drivers are already up and running…

Anton Bassov

Prokash_Sinha-1 · June 10, 2008, 4:29pm

Thanks Anton for enlightment!

-pro

> 2) Is it true that always FS recognizer starts at 1? If so, are there
> any file systems that
> are beyond its control(s) in the sense that they get started earlier and
> FS recognizer
> has any role in it.

Start type 0 means that the driver is loaded into RAM by ntldr *before*
ntoskrnl.exe starts execution. The only reason for doing so is avoiding
loading inter-dependencies that would arise if ntoskrnl.exe had to load a
given driver. However, their DriverEntry() routines are not called at this
time, for understandable reasons - it may happen only after IO Manager has
been initialized. All these drivers start their actual execution only in
Phase 1 when the system boot loader progress bar is already set to 25%. At
this point IO Manager starts executing their code, plus loads and executes
loads drivers of start type 1 and executes their DriverEntry() routines
(which, btw, takes 50% of the boot time). Therefore, for the practical
purposes, there is no huge difference between start type 0 and start type
1 - in both cases you have to live with the fact that some calls cannot be
made in their DriverEntry() routines, because drivers that are required
for this call to be successful are, probably, not yet ready…

> 3) DriverEntry() is invoked under systemProcess, and there is the thread
> created here
> ( i.e by default under system process), then why is this difference
> that one can open/create but on the > other ( ie. the code path in
> DriverEntry(). Is there there any state related information(s) …

I think it happens because driver-created threads start their
*actual*execution at a later stage, i.e. after DriverEntry() points of all
drivers of start types 0 and 1 have been invoked, so that all necessary
drivers are already up and running…

Anton Bassov

NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

OSR_Community_User · June 11, 2008, 3:12am

Yes, Anton and Ayush are right. The thread created in DriverEntry starts to
run sometime later after DriverEntry is done.

This is the output:

—>>> DriverEntry: sfilter.sys loaded. // DriverEntry() starts
—>>> before CreateInitThread // before CreateInitThread() is
called
—>>> PsCreateSystemThread() done // a thread is created
—>>> ZwClose(ThreadHandle) done // close the thread handle
—>>> after CreateInitThread // after CreateInitThread() is called
—>>> Exiting DriverEntry() // DriverEntry() running complete
—>>> start Init(PVOID Context) // the thread starts to run
—>>> end of Init(PVOID Context) // the thread running complete

cxun

From:
Sent: Wednesday, June 11, 2008 4:05 AM
To: “Windows File Systems Devs Interest List”
Subject: RE:[ntfsd] Re[2]: Why ZwCreateFile ALWAYS return
STATUS_INVALID_PARAMETER?

>> 2) Is it true that always FS recognizer starts at 1? If so, are there any
>> file systems that
>> are beyond its control(s) in the sense that they get started earlier and
>> FS recognizer
>> has any role in it.
>
> Start type 0 means that the driver is loaded into RAM by ntldr before
> ntoskrnl.exe starts execution. The only reason for doing so is avoiding
> loading inter-dependencies that would arise if ntoskrnl.exe had to load a
> given driver. However, their DriverEntry() routines are not called at this
> time, for understandable reasons - it may happen only after IO Manager has
> been initialized. All these drivers start their actual execution only in
> Phase 1 when the system boot loader progress bar is already set to 25%. At
> this point IO Manager starts executing their code, plus loads and executes
> loads drivers of start type 1 and executes their DriverEntry() routines
> (which, btw, takes 50% of the boot time). Therefore, for the practical
> purposes, there is no huge difference between start type 0 and start type
> 1 - in both cases you have to live with the fact that some calls cannot be
> made in their DriverEntry() routines, because drivers that are required
> for this call to be successful are, probably, not yet ready…
>
>> 3) DriverEntry() is invoked under systemProcess, and there is the thread
>> created here
>> ( i.e by default under system process), then why is this difference
>> that one can open/create but on the > other ( ie. the code path in
>> DriverEntry(). Is there there any state related information(s) …
>
> I think it happens because driver-created threads start their
> actualexecution at a later stage, i.e. after DriverEntry() points of all
> drivers of start types 0 and 1 have been invoked, so that all necessary
> drivers are already up and running…
>
> Anton Bassov
>
>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>