BugCheck in TDI Filter TDI_RECEIVE Completion.

Have some very simple code but it is Bug Checking from time to time.
Seems to be trouble with MDL.


if(*IoRequestPacket && (STATUS_MORE_PROCESSING_REQUIRED == status))
{
//do set up the filters completion routine and call it
IrpStack->CompletionRoutine = F_RECV_COMPLETION_ROUTINE ;
}

F_RECV_COMPLETION_ROUTINE(
IN PDEVICE_OBJECT DeviceObject,
IN PIRP pIrp,
IN PVOID Context
)
{
PMDL pMDL = pIrp->MdlAddress ;
if(pMDL)
ulBytes = MmGetMdlByteCount(pMDL) ;
//call original Completion afterwards...
}

Bug Checks vary from DRIVER_IRQL... to IRQL_NOT_LESS...

Do I miss something? Since I am only filtering, I supposed that the MDL was
already locked.

VijenderYadav
Wed Oct 27 06:03:01 CDT 2004

Hi all,

I am also having problems with AFd.SYS.

When I call AFD's ClientEventReceive, most of the times it returns
STATUS_SUCCESS. But sometimes it returns STATUS_MORE_PROCESSING_REQUIRED and
pass me a receiv irp .

I extract the buffer from associated MDL using MmGetMdlVirtualAddress. But
some times I get an invalid address here. On analyzing the irp, it seems AFD
is just locking the MDL and is not mapping it to system space. Since i get
the buffer in arbit thread context, my driver crashes when I try to access
it. And this happens very rarely.


Regards
Vijender


"Jeff Runaway" wrote:

> Have some very simple code but it is Bug Checking from time to time.
> Seems to be trouble with MDL.
>
>
> if(*IoRequestPacket && (STATUS_MORE_PROCESSING_REQUIRED == status))
> {
> //do set up the filters completion routine and call it
> IrpStack->CompletionRoutine = F_RECV_COMPLETION_ROUTINE ;
> }
>
> F_RECV_COMPLETION_ROUTINE(
> IN PDEVICE_OBJECT DeviceObject,
> IN PIRP pIrp,
> IN PVOID Context
> )
> {
> PMDL pMDL = pIrp->MdlAddress ;
> if(pMDL)
> ulBytes = MmGetMdlByteCount(pMDL) ;
> //call original Completion afterwards...
> }
>
> Bug Checks vary from DRIVER_IRQL... to IRQL_NOT_LESS...
>
> Do I miss something? Since I am only filtering, I supposed that the MDL was
> already locked.
>
>
>

Eliyas
Wed Oct 27 11:14:19 CDT 2004

Why are you calling MmGetMdlVirtualAddress in the first place? This call
returns the actual address (typically the usermode address in your case)
that was used to describe the MDL and is valid as long as you are with in
that user process context. No matter whether AFD maps the MDL to system
address space or not, the address returned by this call is going to be
always the same. So you crash while accessing this address as soon as you
fall out of the process context - and that happens to you once in a while.
Long story short, you should use MmGetSystemAddressForMdl instead of
MmGetMdlVirtualAddress.

--
-Eliyas
This posting is provided "AS IS" with no warranties, and confers no rights.
http://www.microsoft.com/whdc/hwdev/driver/kb-drv.mspx

VijenderYadav
Wed Oct 27 14:55:03 CDT 2004

Hi,

After analyzing the problem, I also concluded to use
MmGetSystemAddressForMdl or MmGetSystemAddressForMdlSafe. But I have one
doubt. If the MDL ws not mapped by AFD, this call will map it to system
space. My doubt is that dont I need to unmap these pages when I am done.

Regards
Vijender

"Eliyas Yakub [MSFT]" wrote:

> Why are you calling MmGetMdlVirtualAddress in the first place? This call
> returns the actual address (typically the usermode address in your case)
> that was used to describe the MDL and is valid as long as you are with in
> that user process context. No matter whether AFD maps the MDL to system
> address space or not, the address returned by this call is going to be
> always the same. So you crash while accessing this address as soon as you
> fall out of the process context - and that happens to you once in a while.
> Long story short, you should use MmGetSystemAddressForMdl instead of
> MmGetMdlVirtualAddress.
>
> --
> -Eliyas
> This posting is provided "AS IS" with no warranties, and confers no rights.
> http://www.microsoft.com/whdc/hwdev/driver/kb-drv.mspx
>
>
>

Peter
Thu Oct 28 11:18:46 CDT 2004

If you're mapping Irp->MdlAddress then you don't need to unmap it when
you're done. Whoever created the MDL will take care of that.

If you're mapping your own MDL, then you should unmap it when you're done.

-p

--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Vijender Yadav" <VijenderYadav@discussions.microsoft.com> wrote in message
news:4C6DA566-E601-4FF2-BA4D-432033422253@microsoft.com...
> Hi,
>
> After analyzing the problem, I also concluded to use
> MmGetSystemAddressForMdl or MmGetSystemAddressForMdlSafe. But I have one
> doubt. If the MDL ws not mapped by AFD, this call will map it to system
> space. My doubt is that dont I need to unmap these pages when I am done.
>
> Regards
> Vijender
>
> "Eliyas Yakub [MSFT]" wrote:
>
>> Why are you calling MmGetMdlVirtualAddress in the first place? This call
>> returns the actual address (typically the usermode address in your case)
>> that was used to describe the MDL and is valid as long as you are with in
>> that user process context. No matter whether AFD maps the MDL to system
>> address space or not, the address returned by this call is going to be
>> always the same. So you crash while accessing this address as soon as
>> you
>> fall out of the process context - and that happens to you once in a
>> while.
>> Long story short, you should use MmGetSystemAddressForMdl instead of
>> MmGetMdlVirtualAddress.
>>
>> --
>> -Eliyas
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>> http://www.microsoft.com/whdc/hwdev/driver/kb-drv.mspx
>>
>>
>>