MmMapLockedPagesSpecifyCache: Blue dump under Server 2003-32

NTDEV
1

Hello,

I’m using:

AllocateCommonBuffer
IoAllocateMdl
MmBuildMdlForNonPagedPool

to allocate a continuous physical buffer by kernel driver.

I’m aware that this is wrong and I was warned here about it.

But I have to rewrite an old WDM driver without changing FPGA (which does
not support scatter-gather).

The 32MB allocation works fine.

Then upon IOCTL request from user space I call to:

PVOID Address = MmMapLockedPagesSpecifyCache (devExt->Mdl, UserMode,
MmNonCached , NULL, FALSE, NormalPagePriority)

Under XP-32, the allocation and MmMapLockedPagesSpecifyCache works great and
user space gets the virtual address of the physical buffer.

But under Server 2003-32, allocation works OK but
MmMapLockedPagesSpecifyCache causes blue dump.

I’m not using the same sys.

For Server 2003-32 I used: Windows Server 2003 x86 Checked Build
Environment.lnk

Can you help ?

Why there is a difference between writing a kernel driver for XP-32 to
Server 2003-32 ?

Thanks,
Zvika.

2

Please post the results of !analyze -v.

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Zvi Vered
Sent: Sunday, December 04, 2011 11:40 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] MmMapLockedPagesSpecifyCache: Blue dump under Server
2003-32

Hello,

I’m using:

AllocateCommonBuffer
IoAllocateMdl
MmBuildMdlForNonPagedPool

to allocate a continuous physical buffer by kernel driver.

I’m aware that this is wrong and I was warned here about it.

But I have to rewrite an old WDM driver without changing FPGA (which does
not support scatter-gather).

The 32MB allocation works fine.

Then upon IOCTL request from user space I call to:

PVOID Address = MmMapLockedPagesSpecifyCache (devExt->Mdl, UserMode,
MmNonCached , NULL, FALSE, NormalPagePriority)

Under XP-32, the allocation and MmMapLockedPagesSpecifyCache works great and
user space gets the virtual address of the physical buffer.

But under Server 2003-32, allocation works OK but
MmMapLockedPagesSpecifyCache causes blue dump.

I’m not using the same sys.

For Server 2003-32 I used: Windows Server 2003 x86 Checked Build
Environment.lnk

Can you help ?

Why there is a difference between writing a kernel driver for XP-32 to
Server 2003-32 ?

Thanks,
Zvika.

NTDEV is sponsored by OSR

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

3

> The 32MB allocation works fine.

This looks like an MDL size limit for 32bit Windows.

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

4

Drivers built for XP usually should run on 2003. Is it SP1 or SP2, by
the way?
Unfortunately it is hard to help you because you haven’
t posted any details of the crash (stack trace, or even the error code &
parameters).
– pa

On 04-Dec-2011 21:39, Zvi Vered wrote:

Hello,

I’m using:

AllocateCommonBuffer
IoAllocateMdl
MmBuildMdlForNonPagedPool

to allocate a continuous physical buffer by kernel driver.

I’m aware that this is wrong and I was warned here about it.

But I have to rewrite an old WDM driver without changing FPGA (which
does not support scatter-gather).

The 32MB allocation works fine.

Then upon IOCTL request from user space I call to:

PVOID Address = MmMapLockedPagesSpecifyCache (devExt->Mdl, UserMode,
MmNonCached , NULL, FALSE, NormalPagePriority)

Under XP-32, the allocation and MmMapLockedPagesSpecifyCache works great
and user space gets the virtual address of the physical buffer.

But under Server 2003-32, allocation works OK but
MmMapLockedPagesSpecifyCache causes blue dump.

I’m not using the same sys.

For Server 2003-32 I used: Windows Server 2003 x86 Checked Build
Environment.lnk

Can you help ?

Why there is a difference between writing a kernel driver for XP-32 to
Server 2003-32 ?

Thanks,
Zvika.

5

Unfortunately, the PTP (Psychic Transfer Protocol) doesn’t work to my
machine. You show one line of a sequence of lines, out of context, and
essentially say “My program broke, what did I do wrong?”

What you have done wrong is completely indeterminate. You did not show
the AllocateCommonBuffer call, did not indicate what it returned, did not
show the IoAllocateMdl call, or what it returned, and did not show the
MmBuildMdlForNonPagedPool call, or indiate what it returned. You did not
show any information at all from the crash, e.g., !analyze -v. So we are
supposed to magically infer what all those calls looked like, so we know
you called them in the right way; we are supposed to trust that you
handled all their returns correctly; we are supposed to guess what the
crash was, where it happened, and magically figure out the stack
backtrace?

This is not a question. A question would contain a description of the
problem, show the code (in detail) that led to the problem; prove that you
had handled all the calls correctly, and show what happened, IN DETAIL, as
a consequence.

I used to see 2-4 questions per week in the application-level forums that
were about as vague as this. It is amazing that anyone is trying to write
a driver who doesn’t understand how to actually ask a question in a
meaningful way!

This sounds like a continuation of a bad thread of some time back, wherein
I have a memory that the general agreement was that making kernel common
buffers available to user space ranked high in the list of Really, Really
Bad Ideas. Which goes back to the issue that if you have
really-badly-designed hardware, it simply may be a colossal waste of
effort to try to make it work.

There was also a link, some time back, to an article on how to ask a
question. Go search for that, and go read the article.
joe

Hello,

I’m using:

AllocateCommonBuffer
IoAllocateMdl
MmBuildMdlForNonPagedPool

to allocate a continuous physical buffer by kernel driver.

I’m aware that this is wrong and I was warned here about it.

But I have to rewrite an old WDM driver without changing FPGA (which does
not support scatter-gather).

The 32MB allocation works fine.

Then upon IOCTL request from user space I call to:

PVOID Address = MmMapLockedPagesSpecifyCache (devExt->Mdl, UserMode,
MmNonCached , NULL, FALSE, NormalPagePriority)

Under XP-32, the allocation and MmMapLockedPagesSpecifyCache works great
and
user space gets the virtual address of the physical buffer.

But under Server 2003-32, allocation works OK but
MmMapLockedPagesSpecifyCache causes blue dump.

I’m not using the same sys.

For Server 2003-32 I used: Windows Server 2003 x86 Checked Build
Environment.lnk

Can you help ?

Why there is a difference between writing a kernel driver for XP-32 to
Server 2003-32 ?

Thanks,
Zvika.

NTDEV is sponsored by OSR

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

Hello,

I checked the driver under Server2003-32-SP2 and also under Server2008-64.

Both gave the same results.

It seems that MmMapLockedPagesSpecifyCache cause the crash.

The allocation is done with the following code:

************************************************************************
NTSTATUS AllocateContinuousPhysicalMemory (IN PDEVICE_EXTENSION DevExt)
{
ULONG NumberOfMapRegisters;
DEVICE_DESCRIPTION DeviceDescription;
PPHYSICAL_ADDRESS LogicalAddress;
PDMA_ADAPTER DmaAdapter;
PDEVICE_OBJECT FdoData;
PALLOCATE_COMMON_BUFFER AllocateCommonBuffer;
PVOID UserSpaceAddress;

PAGED_CODE();

RtlZeroMemory(&DeviceDescription, sizeof(DEVICE_DESCRIPTION));

#if defined(DMA_VER2)
DeviceDescription.Version = DEVICE_DESCRIPTION_VERSION2;
#else
DeviceDescription.Version = DEVICE_DESCRIPTION_VERSION;
#endif

DeviceDescription.Master = TRUE;
DeviceDescription.ScatterGather = FALSE;
DeviceDescription.Dma32BitAddresses = FALSE;
DeviceDescription.Dma64BitAddresses = TRUE;
DeviceDescription.InterfaceType = PCIBus;
DeviceDescription.MaximumLength = COMMON_BUFFER_SIZE;

FdoData = WdfDeviceWdmGetPhysicalDevice(DevExt->Device);

DmaAdapter = IoGetDmaAdapter(FdoData,&DeviceDescription,&NumberOfMapRegisters);

if (!DmaAdapter)
{
KdPrint (("IoGetDmaAdapter failed.\n"));
return STATUS_INSUFFICIENT_RESOURCES;
}

AllocateCommonBuffer = DmaAdapter->DmaOperations->AllocateCommonBuffer;

if (!AllocateCommonBuffer)
{
KdPrint (("devExt->AllocateCommonBuffer=0x0\n"));
return STATUS_INSUFFICIENT_RESOURCES;
}

//Allocate common buffer and return its kernel virtual address
DevExt->KernelCommonBuffer = AllocateCommonBuffer(DmaAdapter,
COMMON_BUFFER_SIZE,
&LogicalAddress,
FALSE);

if (!DevExt->KernelCommonBuffer)
{
KdPrint (("AllocateCommonBuffer failed.\n"));
return STATUS_INSUFFICIENT_RESOURCES;
}

KdPrint (("DevExt->KernelCommonBuffer=%p\n",DevExt->KernelCommonBuffer));

RtlZeroMemory(DevExt->KernelCommonBuffer, COMMON_BUFFER_SIZE);

DevExt->CommonBufferMdl = IoAllocateMdl (DevExt->KernelCommonBuffer,COMMON_BUFFER_SIZE,FALSE, FALSE, NULL);

if (!DevExt->CommonBufferMdl)
{
KdPrint (("IoAllocateMdl failed.\n"));
return STATUS_INSUFFICIENT_RESOURCES;
}

KdPrint (("DevExt->CommonBufferMdl=%p\n",DevExt->CommonBufferMdl));

MmBuildMdlForNonPagedPool (DevExt->CommonBufferMdl);

return STATUS_SUCCESS;
}
***********************************************************************
Following is the output of !analyze -v:

***********************************************************************
Loading Dump File [\1public\PUBLIC\a99059\Mini120411-03.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: M:\zvi_vered\module\FIO\windows\module\objchk_wnet_x86\i386;M:\zvi_vered\module\FIO\windows\module\objchk_wxp_x86\i386
Executable search path is:
Unable to load image \WINDOWS\system32\ntkrnlpa.exe, Win32 error 0n2
*** WARNING: Unable to verify timestamp for ntkrnlpa.exe
*** ERROR: Module load completed but symbols could not be loaded for ntkrnlpa.exe
Windows Server 2003 Kernel Version 3790 (Service Pack 2) MP (24 procs) Free x86 compatible
Product: Server, suite: TerminalServer SingleUserTS
Machine Name:
Kernel base = 0x80800000 PsLoadedModuleList = 0x808a6ea8
Debug session time: Sun Dec 4 13:26:50.548 2011 (GMT+2)
System Uptime: 0 days 0:23:31.828
Unable to load image \WINDOWS\system32\ntkrnlpa.exe, Win32 error 0n2
*** WARNING: Unable to verify timestamp for ntkrnlpa.exe
*** ERROR: Module load completed but symbols could not be loaded for ntkrnlpa.exe
Loading Kernel Symbols
...............................................................
.......................................................
Loading User Symbols
Loading unloaded module list
........
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 7A, {1, d0000006, ff0522f0, c0006000}

*** WARNING: Unable to verify timestamp for mssmbios.sys
*** ERROR: Module load completed but symbols could not be loaded for mssmbios.sys
***** Kernel symbols are WRONG. Please fix symbols to do analysis.

Unable to load image wdf01000.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for wdf01000.sys
*** ERROR: Module load completed but symbols could not be loaded for wdf01000.sys
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
Probably caused by : Pci9x5x.sys ( Pci9x5x!PLxEvtIoControl+151 )

Followup: MachineOwner

9: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

KERNEL_DATA_INPAGE_ERROR (7a)
The requested page of kernel data could not be read in. Typically caused by
a bad block in the paging file or disk controller error. Also see
KERNEL_STACK_INPAGE_ERROR.
If the error status is 0xC000000E, 0xC000009C, 0xC000009D or 0xC0000185,
it means the disk subsystem has experienced a failure.
If the error status is 0xC000009A, then it means the request failed because
a filesystem failed to make forward progress.
Arguments:
Arg1: 00000001, lock type that was held (value 1,2,3, or PTE address)
Arg2: d0000006, error status (normally i/o status code)
Arg3: ff0522f0, current process (virtual address for lock type 3, or PTE)
Arg4: c0006000, virtual address that could not be in-paged (or PTE contents if arg1 is a PTE address)

Debugging Details:

***** Kernel symbols are WRONG. Please fix symbols to do analysis.

*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************

ADDITIONAL_DEBUG_TEXT:
Use '!findthebuild' command to search for the target build information.
If the build information is available, run '!findthebuild -s ; .reload' to set symbol path and load symbols.

MODULE_NAME: Pci9x5x

FAULTING_MODULE: 80800000 nt

DEBUG_FLR_IMAGE_TIMESTAMP: 4edb586a

ERROR_CODE: (NTSTATUS) 0xd0000006 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The required data was not placed into memory because of an I/O error status of "0x%08lx".

BUGCHECK_STR: 0x7a_d0000006

CUSTOMER_CRASH_COUNT: 3

DEFAULT_BUCKET_ID: DRIVER_FAULT_SERVER_MINIDUMP

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from 80851cd9 to 80827c63

STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be wrong.
b81e2a18 80851cd9 0000007a 00000001 d0000006 nt+0x27c63
b81e2a4c 80852458 ff0522f0 c0600030 ff0523d0 nt+0x51cd9
b81e2a68 8083c965 c0600030 ff0522f0 00000021 nt+0x52458
b81e2abc 80853372 ff03b000 ff0523d0 c0006280 nt+0x3c965
b81e2b14 b3b9cbd1 ff03b000 00000001 00000000 nt+0x53372
b81e2b7c f72fa072 7b59dfe8 00cec6e8 00000004 Pci9x5x!PLxEvtIoControl+0x151 [m:\zvi_vered\module\fio\windows\module\iocontrol.c @ 151]
b81e2ba0 f72fb3d0 7b59dfe8 00cec6e8 00000004 wdf01000+0x2f072
b81e2bd0 f72fd9ac 00cec6e8 ff313910 84a62010 wdf01000+0x303d0
b81e2bec f72fea36 84a62000 00000000 849b1658 wdf01000+0x329ac
b81e2c0c f7300824 ff313910 84a88e48 84a0f4f0 wdf01000+0x33a36
b81e2c30 f72efa3f 84a88e48 b81e2c50 8081df65 wdf01000+0x35824
b81e2c3c 8081df65 ff3fc4a8 84a88e48 8497e1a0 wdf01000+0x24a3f
b81e2c50 808f5437 84a88edc 8497e1a0 84a88e48 nt+0x1df65
b81e2c64 808f61bf ff3fc4a8 84a88e48 8497e1a0 nt+0xf5437
b81e2d00 808eed08 0000077c 00000758 00000000 nt+0xf61bf
b81e2d34 8088978c 0000077c 00000758 00000000 nt+0xeed08
b81e2d64 7c8285ec badb0d00 0012fd44 00000000 nt+0x8978c
b81e2d68 badb0d00 0012fd44 00000000 00000000 0x7c8285ec
b81e2d6c 0012fd44 00000000 00000000 00000000 0xbadb0d00
b81e2d70 00000000 00000000 00000000 00000000 0x12fd44

STACK_COMMAND: kb

FOLLOWUP_IP:
Pci9x5x!PLxEvtIoControl+151 [m:\zvi_vered\module\fio\windows\module\iocontrol.c @ 151]
b3b9cbd1 8b4df0 mov ecx,dword ptr [ebp-10h]

FAULTING_SOURCE_CODE:
147: UserMode,
148: MmNonCached ,
149: NULL,
150: FALSE,

151: LowPagePriority);
152: if (!devExt->UserSpaceCommonBuffer)
153: {
154: KdPrint (("MmMapLockedPagesSpecifyCache failed.\n"));
155: }
156:

SYMBOL_STACK_INDEX: 5

SYMBOL_NAME: Pci9x5x!PLxEvtIoControl+151

FOLLOWUP_NAME: MachineOwner

IMAGE_NAME: Pci9x5x.sys

BUCKET_ID: WRONG_SYMBOLS

Followup: MachineOwner

********************************************************************

Can you help ?

Thanks,
Zvika.

7

Hi Zvika,

Looks rather straightforward:
KERNEL_DATA_INPAGE_ERROR:
“In rare cases, it is caused when nonpaged pool resources run out”
(from MS Technet)

Arg2: d0000006, error status (normally i/o status code)
It is C0000006 - STATUS_IN_PAGE_ERROR, translated to HRESULT.

And - from MSDN
(http://msdn.microsoft.com/en-us/library/windows/hardware/ff554629(v=v
s.85%29.aspx) page " MmMapLockedPagesSpecifyCache routine":
" If AccessMode is UserMode and the specified pages cannot be mapped,
the routine raises an exception. Callers that specify UserMode must wrap
the call to MmMapLockedPagesSpecifyCache in a try/except block."

Best regards,
Alex Krol

9: kd> !analyze -v

***********************************************************************

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

***********************************************************************

********

KERNEL_DATA_INPAGE_ERROR (7a)
The requested page of kernel data could not be read in. Typically
caused by
a bad block in the paging file or disk controller error. Also see
KERNEL_STACK_INPAGE_ERROR.
If the error status is 0xC000000E, 0xC000009C, 0xC000009D or
0xC0000185,
it means the disk subsystem has experienced a failure.
If the error status is 0xC000009A, then it means the request failed
because
a filesystem failed to make forward progress.
Arguments:
Arg1: 00000001, lock type that was held (value 1,2,3, or PTE address)
Arg2: d0000006, error status (normally i/o status code)
Arg3: ff0522f0, current process (virtual address for lock type 3, or
PTE)
Arg4: c0006000, virtual address that could not be in-paged (or PTE
contents if arg1 is a PTE address)

Debugging Details:

ADDITIONAL_DEBUG_TEXT:
Use ‘!findthebuild’ command to search for the target build
information.
If the build information is available, run ‘!findthebuild -s ;
.reload’
to set symbol path and load symbols.

MODULE_NAME: Pci9x5x

FAULTING_MODULE: 80800000 nt

DEBUG_FLR_IMAGE_TIMESTAMP: 4edb586a

ERROR_CODE: (NTSTATUS) 0xd0000006 - The instruction at “0x%08lx”
referenced memory at “0x%08lx”. The required data was not placed into
memory because of an I/O error status of “0x%08lx”.

BUGCHECK_STR: 0x7a_d0000006

CUSTOMER_CRASH_COUNT: 3

DEFAULT_BUCKET_ID: DRIVER_FAULT_SERVER_MINIDUMP

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from 80851cd9 to 80827c63

STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may
be wrong.
b81e2a18 80851cd9 0000007a 00000001 d0000006 nt+0x27c63
b81e2a4c 80852458 ff0522f0 c0600030 ff0523d0 nt+0x51cd9
b81e2a68 8083c965 c0600030 ff0522f0 00000021 nt+0x52458
b81e2abc 80853372 ff03b000 ff0523d0 c0006280 nt+0x3c965
b81e2b14 b3b9cbd1 ff03b000 00000001 00000000 nt+0x53372
b81e2b7c f72fa072 7b59dfe8 00cec6e8 00000004
Pci9x5x!PLxEvtIoControl+0x151
[m:\zvi_vered\module\fio\windows\module\iocontrol.c @ 151]
b81e2ba0 f72fb3d0 7b59dfe8 00cec6e8 00000004 wdf01000+0x2f072
b81e2bd0 f72fd9ac 00cec6e8 ff313910 84a62010 wdf01000+0x303d0
b81e2bec f72fea36 84a62000 00000000 849b1658 wdf01000+0x329ac
b81e2c0c f7300824 ff313910 84a88e48 84a0f4f0 wdf01000+0x33a36
b81e2c30 f72efa3f 84a88e48 b81e2c50 8081df65 wdf01000+0x35824
b81e2c3c 8081df65 ff3fc4a8 84a88e48 8497e1a0 wdf01000+0x24a3f
b81e2c50 808f5437 84a88edc 8497e1a0 84a88e48 nt+0x1df65
b81e2c64 808f61bf ff3fc4a8 84a88e48 8497e1a0 nt+0xf5437
b81e2d00 808eed08 0000077c 00000758 00000000 nt+0xf61bf
b81e2d34 8088978c 0000077c 00000758 00000000 nt+0xeed08
b81e2d64 7c8285ec badb0d00 0012fd44 00000000 nt+0x8978c
b81e2d68 badb0d00 0012fd44 00000000 00000000 0x7c8285ec
b81e2d6c 0012fd44 00000000 00000000 00000000 0xbadb0d00
b81e2d70 00000000 00000000 00000000 00000000 0x12fd44

STACK_COMMAND: kb

FOLLOWUP_IP:
Pci9x5x!PLxEvtIoControl+151
[m:\zvi_vered\module\fio\windows\module\iocontrol.c @ 151]
b3b9cbd1 8b4df0 mov ecx,dword ptr [ebp-10h]

FAULTING_SOURCE_CODE:
147:
UserMode,
148:
MmNonCached ,
149:
NULL,
150:
FALSE,
> 151:
LowPagePriority);
152: if (!devExt->UserSpaceCommonBuffer)
153: {
154: KdPrint ((“MmMapLockedPagesSpecifyCache
failed.\n”));
155: }
156:

SYMBOL_STACK_INDEX: 5

SYMBOL_NAME: Pci9x5x!PLxEvtIoControl+151

FOLLOWUP_NAME: MachineOwner

IMAGE_NAME: Pci9x5x.sys

BUCKET_ID: WRONG_SYMBOLS

Followup: MachineOwner

********************************************************************

8

You might want to fix your symbols:

.symfix+
.reload -f -n

mm
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Alexander Krol
Sent: Monday, December 05, 2011 2:39 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] MmMapLockedPagesSpecifyCache: Blue dump under Server
2003-32

Hi Zvika,

Looks rather straightforward:
KERNEL_DATA_INPAGE_ERROR:
“In rare cases, it is caused when nonpaged pool resources run out”
(from MS Technet)

Arg2: d0000006, error status (normally i/o status code)
It is C0000006 - STATUS_IN_PAGE_ERROR, translated to HRESULT.

And - from MSDN
(http://msdn.microsoft.com/en-us/library/windows/hardware/ff554629(v=v
s.85%29.aspx) page " MmMapLockedPagesSpecifyCache routine":
" If AccessMode is UserMode and the specified pages cannot be mapped, the
routine raises an exception. Callers that specify UserMode must wrap the
call to MmMapLockedPagesSpecifyCache in a try/except block."

Best regards,
Alex Krol

> 9: kd> !analyze -v
>
***************************************************************
>
> *
> *
> * Bugcheck Analysis
> *
> *
> *
>
***************************************************************
>
>
> KERNEL_DATA_INPAGE_ERROR (7a)
> The requested page of kernel data could not be read in. Typically
> caused by a bad block in the paging file or disk controller error.
> Also see KERNEL_STACK_INPAGE_ERROR.
> If the error status is 0xC000000E, 0xC000009C, 0xC000009D or
> 0xC0000185, it means the disk subsystem has experienced a failure.
> If the error status is 0xC000009A, then it means the request failed
> because a filesystem failed to make forward progress.
> Arguments:
> Arg1: 00000001, lock type that was held (value 1,2,3, or PTE address)
> Arg2: d0000006, error status (normally i/o status code)
> Arg3: ff0522f0, current process (virtual address for lock type 3, or
> PTE)
> Arg4: c0006000, virtual address that could not be in-paged (or PTE
> contents if arg1 is a PTE address)
>
> Debugging Details:
> ------------------
>
> ADDITIONAL_DEBUG_TEXT:
> Use ‘!findthebuild’ command to search for the target build
information.
> If the build information is available, run ‘!findthebuild -s ;
.reload’
> to set symbol path and load symbols.
>
> MODULE_NAME: Pci9x5x
>
> FAULTING_MODULE: 80800000 nt
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 4edb586a
>
> ERROR_CODE: (NTSTATUS) 0xd0000006 - The instruction at “0x%08lx”
> referenced memory at “0x%08lx”. The required data was not placed into
> memory because of an I/O error status of “0x%08lx”.
>
> BUGCHECK_STR: 0x7a_d0000006
>
> CUSTOMER_CRASH_COUNT: 3
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT_SERVER_MINIDUMP
>
> CURRENT_IRQL: 0
>
> LAST_CONTROL_TRANSFER: from 80851cd9 to 80827c63
>
> STACK_TEXT:
> WARNING: Stack unwind information not available. Following frames may
> be wrong.
> b81e2a18 80851cd9 0000007a 00000001 d0000006 nt+0x27c63 b81e2a4c
> 80852458 ff0522f0 c0600030 ff0523d0 nt+0x51cd9
> b81e2a68 8083c965 c0600030 ff0522f0 00000021 nt+0x52458 b81e2abc
> 80853372 ff03b000 ff0523d0 c0006280 nt+0x3c965
> b81e2b14 b3b9cbd1 ff03b000 00000001 00000000 nt+0x53372 b81e2b7c
> f72fa072 7b59dfe8 00cec6e8 00000004
> Pci9x5x!PLxEvtIoControl+0x151
> [m:\zvi_vered\module\fio\windows\module\iocontrol.c @ 151]
> b81e2ba0 f72fb3d0 7b59dfe8 00cec6e8 00000004 wdf01000+0x2f072
> b81e2bd0 f72fd9ac 00cec6e8 ff313910 84a62010 wdf01000+0x303d0 b81e2bec
> f72fea36 84a62000 00000000 849b1658 wdf01000+0x329ac b81e2c0c f7300824
> ff313910 84a88e48 84a0f4f0 wdf01000+0x33a36
> b81e2c30 f72efa3f 84a88e48 b81e2c50 8081df65 wdf01000+0x35824 b81e2c3c
> 8081df65 ff3fc4a8 84a88e48 8497e1a0 wdf01000+0x24a3f
> b81e2c50 808f5437 84a88edc 8497e1a0 84a88e48 nt+0x1df65
> b81e2c64 808f61bf ff3fc4a8 84a88e48 8497e1a0 nt+0xf5437
> b81e2d00 808eed08 0000077c 00000758 00000000 nt+0xf61bf
> b81e2d34 8088978c 0000077c 00000758 00000000 nt+0xeed08
> b81e2d64 7c8285ec badb0d00 0012fd44 00000000 nt+0x8978c
> b81e2d68 badb0d00 0012fd44 00000000 00000000 0x7c8285ec b81e2d6c
> 0012fd44 00000000 00000000 00000000 0xbadb0d00
> b81e2d70 00000000 00000000 00000000 00000000 0x12fd44
>
>
> STACK_COMMAND: kb
>
> FOLLOWUP_IP:
> Pci9x5x!PLxEvtIoControl+151
> [m:\zvi_vered\module\fio\windows\module\iocontrol.c @ 151]
> b3b9cbd1 8b4df0 mov ecx,dword ptr [ebp-10h]
>
> FAULTING_SOURCE_CODE:
> 147:
> UserMode,
> 148:
> MmNonCached ,
> 149:
> NULL,
> 150:
> FALSE,
> > 151:
> LowPagePriority);
> 152: if (!devExt->UserSpaceCommonBuffer)
> 153: {
> 154: KdPrint ((“MmMapLockedPagesSpecifyCache
> failed.\n”));
> 155: }
> 156:
>
>
> SYMBOL_STACK_INDEX: 5
>
> SYMBOL_NAME: Pci9x5x!PLxEvtIoControl+151
>
> FOLLOWUP_NAME: MachineOwner
>
> IMAGE_NAME: Pci9x5x.sys
>
> BUCKET_ID: WRONG_SYMBOLS
>
> Followup: MachineOwner
> ---------
> ********************************************************************

—
NTDEV is sponsored by OSR

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

9

Hello,

If I wrap MmMapLockedPagesSpecifyCache with try/except, windows will not crash but MmMapLockedPagesSpecifyCache will fail.

I want to map a preallocated buffer to a user space address upon IOCTL request.

Can you help ?

Thanks,
Zvika.

10

I think MmNonCached conflicts with the actual allocated memory type. Map as cached.

11

xxxxx@broadcom.com wrote Monday, December 05, 2011 4:42 PM

I think MmNonCached conflicts with the actual allocated memory type.
Map as cached.

No, he allocated common buffer with CacheEnabled = FALSE.
Looks like plain resource problem - though, strangely enough, he sees it
on Server2003, with larger paged pool, but not on XP.
Zvika, run poolmon on problematic station - at least, you’ll see what is
happening there.

Best regards,
Alex Krol

12

>No, he allocated common buffer with CacheEnabled = FALSE.

The documentation for AllocateCommonBuffer states that CacheEnabled is ignored and the memory is always allocated as cached.

13

On 05-Dec-2011 19:47, xxxxx@broadcom.com wrote:

> No, he allocated common buffer with CacheEnabled = FALSE.

The documentation for AllocateCommonBuffer states that CacheEnabled is ignored and the memory is always allocated as cached.

Ok, so let the OP repeat the exercise with CacheEnabled=TRUE and let us
know results.

– pa

14

On 12/5/2011 9:41 AM, xxxxx@broadcom.com wrote:

I think MmNonCached conflicts with the actual allocated memory type. Map as cached.

MmMapLockedPagesSpecifyCache implements a cache override for pages
within the PFN database, so it really doesn’t matter what cache
attributes you specify. (At least that is the case for w2k3 and later.)

15

> MmMapLockedPagesSpecifyCache implements a cache override for pages within the PFN database

If a memory location is accessed as cached and non-cached at the same time, all hell breaks loose. The OS does not allow that. At least should try to not allow.

16

Hello,

I tried to allocate the buffer with:

devExt->KernelCommonBuffer = AllocateCommonBuffer (DmaAdapter, 32*1024*1024,&LogicalAddress, TRUE);

devExt->CommonBufferMdl = IoAllocateMdl (devExt->KernelCommonBuffer,32*1024*1024,FALSE,FALSE,NULL);

MmBuildMdlForNonPagedPool (devExt->CommonBufferMdl).

Upon IOCTL request I call to:

devExt->UserSpaceCommonBuffer = MmMapLockedPagesSpecifyCache (devExt->CommonuBufferMdl,UserMode,MmCached,NULL,FALSE,HighPagePriority)

But the results are the same. There is a crash.

Can you help ?

Thanks,
Zvika.

17

Have you run poolmon with your call to MmMapLockedPagesSpecifyCache
guarded by try/except block?
You need to catch this exception, Zvika, otherwise you’ll have blue
screen in case of resource starving (just run your supposedly working
driver on XP under Driver Verifier).

Best regards,
Alex Krol

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-485534-
xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Tuesday, December 06, 2011 8:01 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] MmMapLockedPagesSpecifyCache: Blue dump under
Server 2003-32

Hello,

I tried to allocate the buffer with:

devExt->KernelCommonBuffer = AllocateCommonBuffer (DmaAdapter,
32*1024*1024,&LogicalAddress, TRUE);

devExt->CommonBufferMdl = IoAllocateMdl (devExt-
>KernelCommonBuffer,32*1024*1024,FALSE,FALSE,NULL);

MmBuildMdlForNonPagedPool (devExt->CommonBufferMdl).

Upon IOCTL request I call to:

devExt->UserSpaceCommonBuffer = MmMapLockedPagesSpecifyCache (devExt-
>CommonuBufferMdl,UserMode,MmCached,NULL,FALSE,HighPagePriority)

But the results are the same. There is a crash.

Can you help ?

Thanks,
Zvika.

NTDEV is sponsored by OSR

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

18

In what context are you calling MmMap*?

19

Have you ever considered

#define BLOCK_SIZE (32 * 1024 * 1024)

as a way to not reproduce the same bizarre formulate in two places?

That said, I see no test here of the form

if(devExt->KernelCommonBuffer == NULL)
{ /* unable to allocate */
…deal with failed allocation
} /* unable to allocate */

In fact, I see no tests anywhere that indicate you have tested for failure
from any of the calls Since there is no error checking, it is safe to
assume that any failure anywhere merely propagates until somebody gets an
unacceptable error value, then it bluescreens. A key rule of driver
programming: THERE SHALL BE NO FAILURES THAT GO UNDETECTED AND FOR ALL
FAILURES YOU WILL PROVIDE GRACEFUL ERROR RECOVERY.

I see neither detection nor recovery in this code.
joe

Hello,

I tried to allocate the buffer with:

devExt->KernelCommonBuffer = AllocateCommonBuffer (DmaAdapter,
32*1024*1024,&LogicalAddress, TRUE);

devExt->CommonBufferMdl = IoAllocateMdl
(devExt->KernelCommonBuffer,32*1024*1024,FALSE,FALSE,NULL);

MmBuildMdlForNonPagedPool (devExt->CommonBufferMdl).

Upon IOCTL request I call to:

devExt->UserSpaceCommonBuffer = MmMapLockedPagesSpecifyCache
(devExt->CommonuBufferMdl,UserMode,MmCached,NULL,FALSE,HighPagePriority)

But the results are the same. There is a crash.

Can you help ?

Thanks,
Zvika.

NTDEV is sponsored by OSR

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

20

Dear Joe,

My code has #define BLOCK_SIZE (32*1024*1024)
I also checked each step in the allocation.

Under XP, all the tests are OK and MmMapLockedPagesSpecifyCache works fine.
Under Server2003-32 and Server2008-64, cause a crash.

Thanks,
Zvika.

On Tue, Dec 6, 2011 at 7:57 PM, wrote:
> Have you ever considered
>
> #define BLOCK_SIZE (32 * 1024 * 1024)
>
> as a way to not reproduce the same bizarre formulate in two places?
>
> That said, I see no test here of the form
>
> if(devExt->KernelCommonBuffer == NULL)
> ? { /* unable to allocate /
> ? ?..deal with failed allocation
> ? } / unable to allocate /
>
> In fact, I see no tests anywhere that indicate you have tested for failure
> from any of the calls ?Since there is no error checking, it is safe to
> assume that any failure anywhere merely propagates until somebody gets an
> unacceptable error value, then it bluescreens. ?A key rule of driver
> programming: THERE SHALL BE NO FAILURES THAT GO UNDETECTED AND FOR ALL
> FAILURES YOU WILL PROVIDE GRACEFUL ERROR RECOVERY.
>
> I see neither detection nor recovery in this code.
> ? ? joe
>
>
>> Hello,
>>
>> I tried to allocate the buffer with:
>>
>> devExt->KernelCommonBuffer = AllocateCommonBuffer (DmaAdapter,
>> 3210241024,&LogicalAddress, TRUE);
>>
>> devExt->CommonBufferMdl = IoAllocateMdl
>> (devExt->KernelCommonBuffer,321024*1024,FALSE,FALSE,NULL);
>>
>> MmBuildMdlForNonPagedPool (devExt->CommonBufferMdl).
>>
>> Upon IOCTL request I call to:
>>
>> devExt->UserSpaceCommonBuffer = MmMapLockedPagesSpecifyCache
>> (devExt->CommonuBufferMdl,UserMode,MmCached,NULL,FALSE,HighPagePriority)
>>
>> But the results are the same. There is a crash.
>>
>> Can you help ?
>>
>> Thanks,
>> Zvika.
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> 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
>
> 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