Bugcheck 4e 9a

NTDEV
1

Hi,

In my read function, I need to split the incoming read/write requests into multiple child requests to send to remote i/o targets.

The code is something like this:

In SCSIOP_READ:
PIRP irp = WdfRequestWdmGetIrp(Request);
PCHAR dataBuffer = MmGetSystemAddressForMdlSafe(irp->MdlAddress, NormalPagePriority);

For each child request
WdfRequestCreate(…, &childRequest);
WdfMemoryCreatePreallocated(dataBuffer + offset, size, … , &memory);
WdfIoTargetFormatRequestForRead(remoteIoTarget, childRequest, memory, … );

In completion routine
Once all the child requests are done, complete the original request.

Unfortunately, this tends to Bugcheck with 4e, 009a occasionally, with the NTFS file system driver showing up as the culprit.

What would be the best way to resolve this?

I was looking to see if it’s possible to do a IoBuildPartialMdl with the incoming MDL & then send the child requests, but I guess the function to create a WdfMemory object using MDLs is missing.

Regards,
Mridul.

2

Are you sure the buffer is locked?

3

How do I check that??

4

If you are referring to MmIsAddressValid(…), then yes, I am doing that right after the MmGetSystemAddressForMdlSafe call.

5

Read the manual, this test does not verify this will work, after you get the
MDL do you do a MmProbeAndLockPages?

–
Don Burn (MVP, Windows DDK)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

wrote in message news:xxxxx@ntdev…
> If you are referring to MmIsAddressValid(…), then yes, I am doing that
> right after the MmGetSystemAddressForMdlSafe call.
>

6

I tried a MmProbeAndLockPages for the MdlAddress in the incoming Irp & then do a MmUnlockPages for the same MdlAddress either in the completion routine, or in the actual call itself.

Unfortunately I get a bugcheck 50 on MmUnlockPages.

From what I’ve read in the OSR lists, there is no need to probe & lock the MdlAddress from the incoming IRPs because that is already done by the IO Manager.

I suspect the reason for the original bugcheck 4e is because I am creating requests to remote I/O targets with the address obtained by MmGetlSystemAddressForMdlSafe. This causes intermittent crashes. Do I have to do create an IRP using IoBuildPartialMdl and then create Requests based on this?

Thanks for the responses.

Regards,
Mridul.

7

> From what I’ve read in the OSR lists, there is no need to probe & lock the MdlAddress from the

incoming IRPs because that is already done by the IO Manager.

Correct. Irp->MdlAddress is already probed and locked, you must neither probe/lock it nor unlock or destroy it. You can only use it.

crashes. Do I have to do create an IRP using IoBuildPartialMdl

Yes, this seems to be the better choice.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

8

Hi,

My driver is built using the checked build environment for x86 Windows XP using winddk\6000. It works absolutely fine on Windows XP. The same driver dies on Windows Vista consistently with Bug Check 4e {9a, xxxx, 6, 2}. It dies with the same bug check if I build the driver using the x86 checked build environment for Windows Longhorn using winddk\6000, or winddk\6001.1800.

In SCSIOP_READ:
PIRP irp = WdfRequestWdmGetIrp(Request);
PMDL mdl = irp->MdlAddress;
WDF_OBJECT_ATTRIBUTES attributes;
int i = 0;

for (i = 0; i < requestCount; ++i)
{
PCHAR dataBuffer = NULL;
PMDL childMdl = IoAllocateMdl((PCHAR)MmGetMdlVirtualAddress(mdl) + offset, readLength, TRUE, FALSE, NULL);
IoBuildPartialMdl(irp->MdlAddress, childMdl, (PCHAR)MmGetMdlVirtualAddress(mdl) + offset, readLength);
dataBuffer = MmGetSystemAddressForMdlSafe(childMdl, NormalPriority);

WdfRequestCreate(&attributes, remoteIoTarget, &childRequest);

WDF_OBJECT_ATTRIBUTES_INIT(&attributes);
attributes.ParentObject = childRequest;
WdfMemoryCreatePreallocated(&attributes, dataBuffer, readLength, &memory);
WdfIoTargetFormatRequestForRead(remoteIoTarget, childRequest, memory, … );
}

In completion routine
WdfObjectDelete(Request);
IoFreeMdl(context->childMdl);
if (childRequestCount == 0)
{
WdfRequestCompleteWithInformation(context->ParentRequest, STATUS_SUCCESS, information);
}

Here?s one of the bugchecks

*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 4E, {9a, 3f430, 6, 2}

Probably caused by : memory_corruption ( nt!MiBadRefCount+26 )

Followup: MachineOwner

nt!RtlpBreakWithStatusInstruction:
818c8514 cc int 3
kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

PFN_LIST_CORRUPT (4e)
Typically caused by drivers passing bad memory descriptor lists (ie: calling
MmUnlockPages twice with the same list, etc). If a kernel debugger is
available get the stack trace.
Arguments:
Arg1: 0000009a,
Arg2: 0003f430
Arg3: 00000006
Arg4: 00000002

Debugging Details:

BUGCHECK_STR: 0x4E_9a

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

PROCESS_NAME: System

CURRENT_IRQL: 2

LAST_CONTROL_TRANSFER: from 818dd2d7 to 818c8514

STACK_TEXT:
99ab0abc 818dd2d7 00000003 1b1f0465 00000000 nt!RtlpBreakWithStatusInstruction
99ab0b0c 818dddbd 00000003 c0429180 848eb540 nt!KiBugCheckDebugBreak+0x1c
99ab0ed8 818dd163 0000004e 0000009a 0003f430 nt!KeBugCheck2+0x66d
99ab0ef8 818b397c 0000004e 0000009a 0003f430 nt!KeBugCheckEx+0x1e
99ab0f10 818ff89a 00000000 00004000 00004000 nt!MiBadRefCount+0x26
99ab0fec 818fe29c 85230000 850ed9b8 99ab1094 nt!MiFreePoolPages+0x128
99ab1050 82820235 85230000 00000000 99ab107c nt!ExFreePoolWithTag+0x40e
99ab1060 828201b5 871d3810 85230000 99ab1094 Ntfs!NtfsDeleteMdlAndBuffer+0x31
99ab107c 8281f9fd 850ed9b8 99ab1094 00000000 Ntfs!NtfsDeallocateCompressionBuffer+0x2d
99ab108c 8281f8d2 85230000 00004000 99ab15e8 Ntfs!NtfsNonCachedIo+0x785
99ab11ac 8281c2f7 99ab1350 850ed9b8 871a9600 Ntfs!NtfsNonCachedIo+0x664
99ab1214 82822509 99ab1350 850ed9b8 871a9600 Ntfs!NtfsNonCachedUsaWrite+0x145
99ab1340 82820914 99ab1350 850ed9b8 0118070a Ntfs!NtfsCommonWrite+0x1b37
99ab14d8 818cc053 853ff020 850ed9b8 850ed9b8 Ntfs!NtfsFsdWrite+0x2dc
99ab14f0 81fb5ba7 8509f4b8 850ed9b8 00000000 nt!IofCallDriver+0x63
99ab1514 81fb5d64 99ab1534 8509f4b8 00000000 fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x251
99ab154c 818cc053 8509f4b8 850ed9b8 850ed9b8 fltmgr!FltpDispatch+0xc2
99ab1564 81fb5d81 850f7908 00000000 99940768 nt!IofCallDriver+0x63
99ab1590 818cc053 850f7908 850ed9b8 01ae5000 fltmgr!FltpDispatch+0xdf
99ab15a8 818509ce 99ab1844 99ab15e8 00000000 nt!IofCallDriver+0x63
99ab15bc 818901b6 849762d8 850f7908 99ab1660 nt!IoSynchronousPageWrite+0x10b
99ab16ec 8188f2d7 9ffd8728 9ffd8748 85149b38 nt!MiFlushSectionInternal+0x97f
99ab174c 8184fae7 99958fbc 00004000 00000005 nt!MmFlushSection+0xd5
99ab17e0 8281b427 99958fbc 99ab188c 00004000 nt!CcFlushCache+0x239
99ab18b4 82896ae4 97af8180 0b35d26f 00000000 Ntfs!LfsFlushLfcb+0x479
99ab190c 82898986 01af8180 0b35d26f 00000000 Ntfs!LfsFlushToLsnPriv+0x1ad
99ab1950 8289a755 a07fc830 0b35d26f 00000000 Ntfs!LfsFlushToLsn+0x80
99ab197c 8289cf30 015f7918 00000180 815f7918 Ntfs!NtfsCommitCurrentTransaction+0x11e
99ab1990 828b1fa3 815f7918 1b2fa367 00000000 Ntfs!NtfsCheckpointCurrentTransaction+0x21
99ab19d4 828b6de4 815f7918 9d6255f0 0000006c Ntfs!NtfsCacheSharedSecurityByDescriptor+0x93
99ab1a20 828b5324 815f7918 9d6255f0 1b2fa6b7 Ntfs!NtfsCacheSharedSecurityForCreate+0xf6
99ab1c04 8289dd01 815f7918 85d8b3e8 9fe780f8 Ntfs!NtfsCreateNewFile+0x329
99ab1cec 828232aa 815f7918 85d8b3e8 83316fa4 Ntfs!NtfsCommonCreate+0xca2
99ab1d2c 818c9318 83316f3c 00000000 ffffffff Ntfs!NtfsCommonCreateCallout+0x20
99ab1d2c 818c9411 83316f3c 00000000 ffffffff nt!KiSwapKernelStackAndExit+0x118
83316ecc 8184e7a1 83316f3c 8282328a 99ab2000 nt!KiSwitchKernelStackAndCallout+0x31
83316f18 8282333a 8282328a 83316f3c 00000000 nt!KeExpandKernelStackAndCalloutEx+0x1e7
83316f4c 8289f1fb 815f7918 85d8b3e8 83316fa4 Ntfs!NtfsCommonCreateOnNewStack+0x3c
83317048 818cc053 853ff020 85d8b3e8 870242e4 Ntfs!NtfsFsdCreate+0x1f1
83317060 81a30c05 01857e59 84f7a53c 86ff98e0 nt!IofCallDriver+0x63
83317130 81a562ff 86ff98f8 00000000 84f7a498 nt!IopParseDevice+0xf61
833171c0 81a2dfea 00000000 83317218 00000240 nt!ObpLookupObjectName+0x5a8
83317224 81a2fae7 833173a4 00000000 84976200 nt!ObOpenObjectByName+0x13c
83317298 81a36441 9d6fc468 c0120000 833173a4 nt!IopCreateFile+0x63b
833172f4 819eeea1 9d6fc468 c0120000 833173a4 nt!IoCreateFileEx+0x9d
83317350 80650fe1 9d6fc468 c0120000 833173a4 nt!IoCreateFileSpecifyDeviceObjectHint+0x58
83317414 8064e774 833174e8 8331744c 833174b4 CLFS!CClfsContainer::Create+0xf1
83317480 8065eb55 833174e8 00010000 00000001 CLFS!CClfsBaseFilePersisted::CreateImage+0x19c
83317528 806517fb 00000000 8518da54 00000000 CLFS!CClfsLogFcbPhysical::Initialize+0x1bf
833175d8 80654faa 03551724 85b964d8 8150d360 CLFS!CClfsRequest::Create+0x295
83317614 80663a7f 8150d360 85b964d8 03551764 CLFS!CClfsRequest::Dispatch+0xe2
83317654 806494ea 85b964d8 8150d360 035517a0 CLFS!ClfsDispatchIoRequest+0x13b
83317690 818cc053 85b964d8 8150d360 8510730c CLFS!CClfsDriver::LogIoDispatch+0x3c
833176a8 81a30c05 01857811 8518dadc 85b964c0 nt!IofCallDriver+0x63
83317778 81a562ff 85b964d8 00000000 8518da38 nt!IopParseDevice+0xf61
83317808 81a2dfea 00000000 83317860 00000242 nt!ObpLookupObjectName+0x5a8
8331786c 81a2fae7 83317a04 00000000 8497da00 nt!ObOpenObjectByName+0x13c
833178e0 81a36441 83317a64 c0010000 83317a04 nt!IopCreateFile+0x63b
8331793c 819eeea1 83317a64 c0010000 83317a04 nt!IoCreateFileEx+0x9d
83317998 80664233 83317a64 c0010000 83317a04 nt!IoCreateFileSpecifyDeviceObjectHint+0x58
83317aa4 82867dba 9feb6168 9d0eaf50 c0000000 CLFS!ClfsCreateLogFile+0x747
83317c14 8286481c 85013008 9ff09008 9d71ed70 Ntfs!TxfStartRm+0xa09
83317ca8 828a497c 853ff0d8 851574d0 85013008 Ntfs!TxfInitializeVolume+0x688
83317cc4 8281703e 85013008 00000000 01b5c7f7 Ntfs!NtfsCommonFileSystemControl+0x99
83317d44 8184841d 00000000 00000000 849762d8 Ntfs!NtfsFspDispatch+0x264
83317d7c 819e5a1c 85013008 018572a9 00000000 nt!ExpWorkerThread+0xfd
83317dc0 8183ea3e 81848320 00000000 00000000 nt!PspSystemThreadStartup+0x9d
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
nt!MiBadRefCount+26
818b397c cc int 3

SYMBOL_STACK_INDEX: 4

SYMBOL_NAME: nt!MiBadRefCount+26

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

DEBUG_FLR_IMAGE_TIMESTAMP: 47918b12

IMAGE_NAME: memory_corruption

FAILURE_BUCKET_ID: 0x4E_9a_nt!MiBadRefCount+26

BUCKET_ID: 0x4E_9a_nt!MiBadRefCount+26

Followup: MachineOwner

kd> !pfn 3f430
PFN 0003F430 at address 848EB540
flink 00000000 blink / share count 00000001 pteaddress C0429180
reference count 0002 Cached color 0 Priority 0
restore pte 00000000 containing page 03FFFD Active

Is there anything I can try to figure this out?

Regards,
Mridul.