FileObject in CR

NTDEV
1

Hi All

In the Completion Routine I have written foll code

/////////////

pIrpStkLoc = IoGetCurrentIrpStackLocation ( pIrp ) ;
if ( NULL != pIrpStkLoc )
{
MyDbgPrint (( “pFileObject : (%u)” , pIrpStkLoc->FileObject )) ;
}

////////////

But it generates Bug Check 0xD6: DRIVER_PAGE_FAULT_BEYOND_END_OF_ALLOCATION.

Can we not access FileObject in CR ?

Thanks
Abhijit

2

Bug check D6 is a Driver Verifier one, and it’s caused by accessing past the
end of the allocation (as it says).

I don’t think it makes any difference WHERE the access is done. Here’s why:

  • The way that Driver Verifier catches accesses past the end of the buffer
    is by allocating any block smaller than a page at the end of a page (say you
    allocate 100 bytes, the allocation will be made at the last 100 bytes of the
    page, rather than the beginning of it).
  • The next page after the allocated page is left INVALID, which means that
    code that whatever the reason is, goes beyond the page will cause a
    page-fault.
  • Driver verifier keeps track of it’s allocations, and when a page fault
    happens, it looks at the page that faulted and says “Oh, that just after the
    page that I allocated, let’s make it a D6”.

So, if you can access FileObject anywhere else, you should be able to do it
in the completion routine.

If it was a problem with IRQL (or any other dependancy of WHERE in the
code), it would not be a D6 bug-check.

Of course, it’s technically possible that the result from
IoGetCurrentIrpStackLocation returns a short version of pIrpStkLoc under
some circumstances, and that the FileObject shouldn’t be accessed here.
Someone who knows more about this would have to comment on that.

–
Mats

-----Original Message-----
From: Abhijit [mailto:xxxxx@yahoo.com]
Sent: Tuesday, May 18, 2004 3:08 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] FileObject in CR

Hi All

In the Completion Routine I have written foll code

/////////////

pIrpStkLoc = IoGetCurrentIrpStackLocation ( pIrp ) ;
if ( NULL != pIrpStkLoc )
{
MyDbgPrint (( “pFileObject : (%u)” , pIrpStkLoc->FileObject )) ;
}

////////////

But it generates Bug Check 0xD6: DRIVER_PAGE_FAULT_BEYOND_END_OF_ALLOCATION.

Can we not access FileObject in CR ?

Thanks
Abhijit

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@3dlabs.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

Is this an IRP youallocated yourself? What does !irp tell you about the current stack location (ie what is the max, what is the current)?

If you did allocate this irp yourself, when your completion routine runs, there are no current irp stack locations (since you are the owner of the irp). This is the same reason why the PDEVICE_OBJECT passed in is also NULL. There are a few ways to get around this, the easiest being allocating an IRP with a StackSize+1, setting the next stack location and then setting your completion routine.

d

________________________________________
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@3Dlabs.com
Sent: Tuesday, May 18, 2004 7:24 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] FileObject in CR

Bug check D6 is a Driver Verifier one, and it’s caused by accessing past the end of the allocation (as it says).
?
I don’t think it makes any difference WHERE the access is done. Here’s why:
?
- The way that Driver Verifier catches accesses past the end of the buffer is by allocating any block smaller than a page at the end of a page (say you allocate 100 bytes, the allocation will be made at the last 100 bytes of the page, rather than the beginning of it).
- The next page after the allocated page is left INVALID, which means that code that whatever the reason is, goes beyond the page will cause a page-fault.
- Driver verifier keeps track of it’s allocations, and when a page fault happens, it looks at the page that faulted and says “Oh, that just after the page that I allocated, let’s make it a D6”.
?
So, if you can access FileObject anywhere else, you should be able to do it in the completion routine.
?
If it was a problem with IRQL (or any other dependancy of WHERE in the code), it would not be a D6 bug-check.
?
Of course, it’s technically possible that the result from IoGetCurrentIrpStackLocation returns a short version of pIrpStkLoc under some circumstances, and that the FileObject shouldn’t be accessed here. Someone who knows more about this would have to comment on that.
?
–
Mats
-----Original Message-----
From: Abhijit [mailto:xxxxx@yahoo.com]
Sent: Tuesday, May 18, 2004 3:08 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] FileObject in CR
Hi All
?
In the Completion Routine I have written foll code
?
?
/////////////
?
pIrpStkLoc = IoGetCurrentIrpStackLocation ( pIrp ) ;
if ( NULL != pIrpStkLoc )
{
??? ??MyDbgPrint (( “pFileObject : (%u)” , pIrpStkLoc->FileObject )) ;
}
?
////////////
?
But it generates Bug Check 0xD6: DRIVER_PAGE_FAULT_BEYOND_END_OF_ALLOCATION.
?
Can we not access FileObject in CR ?
?
Thanks
Abhijit
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@3dlabs.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@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

4

Is the Completion routine for a driver in the stack or for the IRP
originator?
Please note the originator doesn’t have a stack location by default although
IoGetCurrentStackLocation will return NON-NULL which points to the end of
the IRP.

You can try kd>!irp xxxxxxxx to verify if the stack is valid.

Good luck,
Calvin

Calvin Guan Software Engineer
ATI Technologies Inc. www.ati.com

-----Original Message-----
From: Abhijit [mailto:xxxxx@yahoo.com]
Sent: Tuesday, May 18, 2004 10:08 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] FileObject in CR

Hi All

In the Completion Routine I have written foll code

/////////////

pIrpStkLoc = IoGetCurrentIrpStackLocation ( pIrp ) ;
if ( NULL != pIrpStkLoc )
{
MyDbgPrint (( “pFileObject : (%u)” , pIrpStkLoc->FileObject )) ;
}

////////////

But it generates Bug Check 0xD6: DRIVER_PAGE_FAULT_BEYOND_END_OF_ALLOCATION.

Can we not access FileObject in CR ?

Thanks
Abhijit

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@ati.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

5

Thanks All.

I had allocated the IRP using TdiBuildInternalDeviceControlIrp which is a macro around
IoBuildDeviceIoControlRequest, which doesn’t allocate stack location for the creator.

IoGetCurrentIrpStackLocation returning NON-NULL pointer confused me. It made me think that the stack location is OK but the FileObject cannot be accessed. Huuhh !!

One more query: !irp produced foll output

kd> !irp 844dff68
Irp is active with 1 stacks 2 is current (= 0x844dfffc)
Mdl = 80e984d0 Thread 80f333d0: Irp is completed.
cmd flg cl Device File Completion-Context
[f, 0] 0 10 80e61448 00000000 f955bf60-844e1ff8

Does the second line (Irp is active with 1 stacks 2 is current (= 0x844dfffc))
means that “The IRP has 1 stack location and I am trying to access the second stack location.”

Thanks again
Abhijit.

“Abhijit” wrote in message news:xxxxx@ntdev…
Hi All

In the Completion Routine I have written foll code

/////////////

pIrpStkLoc = IoGetCurrentIrpStackLocation ( pIrp ) ;
if ( NULL != pIrpStkLoc )
{
MyDbgPrint (( “pFileObject : (%u)” , pIrpStkLoc->FileObject )) ;
}

////////////

But it generates Bug Check 0xD6: DRIVER_PAGE_FAULT_BEYOND_END_OF_ALLOCATION.

Can we not access FileObject in CR ?

Thanks
Abhijit

6

Yes, the output of !irp verifies that the current irp stack location is one past the end, ie it is invalid.

d

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Abhijit
Sent: Tuesday, May 18, 2004 10:22 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] FileObject in CR

Thanks All.
?
I had allocated the IRP using TdiBuildInternalDeviceControlIrp which is a macro around
IoBuildDeviceIoControlRequest, which doesn’t allocate stack location for the creator.
?
IoGetCurrentIrpStackLocation returning NON-NULL pointer confused me. It made me think that the stack location is OK but the FileObject cannot be accessed. Huuhh !!
?
?
One more query: !irp produced foll output
?
kd> !irp 844dff68
Irp is active with 1 stacks 2 is current (= 0x844dfffc)
?Mdl = 80e984d0 Thread 80f333d0:? Irp is completed.?
??? cmd? flg cl Device?? File??? Completion-Context
?[? f, 0]?? 0 10 80e61448 00000000 f955bf60-844e1ff8???
?
Does the second line (Irp is active with 1 stacks 2 is current (= 0x844dfffc))
means that “The IRP has 1 stack location and I am trying to access the second stack location.”
?
?
Thanks again
Abhijit.
?
?
?
“Abhijit” wrote in message news:xxxxx@ntdev…
Hi All
?
In the Completion Routine I have written foll code
?
?
/////////////
?
pIrpStkLoc = IoGetCurrentIrpStackLocation ( pIrp ) ;
if ( NULL != pIrpStkLoc )
{
??? ??MyDbgPrint (( “pFileObject : (%u)” , pIrpStkLoc->FileObject )) ;
}
?
////////////
?
But it generates Bug Check 0xD6: DRIVER_PAGE_FAULT_BEYOND_END_OF_ALLOCATION.
?
Can we not access FileObject in CR ?
?
Thanks
Abhijit
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

7

I think the issue is a small misunderstanding in how
IoGetCurrentIrpStackLocation() works – it doesn’t return NULL, but
presumes that you have allocated sufficient stack space. Look at the
macro as it is defined in the headers.

Therefore, your check for NULL won’t ever fire. This means that, should
you not have a valid stack location, you would then be dereferencing an
invalid memory location when attempting to check the FileObject.

Hth,
.

-----Original Message-----
From: Abhijit [mailto:xxxxx@yahoo.com]
Sent: Tuesday, May 18, 2004 7:08 AM
Subject: FileObject in CR

Hi All

In the Completion Routine I have written foll code

/////////////

pIrpStkLoc = IoGetCurrentIrpStackLocation ( pIrp ) ;
if ( NULL != pIrpStkLoc )
{
MyDbgPrint (( “pFileObject : (%u)” , pIrpStkLoc->FileObject )) ;
}

////////////

But it generates Bug Check 0xD6:
DRIVER_PAGE_FAULT_BEYOND_END_OF_ALLOCATION.

Can we not access FileObject in CR ?

Thanks
Abhijit