Dear Members,
Upon DriverEntry I call to the following code to allocate a 16MB of
configuous buffer.
NTSTATUS AllocateContinuousPhysicalMemory (IN PDEVICE_EXTENSION DevExt)
{
PHYSICAL_ADDRESS HighestAcceptableAddress = {0x0,0xFFFFFFFF};
PHYSICAL_ADDRESS LowestAcceptableAddress = {0x0,0x0};
PHYSICAL_ADDRESS BoundaryAddressMultiple = {0x0,0x0};
DevExt->KernelCommonBuffer = MmAllocateContiguousMemorySpecifyCache
(COMMON_BUFFER_SIZE,
LowestAcceptableAddress,
HighestAcceptableAddress,
BoundaryAddressMultiple,
MmCached);
if (!DevExt->KernelCommonBuffer)
{
KdPrint ((“MmAllocateContiguousMemory failed\n”));
return STATUS_INSUFFICIENT_RESOURCES;
}
DevExt->CommonBufferMdl = IoAllocateMdl
(DevExt->KernelCommonBuffer,COMMON_BUFFER_SIZE,FALSE, FALSE, NULL);
if (!DevExt->CommonBufferMdl)
{
KdPrint ((“IoAllocateMdl failed.\n”));
return STATUS_INSUFFICIENT_RESOURCES;
}
MmBuildMdlForNonPagedPool (DevExt->CommonBufferMdl);
return STATUS_SUCCESS;
}
The allocation works fine. As you can see I checked that CommonBufferMdl and
KernelCommonBuffer are valid
Now I have to map this buffer to user space. So upon IOCTL request from user
space I call to the following code:
…
case FIOA_ALLOCATE_COMMON_BUFFER:
status = WdfRequestRetrieveOutputBuffer
(Request,sizeof(FIOA_READ_LONG_REPLY),
&pOutBuffer, &Length);
pReadReply = (FIOA_READ_LONG_REPLY *)pOutBuffer;
bytesReturned = sizeof(FIOA_READ_LONG_REPLY);
//Map common buffer to user space. This can be done only upon IOCTL
request
__try
{
devExt->UserSpaceCommonBuffer =
MmMapLockedPagesSpecifyCache(devExt->CommonBufferMdl,
UserMode,
MmCached ,
NULL,
FALSE,
NormalPagePriority);
if (!devExt->UserSpaceCommonBuffer)
{
KdPrint ((“MmMapLockedPagesSpecifyCache failed.\n”));
}
}
__except (EXCEPTION_EXECUTE_HANDLER)
{
devExt->UserSpaceCommonBuffer = 0x0;
KdPrint ((“MmMapLockedPagesSpecifyCache caused exception:
%x\n”,GetExceptionCode()));
}
pReadReply->Data = devExt->UserSpaceCommonBuffer;
WdfRequestCompleteWithInformation
(Request,STATUS_SUCCESS,sizeof(long));
break;
…
When I send the FIOA_ALLOCATE_COMMON_BUFFER request I get blue dump.
Following is the analyze -v of the dump file:
Microsoft (R) Windows Debugger Version 6.12.0002.633 X86
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [\1public\PUBLIC\a99059\Mini121311-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available
Symbol search path is:
M:\zvi_vered\module\FIO_YOYO\windows\module\objchk_wnet_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: Tue Dec 13 11:33:33.408 2011 (UTC + 2:00)
System Uptime: 0 days 0:23:15.890
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, 8524cd88, 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
*** WARNING: Unable to verify timestamp for Npfs.SYS
*** ERROR: Module load completed but symbols could not be loaded for
Npfs.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+1a1 )
Followup: MachineOwner
20: 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: 8524cd88, 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: 4ee71b46
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: 1
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.
b84c39ec 80851cd9 0000007a 00000001 d0000006 nt+0x27c63
b84c3a20 80852458 8524cd88 c0600030 8524ce68 nt+0x51cd9
b84c3a3c 8083c965 c0600030 8524cd88 00000021 nt+0x52458
b84c3a90 80853372 8522b000 8524ce68 c0006280 nt+0x3c965
b84c3ae8 b8de5b01 8522b000 00000001 00000001 nt+0x53372
b84c3b7c f72fa072 7b57a1f8 7ad0cfe8 00000004 Pci9x5x!PLxEvtIoControl+0x1a1
[m:\zvi_vered\module\fio_yoyo\windows\module\iocontrol.c @ 154]
b84c3ba0 f72fb3d0 7b57a1f8 7ad0cfe8 00000004 wdf01000+0x2f072
b84c3bd0 f72fd9ac 7ad0cfe8 852f3010 84a85e00 wdf01000+0x303d0
b84c3bec f72fea36 84a85e00 00000000 84a215e8 wdf01000+0x329ac
b84c3c0c f7300824 852f3010 852e4368 85301668 wdf01000+0x33a36
b84c3c30 f72efa3f 852e4368 b84c3c50 8081df65 wdf01000+0x35824
b84c3c3c 8081df65 85234138 852e4368 84a5c388 wdf01000+0x24a3f
b84c3c50 808f5437 852e43fc 84a5c388 852e4368 nt+0x1df65
b84c3c64 808f61bf 85234138 852e4368 84a5c388 nt+0xf5437
b84c3d00 808eed08 0000077c 00000758 00000000 nt+0xf61bf
b84c3d34 8088978c 0000077c 00000758 00000000 nt+0xeed08
b84c3d64 7c8285ec badb0d00 0012fd44 00000000 nt+0x8978c
b84c3d68 badb0d00 0012fd44 00000000 00000000 0x7c8285ec
b84c3d6c 0012fd44 00000000 00000000 00000000 Npfs+0x4d00
b84c3d70 00000000 00000000 00000000 00000000 0x12fd44
STACK_COMMAND: kb
FOLLOWUP_IP:
Pci9x5x!PLxEvtIoControl+1a1
[m:\zvi_vered\module\fio_yoyo\windows\module\iocontrol.c @ 154]
b8de5b01 8b55d8 mov edx,dword ptr [ebp-28h]
FAULTING_SOURCE_CODE:
150: UserMode,
151: MmCached ,
152: NULL,
153: FALSE,
154:
NormalPagePriority);
155:
156: if (!devExt->UserSpaceCommonBuffer)
157: {
158: KdPrint ((“MmMapLockedPagesSpecifyCache
failed.\n”));
159: }
SYMBOL_STACK_INDEX: 5
SYMBOL_NAME: Pci9x5x!PLxEvtIoControl+1a1
FOLLOWUP_NAME: MachineOwner
IMAGE_NAME: Pci9x5x.sys
BUCKET_ID: WRONG_SYMBOLS
Followup: MachineOwner
As you can see the reason for the exception is MmMapLockedPagesSpecifyCache.
I built the driver with “build -ceZ -w” and also ran PreFast. There are no
relevant warnings.
But why ??? What am I doing wrong ?
Is it possible that mapping to user space is not possible under
Server2003-32 ?
The buffer has to be contiguous because this is what the FPGA needs.
I read many answers on this problem but did not find an answer.
Thank you in advance for your reply.
Best regards,
Zvika.