Unexpected IOCTL behaviour

shakti_sinha-2 · January 27, 2014, 1:30pm

Hi,

I’ve written a simple IOCTL handler in my driver.

enum status stat = STAT_TEST; //STAT_TEST = 0Xf

RtlZeroMemory(out_buf,out_buf_len);
RtlCopyMemory(out_buf,&stat,sizeof(enum status));

When I print out_buf in the application, it gives me a value of -858993460.
Any status returned, other than 0x0, is printed as -858993460.

Any pointer is appreciated.

Thanks

Tim_Roberts · January 27, 2014, 1:34pm

xxxxx@rediff.com wrote:

I’ve written a simple IOCTL handler in my driver.

enum status stat = STAT_TEST; //STAT_TEST = 0Xf

RtlZeroMemory(out_buf,out_buf_len);
RtlCopyMemory(out_buf,&stat,sizeof(enum status));

When I print out_buf in the application, it gives me a value of -858993460.
Any status returned, other than 0x0, is printed as -858993460.

That’s 0xCCCCCCCC. That’s the value used by the C compiler to seed
uninitialized memory.

Did you set the IRP’s IoStatus.Information field to “sizeof(enum
status)”? You have to tell it how much data you are returning.

By the way, the size of an “enum” is not predictable. It’s entirely up
to the compiler. You should use “unsigned int” or “ULONG”.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

shakti_sinha-2 · January 27, 2014, 3:16pm

Yes Tim, I’m setting the IoStatus.Information.

One observation I made is that, if I pass STATUS_SUCCESS as the NT status, then the output buffer is proper in the application.
But if the status is not STATUS_SUCCESS, then output buffer and no of bytes written are -858993460 in the application.

Why will the IO subsytem do that?

Doron_Holan · January 27, 2014, 3:25pm

NT_SUCCESS() must be true for the output buffer to be copied

d

Dent from my phone

From: xxxxx@rediff.com mailto:xxxxx
Sent: ?1/?27/?2014 12:16 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE:[ntdev] Unexpected IOCTL behaviour

Yes Tim, I’m setting the IoStatus.Information.

One observation I made is that, if I pass STATUS_SUCCESS as the NT status, then the output buffer is proper in the application.
But if the status is not STATUS_SUCCESS, then output buffer and no of bytes written are -858993460 in the application.

Why will the IO subsytem do that?

—
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx></mailto:xxxxx>

OSR_Community_User · January 28, 2014, 2:43am

I’m curious why you think -858993460 is a useful number to display. What
good is it? What does it tell you? Nothing whatsoever. But if you
display it in hex, you get 0xCCCCCCCC, which means it is an uninitialized
local variable. Big surprise. The length hasn’t been stored if the call
returns an error. This would have been obvious had you thought beyond
decimal. (For that matter, how did you get this value displayed? You did
declare the value as a DWORD, right? The debugger tends to display DWORDs
in hex).

Whenever you get a weird-looking number, especially a negative number,
your very first step should be to display it in hex. And when you give us
the number in a post like this, show the hex value. That has meaning.
Decimal values rarely have meaning when they are large negative numbers.

joe

NT_SUCCESS() must be true for the output buffer to be copied

d

Dent from my phone

From: xxxxx@rediff.com mailto:xxxxx
> Sent: ý1/ý27/ý2014 12:16 PM
> To: Windows System Software Devs Interest Listmailto:xxxxx
> Subject: RE:[ntdev] Unexpected IOCTL behaviour
>
> Yes Tim, I’m setting the IoStatus.Information.
>
> One observation I made is that, if I pass STATUS_SUCCESS as the NT status,
> then the output buffer is proper in the application.
> But if the status is not STATUS_SUCCESS, then output buffer and no of
> bytes written are -858993460 in the application.
>
> Why will the IO subsytem do that?
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx></mailto:xxxxx>

OSR_Community_User · January 28, 2014, 2:46am

> Yes Tim, I’m setting the IoStatus.Information.

One observation I made is that, if I pass STATUS_SUCCESS as the NT status,
then the output buffer is proper in the application.
But if the status is not STATUS_SUCCESS, then output buffer and no of
bytes written are -858993460 in the application.

Why will the IO subsytem do that?

As I already observed, you actually are seeing EXPECTED IOCTL behavior if
you pass some non-success code back. In fact, it is the DOCUMENTED
behavior.
joe

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

OSR_Community_User · January 28, 2014, 2:52am

> Hi,

I’ve written a simple IOCTL handler in my driver.

enum status stat = STAT_TEST; //STAT_TEST = 0Xf

RtlZeroMemory(out_buf,out_buf_len);
RtlCopyMemory(out_buf,&stat,sizeof(enum status));

When I print out_buf in the application, it gives me a value of
-858993460.
Any status returned, other than 0x0, is printed as -858993460.

Any pointer is appreciated.

As has already been pointed out, this makes no sense as a decimal number,
but is obvious if you print it in hex.

Note that this is the value that the Debug mode applications use to
initialize /stack/ memory. Uninitialized heap is (I think) 0xCDCDCDCD,
and free memory is overwritten as 0xFEEEFEEE. So keep in mind that
decimal values are unlikely to give you any insight into what is going on.
joe

Thanks

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

anton_bassov · January 28, 2014, 6:17am

> Note that this is the value that the Debug mode applications use to initialize /stack/ memory. Uninitialized

heap is (I think) 0xCDCDCDCD, and free memory is overwritten as 0xFEEEFEEE

Actually, I have always thought the choice of 0xCCCCCCCC is rooted in the fact that 0xCC is an opcode for INT3
debug exception. Am I wrong?

Anton Bassov

OSR_Community_User · January 28, 2014, 2:41pm

That might well be the reason; an attempt to transfer control into the
stack might have a high probability of hitting this. But I wanted to
point out that “uninitialized variable” has different meanings depending
on where it is located.
joe

> Note that this is the value that the Debug mode applications use to
> initialize /stack/ memory. Uninitialized
> heap is (I think) 0xCDCDCDCD, and free memory is overwritten as
> 0xFEEEFEEE

Actually, I have always thought the choice of 0xCCCCCCCC is rooted in the
fact that 0xCC is an opcode for INT3
debug exception. Am I wrong?

Anton Bassov

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

shakti_sinha-2 · January 30, 2014, 12:25am

Thank you all for the replies.
I’ll make sure to deal with HEX values in future.

OSR_Community_User · February 1, 2014, 6:29pm

The important thing is that you show in hex those values which make sense
in hex, and in decimal those values which make sense in decimal. The key
here is that very large negative numbers have to be considered in hex as
their natural representation.
joe

Thank you all for the replies.
I’ll make sure to deal with HEX values in future.

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer