Bsod 0x1a while calling IOCTL_SCSI_PASS_THROUGH_DIRECT

NTDEV
1

Hi,

On Windows 2012 server I am getting the following Bsod
Bugcheck - MEMORY_MANAGEMENT (1a)
Arg1: 0000000000061946

Due to some reason, need to use IOCTL_SCSI_PASSTHROUGH_DIRECT to read data
from the below scsi device instead of calling IRP_MJ_READ on the lower
device.
I mapped the Mdl received in my driver(DO_DIRECT_IO) to system space
address by calling MmGetSystemAddressForMdlSafe() and passed this system
space address to below driver.
SCSI_PASS_THROUGH_DIRECT.DataBuffer =
MmGetSystemAddressForMdlSafe(Mdl received in my driver)

But the host crashed with the following stack :frowning:

* # Call Site*
*00 nt!KeBugCheckEx*
*01 nt! ?? ::FNODOBFM::`string’*
*02 nt!MmProbeAndLockPages*
*03 storport!PortPassThroughBuildIrp*
*04 storport!PortPassThroughSendAsync*
*05 storport!PortPassThroughExSendAsync*
*06 storport!RaidAdapterPassThrough*
*07 storport!RaidAdapterDeviceControlIrp*
*08 storport!RaDriverDeviceControlIrp*
*09 storport!RaUnitScsiPassThroughIoctl*
*0a storport!RaUnitDeviceControlIrp*
*0b storport!RaDriverDeviceControlIrp*
*0c CLASSPNP!ClassDeviceControl*
*0d disk!DiskDeviceControl*
*0e CLASSPNP!ClassDeviceControlDispatch*

Is any extra handling is required while passing the mapped buffer to below
driver?

Thanks,
-Vipul.

2

Have you searched the archives for this bugcheck? It’s come up several
times, Pavel Lebedinksy explained it clearly here:

http://www.osronline.com/ShowThread.cfm?link=240647

-scott
OSR
@OSRDrivers

“Vipul” wrote in message news:xxxxx@ntdev…
Hi,

On Windows 2012 server I am getting the following Bsod
Bugcheck - MEMORY_MANAGEMENT (1a)
Arg1: 0000000000061946

Due to some reason, need to use IOCTL_SCSI_PASSTHROUGH_DIRECT to read data
from the below scsi device instead of calling IRP_MJ_READ on the lower
device.
I mapped the Mdl received in my driver(DO_DIRECT_IO) to system space address
by calling MmGetSystemAddressForMdlSafe() and passed this system space
address to below driver.
SCSI_PASS_THROUGH_DIRECT.DataBuffer =
MmGetSystemAddressForMdlSafe(Mdl received in my driver)

But the host crashed with the following stack :frowning:

# Call Site
00 nt!KeBugCheckEx
01 nt! ?? ::FNODOBFM::`string’
02 nt!MmProbeAndLockPages
03 storport!PortPassThroughBuildIrp
04 storport!PortPassThroughSendAsync
05 storport!PortPassThroughExSendAsync
06 storport!RaidAdapterPassThrough
07 storport!RaidAdapterDeviceControlIrp
08 storport!RaDriverDeviceControlIrp
09 storport!RaUnitScsiPassThroughIoctl
0a storport!RaUnitDeviceControlIrp
0b storport!RaDriverDeviceControlIrp
0c CLASSPNP!ClassDeviceControl
0d disk!DiskDeviceControl
0e CLASSPNP!ClassDeviceControlDispatch

Is any extra handling is required while passing the mapped buffer to below
driver?

Thanks,
-Vipul.

3

> Hi,

On Windows 2012 server I am getting the following Bsod
Bugcheck - MEMORY_MANAGEMENT (1a)
Arg1: 0000000000061946

Due to some reason, need to use IOCTL_SCSI_PASSTHROUGH_DIRECT to read data
from the below scsi device instead of calling IRP_MJ_READ on the lower
device.
I mapped the Mdl received in my driver(DO_DIRECT_IO) to system space
address by calling MmGetSystemAddressForMdlSafe() and passed this system
space address to below driver.
SCSI_PASS_THROUGH_DIRECT.DataBuffer =
MmGetSystemAddressForMdlSafe(Mdl received in my driver)

There is no guarantee this will work. Did you check the .DataBuffer to
see if it has a valid address? It will either have a valid address or
NULL. If it is NULL, you are going to have problems. The stack is not
the most useful part; include the entire !analyze -v output!

Note that an earlier bug could have damaged storage headers and this is
the first chance the allocator had to discover this damage. Therefore, it
may not be correlated with what you are doing, but what you may have
already done in some totally unrelated execution path in your driver.

Did you run driver verifier? If you did, did you enable special pools?
joe

But the host crashed with the following stack :frowning:

* # Call Site*
*00 nt!KeBugCheckEx*
*01 nt! ?? ::FNODOBFM::`string’*
*02 nt!MmProbeAndLockPages*
*03 storport!PortPassThroughBuildIrp*
*04 storport!PortPassThroughSendAsync*
*05 storport!PortPassThroughExSendAsync*
*06 storport!RaidAdapterPassThrough*
*07 storport!RaidAdapterDeviceControlIrp*
*08 storport!RaDriverDeviceControlIrp*
*09 storport!RaUnitScsiPassThroughIoctl*
*0a storport!RaUnitDeviceControlIrp*
*0b storport!RaDriverDeviceControlIrp*
*0c CLASSPNP!ClassDeviceControl*
*0d disk!DiskDeviceControl*
*0e CLASSPNP!ClassDeviceControlDispatch*

Is any extra handling is required while passing the mapped buffer to below
driver?

Thanks,
-Vipul.

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

4

The bugcheck code that OP is experiencing is in the post. It is a *very*
specific bugcheck code added to Windows 8 for a very specific issue. it has
nothing to do with NULL pointers nor does it have anything to do with the
Executive pool allocator. See the link that I posted.

-scott
OSR
@OSRDrivers

wrote in message news:xxxxx@ntdev…

Hi,

On Windows 2012 server I am getting the following Bsod
Bugcheck - MEMORY_MANAGEMENT (1a)
Arg1: 0000000000061946

Due to some reason, need to use IOCTL_SCSI_PASSTHROUGH_DIRECT to read data
from the below scsi device instead of calling IRP_MJ_READ on the lower
device.
I mapped the Mdl received in my driver(DO_DIRECT_IO) to system space
address by calling MmGetSystemAddressForMdlSafe() and passed this system
space address to below driver.
SCSI_PASS_THROUGH_DIRECT.DataBuffer =
MmGetSystemAddressForMdlSafe(Mdl received in my driver)

There is no guarantee this will work. Did you check the .DataBuffer to
see if it has a valid address? It will either have a valid address or
NULL. If it is NULL, you are going to have problems. The stack is not
the most useful part; include the entire !analyze -v output!

Note that an earlier bug could have damaged storage headers and this is
the first chance the allocator had to discover this damage. Therefore, it
may not be correlated with what you are doing, but what you may have
already done in some totally unrelated execution path in your driver.

Did you run driver verifier? If you did, did you enable special pools?
joe

But the host crashed with the following stack :frowning:

* # Call Site*
*00 nt!KeBugCheckEx*
*01 nt! ?? ::FNODOBFM::`string’*
*02 nt!MmProbeAndLockPages*
*03 storport!PortPassThroughBuildIrp*
*04 storport!PortPassThroughSendAsync*
*05 storport!PortPassThroughExSendAsync*
*06 storport!RaidAdapterPassThrough*
*07 storport!RaidAdapterDeviceControlIrp*
*08 storport!RaDriverDeviceControlIrp*
*09 storport!RaUnitScsiPassThroughIoctl*
*0a storport!RaUnitDeviceControlIrp*
*0b storport!RaDriverDeviceControlIrp*
*0c CLASSPNP!ClassDeviceControl*
*0d disk!DiskDeviceControl*
*0e CLASSPNP!ClassDeviceControlDispatch*

Is any extra handling is required while passing the mapped buffer to below
driver?

Thanks,
-Vipul.

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

5

> [quote]

The stack is not the most useful part; include the entire !analyze -v
output!
[/quote]

The bugcheck code that OP is experiencing is in the post. It is a *very*
specific bugcheck code added to Windows 8 for a very specific issue. it
has
nothing to do with NULL pointers nor does it have anything to do with the
Executive pool allocator. See the link that I posted.

Yes, I saw that after I replied. I had not seen this before, so it looked
like a classic memory-damage report.
joe

-scott
OSR
@OSRDrivers

wrote in message news:xxxxx@ntdev…

> Hi,
>
> On Windows 2012 server I am getting the following Bsod
> Bugcheck - MEMORY_MANAGEMENT (1a)
> Arg1: 0000000000061946
>
> Due to some reason, need to use IOCTL_SCSI_PASSTHROUGH_DIRECT to read
> data
> from the below scsi device instead of calling IRP_MJ_READ on the lower
> device.
> I mapped the Mdl received in my driver(DO_DIRECT_IO) to system space
> address by calling MmGetSystemAddressForMdlSafe() and passed this system
> space address to below driver.
> SCSI_PASS_THROUGH_DIRECT.DataBuffer =
> MmGetSystemAddressForMdlSafe(Mdl received in my driver)

There is no guarantee this will work. Did you check the .DataBuffer to
see if it has a valid address? It will either have a valid address or
NULL. If it is NULL, you are going to have problems. The stack is not
the most useful part; include the entire !analyze -v output!

Note that an earlier bug could have damaged storage headers and this is
the first chance the allocator had to discover this damage. Therefore, it
may not be correlated with what you are doing, but what you may have
already done in some totally unrelated execution path in your driver.

Did you run driver verifier? If you did, did you enable special pools?
joe

>
> But the host crashed with the following stack :frowning:
>
> * # Call Site*
> *00 nt!KeBugCheckEx*
> *01 nt! ?? ::FNODOBFM::`string’*
> *02 nt!MmProbeAndLockPages*
> *03 storport!PortPassThroughBuildIrp*
> *04 storport!PortPassThroughSendAsync*
> *05 storport!PortPassThroughExSendAsync*
> *06 storport!RaidAdapterPassThrough*
> *07 storport!RaidAdapterDeviceControlIrp*
> *08 storport!RaDriverDeviceControlIrp*
> *09 storport!RaUnitScsiPassThroughIoctl*
> *0a storport!RaUnitDeviceControlIrp*
> *0b storport!RaDriverDeviceControlIrp*
> *0c CLASSPNP!ClassDeviceControl*
> *0d disk!DiskDeviceControl*
> *0e CLASSPNP!ClassDeviceControlDispatch*
>
> Is any extra handling is required while passing the mapped buffer to
> below
> driver?
>
> Thanks,
> -Vipul.
>
> —
> 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

6

Hi Scott,

After going through the link, it mentions that we need to reuse the mdl
while sending it to the lower level driver.
In case of SCSI_PASSTHROUGH_DIRECT it expects an buffer address. Not sure
how we can pass an MDL?
I’ll try to set the irp->MdlAddress with the mdl received in my driver (to
reuse the mdl)

Anyways will perform the debug exercise as mentioned in the link to confirm
the behavior…

Regards,
-Vipul.

On Wed, Apr 23, 2014 at 9:59 AM, wrote:

> >


> >
> > The bugcheck code that OP is experiencing is in the post. It is a very
> > specific bugcheck code added to Windows 8 for a very specific issue. it
> > has
> > nothing to do with NULL pointers nor does it have anything to do with the
> > Executive pool allocator. See the link that I posted.
>
> Yes, I saw that after I replied. I had not seen this before, so it looked
> like a classic memory-damage report.
> joe
> >
> > -scott
> > OSR
> > @OSRDrivers
> >
> >
> > wrote in message news:xxxxx@ntdev…
> >
> >> Hi,
> >>
> >> On Windows 2012 server I am getting the following Bsod
> >> Bugcheck - MEMORY_MANAGEMENT (1a)
> >> Arg1: 0000000000061946
> >>
> >> Due to some reason, need to use IOCTL_SCSI_PASSTHROUGH_DIRECT to read
> >> data
> >> from the below scsi device instead of calling IRP_MJ_READ on the lower
> >> device.
> >> I mapped the Mdl received in my driver(DO_DIRECT_IO) to system space
> >> address by calling MmGetSystemAddressForMdlSafe() and passed this system
> >> space address to below driver.
> >> SCSI_PASS_THROUGH_DIRECT.DataBuffer =
> >> MmGetSystemAddressForMdlSafe(Mdl received in my driver)
> >
> > There is no guarantee this will work. Did you check the .DataBuffer to
> > see if it has a valid address? It will either have a valid address or
> > NULL. If it is NULL, you are going to have problems. The stack is not
> > the most useful part; include the entire !analyze -v output!
> >
> > Note that an earlier bug could have damaged storage headers and this is
> > the first chance the allocator had to discover this damage. Therefore,
> it
> > may not be correlated with what you are doing, but what you may have
> > already done in some totally unrelated execution path in your driver.
> >
> > Did you run driver verifier? If you did, did you enable special pools?
> > joe
> >
> >>
> >> But the host crashed with the following stack :frowning:
> >>
> >> * # Call Site*
> >> 00 nt!KeBugCheckEx
> >> 01 nt! ?? ::FNODOBFM::`string’
> >> 02 nt!MmProbeAndLockPages
> >> 03 storport!PortPassThroughBuildIrp
> >> 04 storport!PortPassThroughSendAsync
> >> 05 storport!PortPassThroughExSendAsync
> >> 06 storport!RaidAdapterPassThrough
> >> 07 storport!RaidAdapterDeviceControlIrp
> >> 08 storport!RaDriverDeviceControlIrp
> >> 09 storport!RaUnitScsiPassThroughIoctl
> >> 0a storport!RaUnitDeviceControlIrp
> >> 0b storport!RaDriverDeviceControlIrp
> >> 0c CLASSPNP!ClassDeviceControl
> >> 0d disk!DiskDeviceControl
> >> 0e CLASSPNP!ClassDeviceControlDispatch
> >>
> >> Is any extra handling is required while passing the mapped buffer to
> >> below
> >> driver?
> >>
> >> Thanks,
> >> -Vipul.
> >>
> >> —
> >> 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
> >
>
>
>
> —
> 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
>

7

I’m not aware of any way to supply your own MDL to a SCSI pass through
operation. I suspect that the only legitimate way you could make this work
would be to double buffer the read operation.

-scott
OSR
@OSRDrivers

“Vipul” wrote in message news:xxxxx@ntdev…
Hi Scott,

After going through the link, it mentions that we need to reuse the mdl
while sending it to the lower level driver.
In case of SCSI_PASSTHROUGH_DIRECT it expects an buffer address. Not sure
how we can pass an MDL?
I’ll try to set the irp->MdlAddress with the mdl received in my driver (to
reuse the mdl)

Anyways will perform the debug exercise as mentioned in the link to confirm
the behavior…

Regards,
-Vipul.

On Wed, Apr 23, 2014 at 9:59 AM, wrote:

>


>
> The bugcheck code that OP is experiencing is in the post. It is a very
> specific bugcheck code added to Windows 8 for a very specific issue. it
> has
> nothing to do with NULL pointers nor does it have anything to do with the
> Executive pool allocator. See the link that I posted.

Yes, I saw that after I replied. I had not seen this before, so it looked
like a classic memory-damage report.
joe

>
> -scott
> OSR
> @OSRDrivers
>
>
> wrote in message news:xxxxx@ntdev…
>
>> Hi,
>>
>> On Windows 2012 server I am getting the following Bsod
>> Bugcheck - MEMORY_MANAGEMENT (1a)
>> Arg1: 0000000000061946
>>
>> Due to some reason, need to use IOCTL_SCSI_PASSTHROUGH_DIRECT to read
>> data
>> from the below scsi device instead of calling IRP_MJ_READ on the lower
>> device.
>> I mapped the Mdl received in my driver(DO_DIRECT_IO) to system space
>> address by calling MmGetSystemAddressForMdlSafe() and passed this system
>> space address to below driver.
>> SCSI_PASS_THROUGH_DIRECT.DataBuffer =
>> MmGetSystemAddressForMdlSafe(Mdl received in my driver)
>
> There is no guarantee this will work. Did you check the .DataBuffer to
> see if it has a valid address? It will either have a valid address or
> NULL. If it is NULL, you are going to have problems. The stack is not
> the most useful part; include the entire !analyze -v output!
>
> Note that an earlier bug could have damaged storage headers and this is
> the first chance the allocator had to discover this damage. Therefore, it
> may not be correlated with what you are doing, but what you may have
> already done in some totally unrelated execution path in your driver.
>
> Did you run driver verifier? If you did, did you enable special pools?
> joe
>
>>
>> But the host crashed with the following stack :frowning:
>>
>> * # Call Site*
>> 00 nt!KeBugCheckEx
>> 01 nt! ?? ::FNODOBFM::`string’
>> 02 nt!MmProbeAndLockPages
>> 03 storport!PortPassThroughBuildIrp
>> 04 storport!PortPassThroughSendAsync
>> 05 storport!PortPassThroughExSendAsync
>> 06 storport!RaidAdapterPassThrough
>> 07 storport!RaidAdapterDeviceControlIrp
>> 08 storport!RaDriverDeviceControlIrp
>> 09 storport!RaUnitScsiPassThroughIoctl
>> 0a storport!RaUnitDeviceControlIrp
>> 0b storport!RaDriverDeviceControlIrp
>> 0c CLASSPNP!ClassDeviceControl
>> 0d disk!DiskDeviceControl
>> 0e CLASSPNP!ClassDeviceControlDispatch
>>
>> Is any extra handling is required while passing the mapped buffer to
>> below
>> driver?
>>
>> Thanks,
>> -Vipul.
>>
>> —
>> 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
>

—
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

8

>Pavel Lebedinksy explained it clearly here:

http://www.osronline.com/ShowThread.cfm?link=240647

Mr. Lebedinsky was talking about paging I/O:

The 0x1A/0x61946 bugcheck happens when the memory manager issues a paging read
and some driver then tries to create a secondary, write-access MDL describing
the same physical pages. This is bad because when that secondary MDL is unlocked
the pages will get marked dirty when they’re not supposed be, causing various
problems downstream.

But I don’t quite understand the scenario and why it whould be invalid. For a paging read, the pages are locked for write access. If a driver reads into the locked pages by using PIO, the pages will be marked dirty, too. Will it cause the bugcheck/assert? If a different usermode thread does ReadFile at the same time into the same buffer, the pages will get modified, too. Will it bugcheck?

Is the bugcheck actually related to the dummy/filler page?

9

You’ve sort of boxed yourself into a corner by using SPT. Why was a normal
read request rejected?

Mark Roddy

On Wed, Apr 23, 2014 at 8:11 AM, Vipul wrote:

> Hi Scott,
>
> After going through the link, it mentions that we need to reuse the mdl
> while sending it to the lower level driver.
> In case of SCSI_PASSTHROUGH_DIRECT it expects an buffer address. Not sure
> how we can pass an MDL?
> I’ll try to set the irp->MdlAddress with the mdl received in my driver (to
> reuse the mdl)
>
> Anyways will perform the debug exercise as mentioned in the link to
> confirm the behavior…
>
> Regards,
> -Vipul.
>
>
> On Wed, Apr 23, 2014 at 9:59 AM, wrote:
>
>> >


>> >
>> > The bugcheck code that OP is experiencing is in the post. It is a very
>> > specific bugcheck code added to Windows 8 for a very specific issue. it
>> > has
>> > nothing to do with NULL pointers nor does it have anything to do with
>> the
>> > Executive pool allocator. See the link that I posted.
>>
>> Yes, I saw that after I replied. I had not seen this before, so it looked
>> like a classic memory-damage report.
>> joe
>> >
>> > -scott
>> > OSR
>> > @OSRDrivers
>> >
>> >
>> > wrote in message news:xxxxx@ntdev…
>> >
>> >> Hi,
>> >>
>> >> On Windows 2012 server I am getting the following Bsod
>> >> Bugcheck - MEMORY_MANAGEMENT (1a)
>> >> Arg1: 0000000000061946
>> >>
>> >> Due to some reason, need to use IOCTL_SCSI_PASSTHROUGH_DIRECT to read
>> >> data
>> >> from the below scsi device instead of calling IRP_MJ_READ on the lower
>> >> device.
>> >> I mapped the Mdl received in my driver(DO_DIRECT_IO) to system space
>> >> address by calling MmGetSystemAddressForMdlSafe() and passed this
>> system
>> >> space address to below driver.
>> >> SCSI_PASS_THROUGH_DIRECT.DataBuffer =
>> >> MmGetSystemAddressForMdlSafe(Mdl received in my driver)
>> >
>> > There is no guarantee this will work. Did you check the .DataBuffer to
>> > see if it has a valid address? It will either have a valid address or
>> > NULL. If it is NULL, you are going to have problems. The stack is not
>> > the most useful part; include the entire !analyze -v output!
>> >
>> > Note that an earlier bug could have damaged storage headers and this is
>> > the first chance the allocator had to discover this damage. Therefore,
>> it
>> > may not be correlated with what you are doing, but what you may have
>> > already done in some totally unrelated execution path in your driver.
>> >
>> > Did you run driver verifier? If you did, did you enable special pools?
>> > joe
>> >
>> >>
>> >> But the host crashed with the following stack :frowning:
>> >>
>> >> * # Call Site*
>> >> 00 nt!KeBugCheckEx
>> >> 01 nt! ?? ::FNODOBFM::`string’
>> >> 02 nt!MmProbeAndLockPages
>> >> 03 storport!PortPassThroughBuildIrp
>> >> 04 storport!PortPassThroughSendAsync
>> >> 05 storport!PortPassThroughExSendAsync
>> >> 06 storport!RaidAdapterPassThrough
>> >> 07 storport!RaidAdapterDeviceControlIrp
>> >> 08 storport!RaDriverDeviceControlIrp
>> >> 09 storport!RaUnitScsiPassThroughIoctl
>> >> 0a storport!RaUnitDeviceControlIrp
>> >> 0b storport!RaDriverDeviceControlIrp
>> >> 0c CLASSPNP!ClassDeviceControl
>> >> 0d disk!DiskDeviceControl
>> >> 0e CLASSPNP!ClassDeviceControlDispatch
>> >>
>> >> Is any extra handling is required while passing the mapped buffer to
>> >> below
>> >> driver?
>> >>
>> >> Thanks,
>> >> -Vipul.
>> >>
>> >> —
>> >> 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
>> >
>>
>>
>>
>> —
>> 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
>

10

To work around that you can set your IRP::RequestorMode to the original Irp->RequestorMode (which will be UserMode), set SCSI_PASS_THROUGH_DIRECT::DataBuffer to the original user buffer (MmGetMdlVirtualAddress(Mdl)).

For the memory manager this would look like two reads issued to the same buffer, which is absolutely legit.

Make sure to send the IRP in the original user thread context, though.

11

If you lock an MDL with MmProbeAndLockPages and specify IoWriteAccess, when
MmUnlockPages is called the Mm sets the dirty bit in the PFN for each page
in the MDL. These pages are now considered to be modified and must be
written back by the Mm to the backing store at some point.

In this model, paging reads really must be handled specially. Imagine that
you want to page some data in from a backing store. You allocate a buffer,
probe it for write access, and read the data in from the file system. The
data has now been read and so you unlock the MDL, which marks the pages as
dirty. The pages are now considered to be modified and must be written out,
even though you haven’t actually modified the data and a copy of the data is
already sitting on disk. We used to see this all the time with people
writing file system filters, they’d wonder why the file was getting written
out after it had only been read. Now they get a bugcheck and wonder why the
system crashed :slight_smile:

Windows handles this by treating paging MDLs as special, they’re not probed
for access using the same external APIs that everyone else uses. They also
have a special bit to differentiate them from other MDLs (MDL_IO_PAGE_READ).

-scott
OSR
@OSRDrivers

wrote in message news:xxxxx@ntdev…

Pavel Lebedinksy explained it clearly here:

http://www.osronline.com/ShowThread.cfm?link=240647

Mr. Lebedinsky was talking about paging I/O:

The 0x1A/0x61946 bugcheck happens when the memory manager issues a paging
read
and some driver then tries to create a secondary, write-access MDL
describing
the same physical pages. This is bad because when that secondary MDL is
unlocked
the pages will get marked dirty when they’re not supposed be, causing
various
problems downstream.

But I don’t quite understand the scenario and why it whould be invalid. For
a paging read, the pages are locked for write access. If a driver reads
into the locked pages by using PIO, the pages will be marked dirty, too.
Will it cause the bugcheck/assert? If a different usermode thread does
ReadFile at the same time into the same buffer, the pages will get modified,
too. Will it bugcheck?

Is the bugcheck actually related to the dummy/filler page?

12

Paging reads have a requestor mode of Kernel and the MDLs do not have an
associated virtual address.

-scott
OSR
@OSRDrivers

wrote in message news:xxxxx@ntdev…

To work around that you can set your IRP::RequestorMode to the original
Irp->RequestorMode (which will be UserMode), set
SCSI_PASS_THROUGH_DIRECT::DataBuffer to the original user buffer
(MmGetMdlVirtualAddress(Mdl)).

For the memory manager this would look like two reads issued to the same
buffer, which is absolutely legit.

Make sure to send the IRP in the original user thread context, though.

13

I thought the OP is converting an application’s ReadFile to SPTID. If it’s a paging I/O, fudging with it would be unwise.

Will PIO access or memcopy to the system mapped address screw the modified bit of those pages, though?

14

If you map the MDL and use the returned address for PIO you’re safe. The Mm
is responsible for pushing the hardware controlled dirty bit from the PTE
into the PFN when necessary (e.g. working set trimming or on explicit
flush). This isn’t done when the MDL is unmapped, thus the PFNs won’t be
marked as dirty and you won’t get the undesirable behavior.

-scott
OSR
@OSRDrivers

wrote in message news:xxxxx@ntdev…

I thought the OP is converting an application’s ReadFile to SPTID. If it’s a
paging I/O, fudging with it would be unwise.

Will PIO access or memcopy to the system mapped address screw the modified
bit of those pages, though?

15

Hi Mark\ Scott,

The need for mapping IRP_MJ_READ to SPTD is to process the sense data from
the scsi device on a specific unit condition.

I tried to pass irp->MdlAddress (build using IoBuildPartialMdl) along with
SPTD buffer address -> this didn’t work.
But creating a double read buffer worked :expressionless:
Is it that whenever we have to use SPTD in driver, we have to double buffer
the read? Or is there any efficient way out?

Regards,
-Vipul.

On Thu, Apr 24, 2014 at 2:28 AM, Scott Noone wrote:

>


>
> If you map the MDL and use the returned address for PIO you’re safe. The
> Mm is responsible for pushing the hardware controlled dirty bit from the
> PTE into the PFN when necessary (e.g. working set trimming or on explicit
> flush). This isn’t done when the MDL is unmapped, thus the PFNs won’t be
> marked as dirty and you won’t get the undesirable behavior.
>
> -scott
> OSR
> @OSRDrivers
>
>
> wrote in message news:xxxxx@ntdev…
>
>
> I thought the OP is converting an application’s ReadFile to SPTID. If it’s
> a paging I/O, fudging with it would be unwise.
>
> Will PIO access or memcopy to the system mapped address screw the modified
> bit of those pages, though?
>
> —
> 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
>

16

> Windows handles this by treating paging MDLs as special, they’re not probed

They are not even created by IoAllocateMdl, nor they are destroyed by IoFreeMdl.

They are the tail part of the Mm’s structure called MMINPAGE_SUPPORT

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

17

>The need for mapping IRP_MJ_READ to SPTD is to process the sense data from
the scsi device on a specific unit condition

If you are filtering reads, why don’t you filter SRBs below disk.sys instead?