Hi,
So quick background again, driver that manages a virtual drive. Working fine from XP on to Win7 (didn’t run under check builds), Win8 and 10, BugCheck 1A-61946 (windbg reports random items as cause, with stack a bunch of ???, although today got one and there was some data and showed an mmprobeandlock in ntfs, but nothing about my driver in stack). Finding information on this, says something about a paging io read MDL being updated for write and made dirty which appears to be caused by something ZwReadFile was doing. So for diagnosing I just set up a non-paged buffer of 4K, and used it whenever a read came in with (irp->Flags & IRP_PAGING_IO) looping the read if the size was larger. Problem was, still getting the bugcheck. So I said that makes no sense, f-it, I’ll just do that to all reads to test, when I did that, it works. So any idea on what else can be going on, my driver only uses MmGetSystemAddressForMdlSafe to get a virtualaddress to work with, I understood that under ZwReadFile it maybe doing something else with it so I added the alternate buffer for paging reads, but I wonder why I even get paging reads on this virtual drive as there is no page file on it.
TIA!!
Do you make your own IRPs?
Is this a volume driver or a file system filter driver? I’ll assume the
former.
First, paging IO does not mean that the IO is for the paging file, it
simply means that either memory or cache mgr is performing IO but it
could be backed by a regular file. This can happen when touching a
region of a file in the system cache that has no data backing it so it
will be ‘paged’ in using this flag to indicate to the file system that
it is destined for the underlying media. That said, are you certain the
MDL is valid, probed and locked? You could be trying to access the MDL
which has not been probed and locked for pageable addresses and you are
running at DISPATCH IRQL.
Pete
–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com http:</http:>
866.263.9295
------ Original Message ------
From: xxxxx@terabyteunlimited.com
To: “Windows System Software Devs Interest List”
Sent: 5/31/2016 9:32:20 AM
Subject: [ntdev] Is (irp->Flags & IRP_PAGING_IO) Enough to Prevent
BugCheck 1A-61946?
>Hi,
>
>So quick background again, driver that manages a virtual drive.
>Working fine from XP on to Win7 (didn’t run under check builds), Win8
>and 10, BugCheck 1A-61946 (windbg reports random items as cause, with
>stack a bunch of ???, although today got one and there was some data
>and showed an mmprobeandlock in ntfs, but nothing about my driver in
>stack). Finding information on this, says something about a paging io
>read MDL being updated for write and made dirty which appears to be
>caused by something ZwReadFile was doing. So for diagnosing I just
>set up a non-paged buffer of 4K, and used it whenever a read came in
>with (irp->Flags & IRP_PAGING_IO) looping the read if the size was
>larger. Problem was, still getting the bugcheck. So I said that
>makes no sense, f-it, I’ll just do that to all reads to test, when I
>did that, it works. So any idea on what else can be going on, my
>driver only uses MmGetSystemAddressForMdlSafe to get a virtualaddress
>to work with, I understood that under ZwReadFile it maybe doing
>something else with it so I added the alternate buffer for paging
>reads, but I wonder why I even get paging reads on this virtual drive
>as there is no page file on it.
>
>TIA!!
>
>
>—
>NTDEV is sponsored by OSR
>
>Visit the list online at:
>http:
>
>MONTHLY seminars on crash dump analysis, WDF, Windows internals and
>software drivers!
>Details at http:
>
>To unsubscribe, visit the List Server section of OSR Online at
>http:</http:></http:></http:>
it’s a disk driver using files for storing the data to emulate a normal disk. It would be the lowest level driver and is using MmGetSystemAddressForMdlSafe on the IRP_MJ_READ and IRP_MJ_WRITE. The first problem I had when enabling write support (read-only wasn’t and isn’t a problem) was dead lock due to paging file on ZwWriteFile, so a move to not used buffer IO (use direct io) fixed that. All was looking good until Win8/10, then if mounted for write, would get that bug check (read-only still no problem). Trying to use an internal buffer (nonpaged in this case right now) when irp marked as paging io for read operation didn’t fix, when changed reads to always use the internal buffer, then it started to work fine (only changed the read side which uses ZwReadFile). ?
>Do you make your own IRPs?
No.
Forgot to add - all irps are added to list and processed in a worker thread.