bugcheck 0x1A/0x61946 occured at IoBuildAsynchronousFsdRequest on Win2012R2

NTDEV
1

Dear friends,

I am writing volume upper filter driver on Win7, Win8/8.1.
I used IoBuildAsynchronousFsdRequest function to read block.
This driver works well on Windows 7/32bit.
But on Windows 2012R2/64 it failed with BSOD bugcheck 0x1A/0x61946.

According to Mr. Pavel Lebedinksy posting:
http://www.osronline.com/ShowThread.cfm?link=240647

He 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.
The bugcheck is new in win8. Prior to win8 it used to be an assert so you
would
likely see the same problem on a checked win7 build.
To fix this you need to reuse the original MDL instead of creating a new
one.

My questions:

  1. Would like to explain the workaround of “reuse the original MDL” more
    detail?

  2. Where can I find the MS official descriptions about “0x61946 bugcheck is
    new in win8”?

Thanks.

2

On Jun 21, 2014, at 2:19 AM, JaeHeon Kim > wrote:

I am writing volume upper filter driver on Win7, Win8/8.1.
I used IoBuildAsynchronousFsdRequest function to read block.
This driver works well on Windows 7/32bit.
But on Windows 2012R2/64 it failed with BSOD bugcheck 0x1A/0x61946.

According to Mr. Pavel Lebedinksy posting:
http://www.osronline.com/ShowThread.cfm?link=240647

He 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.

Does that describe what you are doing? Are you trying to do a write operation using a secondary MDL that you created from a read request that you got?

2) Where can I find the MS official descriptions about “0x61946 bugcheck is new in win8??

There is no ?official” description.
–
Tim Roberts, xxxxx@probo.commailto:xxxxx
Providenza & Boekelheide, Inc.</mailto:xxxxx>

3

Dear Tim Roberts,
Thank you for your kind answer.
This BSOD occured during READ operation.

My driver’s I/O procedures may be summarized as follows

  1. hooking

(1.1) hooks orgIrp from upper driver by IRP_MJ_READ/WRITE dispatcher
(1.2) returns STATUS_PENDING to I/O manager
(1.3) This orgIrp will be processed by another thread.

  1. process orgIrp by another thread

(2.1) creates another new IRP using IoBuildAsynchronousFsdRequest and sends it

newIrp = IoBuildAsynchronousFsdRequest(
io,
TargetDeviceObject,
buffer,
size,
&offset,
NULL
);

IoSetCompletionRoutine(newIrp, end_io, bio, TRUE, TRUE, TRUE);
IoCallDriver(TargetDeviceObject, newIrp);

(2.2) completion routine : free MDL and new Irp

if (newIrp->MdlAddress != NULL) {
PMDL mdl, nextMdl;
for (mdl = newIrp->MdlAddress; mdl != NULL; mdl = nextMdl) {
nextMdl = mdl->Next;
MmUnlockPages(mdl);
IoFreeMdl(mdl);
}
newIrp->MdlAddress = NULL;
}
IoFreeIrp(newIrp);

(2.3) completion routine : free org Irp

IoCompleteRequest(orgIrp, IO_DISK_INCREMENT);

Notes:

  1. the READ/WRITE works well on the Win7/32bit. On the Win2012R3/64bit the WRITE is ok but READ is fail.

  2. I tried to change IoBuildAsynchronousFsdRequest function
    to (IoAllocateIrp + IoAllocateMdl + MmProbeAndLockPages) method but result was same on READ operation.

Thanks.

4

The bugcheck tell you that you should not issue another READ I/O (build a WRite MDL which IoBuildAsynchronousFsdRequest does) into the original buffer.

Why do you want to do that, anyway?

5

Dear Grig,
Above (2.1) case it’s read operation on another thread.
I don’t WRITE the same buffer during READ.
Anyway, It works nicely on the Win7/32 for several months.
If you need some asks for my driver, please feel free.
Thanks.

6

The buffer for READ operation is WRITTEN to by the device.

A paging I/O comes with a special flag in the MDL. After such MDL is unlocked, the memory is NOT marked as dirty.

With your driver, the new MDL would cause the memory to be marked as dirty. The kernel now checks for that case and issues the bugcheck.

DO NOT make a second IRP.

7

Thank you for your info.
Let me try to redesigne my read logic without making second IRP at read
operation.
Its may be some hard work for me. :frowning:

BTW I have a question once again, why doesn’t this bugcheck occur on the
Win7/32bit?

Thanks.

2014-06-23 22:38 GMT+09:00 :

> The buffer for READ operation is WRITTEN to by the device.
>
> A paging I/O comes with a special flag in the MDL. After such MDL is
> unlocked, the memory is NOT marked as dirty.
>
> With your driver, the new MDL would cause the memory to be marked as
> dirty. The kernel now checks for that case and issues the bugcheck.
>
> DO NOT make a second IRP.
>
> —
> 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
>