Does IoGetDeviceObjectPointer can return other status than
STATUS_SUCCESS
STATUS_OBJECT_TYPE_MISMATCH
STATUS_INVALID_PARAMETER
STATUS_PRIVILEGE_NOT_HELD
STATUS_INSUFFICIENT_RESOURCES
STATUS_OBJECT_NAME_INVALID
thanks
Very likely, yes.
Is there some reason, aside from idle curiosity, that you’re asking?
Peter
Simply,
– i use ZwQuerySymbolicLinkObject to get the name of the device object,
– IoGetDeviceObjectPointer call, return other status than
STATUS_SUCCESS
STATUS_OBJECT_TYPE_MISMATCH
STATUS_INVALID_PARAMETER
STATUS_PRIVILEGE_NOT_HELD
STATUS_INSUFFICIENT_RESOURCES
STATUS_OBJECT_NAME_INVALID
Why ? And does DDK say something on this case ?
Thanks
At 16:29 13/02/2006, you wrote:
Very likely, yes.
Is there some reason, aside from idle curiosity, that you’re asking?
Peter
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256You are currently subscribed to ntdev as: xxxxx@logique.jussieu.fr
To unsubscribe send a blank email to xxxxx@lists.osr.com
As Peter said, it most certainly does, and I would guess from this
question that you are new to driver development. Assuming that, I would
warn you about a common mistake … (STATUS_SUCCESS == status). That is a
guaranteed Verifier failure. You should be using the NT_SUCCESS(status)
macro instead, since there are many “success” status values that can be
returned and will fail (STATUS_SUCCESS == status).
Gary G. Little
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@logique.jussieu.fr
Sent: Monday, February 13, 2006 9:25 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] IoGetDeviceObjectPointer return
Does IoGetDeviceObjectPointer can return other status than
STATUS_SUCCESS
STATUS_OBJECT_TYPE_MISMATCH
STATUS_INVALID_PARAMETER
STATUS_PRIVILEGE_NOT_HELD
STATUS_INSUFFICIENT_RESOURCES
STATUS_OBJECT_NAME_INVALID
thanks
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@seagate.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Well what status does it return? Why didn’t you just ask what a return
of STATUS_WHATEVER on a call to IoGetDeviceObjectPointer means?
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Sedki Boughattas
Sent: Monday, February 13, 2006 11:22 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] IoGetDeviceObjectPointer return
Simply,
– i use ZwQuerySymbolicLinkObject to get the name of the device object,
– IoGetDeviceObjectPointer call, return other status than
STATUS_SUCCESS
STATUS_OBJECT_TYPE_MISMATCH
STATUS_INVALID_PARAMETER
STATUS_PRIVILEGE_NOT_HELD
STATUS_INSUFFICIENT_RESOURCES
STATUS_OBJECT_NAME_INVALID
Why ? And does DDK say something on this case ?
Thanks
At 16:29 13/02/2006, you wrote:
Very likely, yes.
Is there some reason, aside from idle curiosity, that you’re asking?
Peter
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256You are currently subscribed to ntdev as: xxxxx@logique.jussieu.fr
To unsubscribe send a blank email to xxxxx@lists.osr.com
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Yes, i’m new in driver development. I try to understand this.
Thank you for your indulgence.
Thanks
At 17:25 13/02/2006, you wrote:
As Peter said, it most certainly does, and I would guess from this
question that you are new to driver development. Assuming that, I would
warn you about a common mistake … (STATUS_SUCCESS == status). That is a
guaranteed Verifier failure. You should be using the NT_SUCCESS(status)
macro instead, since there are many “success” status values that can be
returned and will fail (STATUS_SUCCESS == status).Gary G. Little
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@logique.jussieu.fr
Sent: Monday, February 13, 2006 9:25 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] IoGetDeviceObjectPointer returnDoes IoGetDeviceObjectPointer can return other status than
STATUS_SUCCESS
STATUS_OBJECT_TYPE_MISMATCH
STATUS_INVALID_PARAMETER
STATUS_PRIVILEGE_NOT_HELD
STATUS_INSUFFICIENT_RESOURCES
STATUS_OBJECT_NAME_INVALIDthanks
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256You are currently subscribed to ntdev as: xxxxx@seagate.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256You are currently subscribed to ntdev as: xxxxx@logique.jussieu.fr
To unsubscribe send a blank email to xxxxx@lists.osr.com
Gary, from my personal experience i feel opposite to what you say i.e. to
handle each success case seperately.
Think of STATUS_PENDING vs STATUS_SUCCESS. Let us say i receive an IRP to
delete one of my object. The object deletion routine returns STATUS_PENDING
because the object has a pending reference count. Now NT_SUCCESS will return
TRUE for both STATUS_PENDING and STATUS_SUCCESS but my handling requires a
different code path if it is STATUS_PENDING.
The bigger problem is when you think of another function like
IoCreateDevice. This function can return STATUS_OBJECT_NAME_EXISTS which is
a success according to NT_SUCCESS but it is actually a failure. I did not
try this myself but i am *assuming* that DeviceObject returned will be NULL
in this case. Using NT_SUCCESS macro will be bad here.
In fact i simply hate this paradigm of returning multiple success with
differnet meanings. Like in COM you have S_OK success, S_FALSE success but
no more elements and S_FAILURE (etc) for failure. I believe, each API should
have only ONE success value and all other should be failure. It should be
callers responsibility to decipher each failure seperately if he wants to.
I had this discussion few days back with another colleague on the same topic
but we could not come up with any reason why you would use NT_SUCCESS macro.
I am sure there are reasons to use these macros but i find them providing
wrong/partial information which is not healthy.
–
Pankaj Garg
This posting is provided “AS IS” with no warranties and confers no rights.
wrote in message news:xxxxx@ntdev…
> As Peter said, it most certainly does, and I would guess from this
> question that you are new to driver development. Assuming that, I would
> warn you about a common mistake … (STATUS_SUCCESS == status). That is a
> guaranteed Verifier failure. You should be using the NT_SUCCESS(status)
> macro instead, since there are many “success” status values that can be
> returned and will fail (STATUS_SUCCESS == status).
>
> Gary G. Little
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of
> xxxxx@logique.jussieu.fr
> Sent: Monday, February 13, 2006 9:25 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] IoGetDeviceObjectPointer return
>
> Does IoGetDeviceObjectPointer can return other status than
>
> STATUS_SUCCESS
> STATUS_OBJECT_TYPE_MISMATCH
> STATUS_INVALID_PARAMETER
> STATUS_PRIVILEGE_NOT_HELD
> STATUS_INSUFFICIENT_RESOURCES
> STATUS_OBJECT_NAME_INVALID
>
> thanks
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@seagate.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
The STATUS_PENDING case is specific to forwarding IO requests. For most
DDK interfaces STATUS_PENDING is not relevant.
In the general case your code can first switch on NT_SUCCESS(Status) and
then perhaps for the error path perform specific remedies for individual
error cases. In general the specific error case is interesting only
while you are debugging the code, or for logging/tracing purposes,
although there are exceptions. Given the massive prevalence of
NT_SUCCESS usage in the code base, you are going to have to come up with
a more compelling argument for why we all should abandon this coding
pattern. (Sort of a software pattern argument ad populum, hmmm…)
But this is way past the OP’s original problem. His problem was that he
was trying to run a marathon not having mastered crawling.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Pankaj Garg
Sent: Monday, February 13, 2006 3:54 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] IoGetDeviceObjectPointer return
Gary, from my personal experience i feel opposite to what you say i.e.
to
handle each success case seperately.
Think of STATUS_PENDING vs STATUS_SUCCESS. Let us say i receive an IRP
to
delete one of my object. The object deletion routine returns
STATUS_PENDING
because the object has a pending reference count. Now NT_SUCCESS will
return
TRUE for both STATUS_PENDING and STATUS_SUCCESS but my handling requires
a
different code path if it is STATUS_PENDING.
The bigger problem is when you think of another function like
IoCreateDevice. This function can return STATUS_OBJECT_NAME_EXISTS which
is
a success according to NT_SUCCESS but it is actually a failure. I did
not
try this myself but i am *assuming* that DeviceObject returned will be
NULL
in this case. Using NT_SUCCESS macro will be bad here.
In fact i simply hate this paradigm of returning multiple success with
differnet meanings. Like in COM you have S_OK success, S_FALSE success
but
no more elements and S_FAILURE (etc) for failure. I believe, each API
should
have only ONE success value and all other should be failure. It should
be
callers responsibility to decipher each failure seperately if he wants
to.
I had this discussion few days back with another colleague on the same
topic
but we could not come up with any reason why you would use NT_SUCCESS
macro.
I am sure there are reasons to use these macros but i find them
providing
wrong/partial information which is not healthy.
–
Pankaj Garg
This posting is provided “AS IS” with no warranties and confers no
rights.
wrote in message news:xxxxx@ntdev…
> As Peter said, it most certainly does, and I would guess from this
> question that you are new to driver development. Assuming that, I
would
> warn you about a common mistake … (STATUS_SUCCESS == status). That
is a
> guaranteed Verifier failure. You should be using the
NT_SUCCESS(status)
> macro instead, since there are many “success” status values that can
be
> returned and will fail (STATUS_SUCCESS == status).
>
> Gary G. Little
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of
> xxxxx@logique.jussieu.fr
> Sent: Monday, February 13, 2006 9:25 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] IoGetDeviceObjectPointer return
>
> Does IoGetDeviceObjectPointer can return other status than
>
> STATUS_SUCCESS
> STATUS_OBJECT_TYPE_MISMATCH
> STATUS_INVALID_PARAMETER
> STATUS_PRIVILEGE_NOT_HELD
> STATUS_INSUFFICIENT_RESOURCES
> STATUS_OBJECT_NAME_INVALID
>
> thanks
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@seagate.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
You have to split the functions which return multiple NT_SUCCESS values
vs those that don’t. Basically, treat the NTSTATUS as a Boolean.
IoCreateDevice has to return many different erros conditions, it is
unfortunate that some return TRUE for NT_SUCCESS, but that is not going
to change.
Look at a start device handler. While you may special case
STATUS_PENDING (to remove the wait), you are essentially doing this
status = IoCallDriver();
Wait for the irp to complete synchronously
if (!NT_SUCCESS(irp)) {
// start failed, return error up the stack
}
// continue onward
If you had if (status == STATUS_SUCCESS) instead of NT_SUCCESS() you
would miss all success cases (and Driver Verifier would nail you to the
ground in the process). I think your assertion should be flipped. In
90% of the cases out there, you will treat the NTSTATUS as a BOOLEAN and
only differentiate between specific values in limited cases.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Pankaj Garg
Sent: Monday, February 13, 2006 12:54 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] IoGetDeviceObjectPointer return
Gary, from my personal experience i feel opposite to what you say i.e.
to
handle each success case seperately.
Think of STATUS_PENDING vs STATUS_SUCCESS. Let us say i receive an IRP
to
delete one of my object. The object deletion routine returns
STATUS_PENDING
because the object has a pending reference count. Now NT_SUCCESS will
return
TRUE for both STATUS_PENDING and STATUS_SUCCESS but my handling requires
a
different code path if it is STATUS_PENDING.
The bigger problem is when you think of another function like
IoCreateDevice. This function can return STATUS_OBJECT_NAME_EXISTS which
is
a success according to NT_SUCCESS but it is actually a failure. I did
not
try this myself but i am *assuming* that DeviceObject returned will be
NULL
in this case. Using NT_SUCCESS macro will be bad here.
In fact i simply hate this paradigm of returning multiple success with
differnet meanings. Like in COM you have S_OK success, S_FALSE success
but
no more elements and S_FAILURE (etc) for failure. I believe, each API
should
have only ONE success value and all other should be failure. It should
be
callers responsibility to decipher each failure seperately if he wants
to.
I had this discussion few days back with another colleague on the same
topic
but we could not come up with any reason why you would use NT_SUCCESS
macro.
I am sure there are reasons to use these macros but i find them
providing
wrong/partial information which is not healthy.
–
Pankaj Garg
This posting is provided “AS IS” with no warranties and confers no
rights.
wrote in message news:xxxxx@ntdev…
> As Peter said, it most certainly does, and I would guess from this
> question that you are new to driver development. Assuming that, I
would
> warn you about a common mistake … (STATUS_SUCCESS == status). That
is a
> guaranteed Verifier failure. You should be using the
NT_SUCCESS(status)
> macro instead, since there are many “success” status values that can
be
> returned and will fail (STATUS_SUCCESS == status).
>
> Gary G. Little
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of
> xxxxx@logique.jussieu.fr
> Sent: Monday, February 13, 2006 9:25 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] IoGetDeviceObjectPointer return
>
> Does IoGetDeviceObjectPointer can return other status than
>
> STATUS_SUCCESS
> STATUS_OBJECT_TYPE_MISMATCH
> STATUS_INVALID_PARAMETER
> STATUS_PRIVILEGE_NOT_HELD
> STATUS_INSUFFICIENT_RESOURCES
> STATUS_OBJECT_NAME_INVALID
>
> thanks
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@seagate.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Mark,
You missed the point. My assertion is, it is not always success when
NT_SUCCESS says TRUE. I agree with Doron however, that in 90% cases
NT_SUCCESS == TRUE means it is a valid success and only few cases like Wait
APIs, IoCreateDevice etc where NT_SUCCESS->TRUE can mean failure of some
sort.
Similarly NT_ERROR is a bad macro. In ZwEnumerateKey the return value can be
STATUS_NO_MORE_ENTRIES for a failure but NT_ERROR will return FALSE, because
it is a warning. Crrrap.
Anyways, my assertion was to always look at the API, understand its return
values before blindly relying on macros like NT_SUCCESS. Also my personal
opinion is that it would have been better if we had only one definition of
success and all others were failures so a programmer would always be
vigilant to properly handle the return values.
BTW my driver writing experience is not as extensive as most of you guys
here and mostly it is NDIS related, so i have not yet used an API which
returns multiple SUCCESS codes. Can you give me an example here?
–
Pankaj Garg
This posting is provided “AS IS” with no warranties and confers no rights.
“Roddy, Mark” wrote in message news:xxxxx@ntdev…
The STATUS_PENDING case is specific to forwarding IO requests. For most
DDK interfaces STATUS_PENDING is not relevant.
In the general case your code can first switch on NT_SUCCESS(Status) and
then perhaps for the error path perform specific remedies for individual
error cases. In general the specific error case is interesting only
while you are debugging the code, or for logging/tracing purposes,
although there are exceptions. Given the massive prevalence of
NT_SUCCESS usage in the code base, you are going to have to come up with
a more compelling argument for why we all should abandon this coding
pattern. (Sort of a software pattern argument ad populum, hmmm…)
But this is way past the OP’s original problem. His problem was that he
was trying to run a marathon not having mastered crawling.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Pankaj Garg
Sent: Monday, February 13, 2006 3:54 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] IoGetDeviceObjectPointer return
Gary, from my personal experience i feel opposite to what you say i.e.
to
handle each success case seperately.
Think of STATUS_PENDING vs STATUS_SUCCESS. Let us say i receive an IRP
to
delete one of my object. The object deletion routine returns
STATUS_PENDING
because the object has a pending reference count. Now NT_SUCCESS will
return
TRUE for both STATUS_PENDING and STATUS_SUCCESS but my handling requires
a
different code path if it is STATUS_PENDING.
The bigger problem is when you think of another function like
IoCreateDevice. This function can return STATUS_OBJECT_NAME_EXISTS which
is
a success according to NT_SUCCESS but it is actually a failure. I did
not
try this myself but i am assuming that DeviceObject returned will be
NULL
in this case. Using NT_SUCCESS macro will be bad here.
In fact i simply hate this paradigm of returning multiple success with
differnet meanings. Like in COM you have S_OK success, S_FALSE success
but
no more elements and S_FAILURE (etc) for failure. I believe, each API
should
have only ONE success value and all other should be failure. It should
be
callers responsibility to decipher each failure seperately if he wants
to.
I had this discussion few days back with another colleague on the same
topic
but we could not come up with any reason why you would use NT_SUCCESS
macro.
I am sure there are reasons to use these macros but i find them
providing
wrong/partial information which is not healthy.
–
Pankaj Garg
This posting is provided “AS IS” with no warranties and confers no
rights.
wrote in message news:xxxxx@ntdev…
> As Peter said, it most certainly does, and I would guess from this
> question that you are new to driver development. Assuming that, I
would
> warn you about a common mistake … (STATUS_SUCCESS == status). That
is a
> guaranteed Verifier failure. You should be using the
NT_SUCCESS(status)
> macro instead, since there are many “success” status values that can
be
> returned and will fail (STATUS_SUCCESS == status).
>
> Gary G. Little
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of
> xxxxx@logique.jussieu.fr
> Sent: Monday, February 13, 2006 9:25 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] IoGetDeviceObjectPointer return
>
> Does IoGetDeviceObjectPointer can return other status than
>
> STATUS_SUCCESS
> STATUS_OBJECT_TYPE_MISMATCH
> STATUS_INVALID_PARAMETER
> STATUS_PRIVILEGE_NOT_HELD
> STATUS_INSUFFICIENT_RESOURCES
> STATUS_OBJECT_NAME_INVALID
>
> thanks
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@seagate.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
If you didn’t mean that kernel programmers should always examine each
success return individually, then I think we are in violent agreement.
Must have been my misreading of your original post.
Certainly NT_ERROR is near-useless, and in fact is hardly ever used.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Pankaj Garg
Sent: Monday, February 13, 2006 4:35 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] IoGetDeviceObjectPointer return
Mark,
You missed the point. My assertion is, it is not always success when
NT_SUCCESS says TRUE. I agree with Doron however, that in 90% cases
NT_SUCCESS == TRUE means it is a valid success and only few cases like
Wait
APIs, IoCreateDevice etc where NT_SUCCESS->TRUE can mean failure of some
sort.
Similarly NT_ERROR is a bad macro. In ZwEnumerateKey the return value
can be
STATUS_NO_MORE_ENTRIES for a failure but NT_ERROR will return FALSE,
because
it is a warning. Crrrap.
Anyways, my assertion was to always look at the API, understand its
return
values before blindly relying on macros like NT_SUCCESS. Also my
personal
opinion is that it would have been better if we had only one definition
of
success and all others were failures so a programmer would always be
vigilant to properly handle the return values.
BTW my driver writing experience is not as extensive as most of you guys
here and mostly it is NDIS related, so i have not yet used an API which
returns multiple SUCCESS codes. Can you give me an example here?
–
Pankaj Garg
This posting is provided “AS IS” with no warranties and confers no
rights.
“Roddy, Mark” wrote in message
news:xxxxx@ntdev…
The STATUS_PENDING case is specific to forwarding IO requests. For most
DDK interfaces STATUS_PENDING is not relevant.
In the general case your code can first switch on NT_SUCCESS(Status) and
then perhaps for the error path perform specific remedies for individual
error cases. In general the specific error case is interesting only
while you are debugging the code, or for logging/tracing purposes,
although there are exceptions. Given the massive prevalence of
NT_SUCCESS usage in the code base, you are going to have to come up with
a more compelling argument for why we all should abandon this coding
pattern. (Sort of a software pattern argument ad populum, hmmm…)
But this is way past the OP’s original problem. His problem was that he
was trying to run a marathon not having mastered crawling.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Pankaj Garg
Sent: Monday, February 13, 2006 3:54 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] IoGetDeviceObjectPointer return
Gary, from my personal experience i feel opposite to what you say i.e.
to
handle each success case seperately.
Think of STATUS_PENDING vs STATUS_SUCCESS. Let us say i receive an IRP
to
delete one of my object. The object deletion routine returns
STATUS_PENDING
because the object has a pending reference count. Now NT_SUCCESS will
return
TRUE for both STATUS_PENDING and STATUS_SUCCESS but my handling requires
a
different code path if it is STATUS_PENDING.
The bigger problem is when you think of another function like
IoCreateDevice. This function can return STATUS_OBJECT_NAME_EXISTS which
is
a success according to NT_SUCCESS but it is actually a failure. I did
not
try this myself but i am assuming that DeviceObject returned will be
NULL
in this case. Using NT_SUCCESS macro will be bad here.
In fact i simply hate this paradigm of returning multiple success with
differnet meanings. Like in COM you have S_OK success, S_FALSE success
but
no more elements and S_FAILURE (etc) for failure. I believe, each API
should
have only ONE success value and all other should be failure. It should
be
callers responsibility to decipher each failure seperately if he wants
to.
I had this discussion few days back with another colleague on the same
topic
but we could not come up with any reason why you would use NT_SUCCESS
macro.
I am sure there are reasons to use these macros but i find them
providing
wrong/partial information which is not healthy.
–
Pankaj Garg
This posting is provided “AS IS” with no warranties and confers no
rights.
wrote in message news:xxxxx@ntdev…
> As Peter said, it most certainly does, and I would guess from this
> question that you are new to driver development. Assuming that, I
would
> warn you about a common mistake … (STATUS_SUCCESS == status). That
is a
> guaranteed Verifier failure. You should be using the
NT_SUCCESS(status)
> macro instead, since there are many “success” status values that can
be
> returned and will fail (STATUS_SUCCESS == status).
>
> Gary G. Little
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of
> xxxxx@logique.jussieu.fr
> Sent: Monday, February 13, 2006 9:25 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] IoGetDeviceObjectPointer return
>
> Does IoGetDeviceObjectPointer can return other status than
>
> STATUS_SUCCESS
> STATUS_OBJECT_TYPE_MISMATCH
> STATUS_INVALID_PARAMETER
> STATUS_PRIVILEGE_NOT_HELD
> STATUS_INSUFFICIENT_RESOURCES
> STATUS_OBJECT_NAME_INVALID
>
> thanks
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@seagate.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
If your point is that, over the years, NT has grown to include a confusing set of status codes and some of these are warnings and informational statuses when you expect them to be errors… then I concede your point.
However, to your SPECIFIC point:
The bigger problem is when you think of another function like IoCreateDevice. This function can return STATUS_OBJECT_NAME_EXISTS which is a success according to NT_SUCCESS but it is actually a failure.
IoCreateDevice *does not* return STATUS_OBJECT_NAME_EXISTS in any way that I can determine. Rather, when attempting to create a device and using a name that’s already in use, I can assure you that you get back STATUS_OBJECT_NAME_COLLISION, which is indeed an error status.
So, yes, the DDK docs are in error (both in terms of this error being returned from IoCreateDevice and in terming this a “failure code”, which it most certainly is not).
You have to be careful about assuming too much about these return status values. STATUS_OBJECT_NAME_EXISTS is meant to be used ONLY when a function succeeds and you want to return additional information (the fact that the object already existed).
Confusing to a newbie? Yes. Confusing to an experienced driver writer? Yes, sometimes.
Peter
OSR
I think that it can return any status code which ZwCreateFile (called
internally) can return. In fact, nobody should rely on any function returning
only these status codes and not the other ones.
I think that it, for instance, will return STATUS_ACCESS_VIOLATION if the
file name references the junk memory location, and so on.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “Sedki Boughattas”
To: “Windows System Software Devs Interest List”
Sent: Monday, February 13, 2006 6:24 PM
Subject: [ntdev] IoGetDeviceObjectPointer return
> Does IoGetDeviceObjectPointer can return other status than
>
> STATUS_SUCCESS
> STATUS_OBJECT_TYPE_MISMATCH
> STATUS_INVALID_PARAMETER
> STATUS_PRIVILEGE_NOT_HELD
> STATUS_INSUFFICIENT_RESOURCES
> STATUS_OBJECT_NAME_INVALID
>
> thanks
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>although there are exceptions. Given the massive prevalence of
NT_SUCCESS usage in the code base, you are going to have to come up with
Yes, but at least propagate the error code to the user app. Usually, the exact
meaning of the NTSTATUS failure code is only relevant in RtlNtStatusToDosError
routine in user-mode NTDLL.DLL 
and the resulting Win32 error code is only
used in FormatMessage function and the UI
There are some exceptions (like “try next device name if this one already
exists”), but they are rare.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com