none
MmMapIoSpace crashing RRS feed

  • Question

  • Hi,

    I am writing a driver for PCI based multiport serial controller. I am writing two drivers for this.

    1. Controller driver that creates FDO for the PCI controller and enumerates the ports on the controller.  THis driver also calculates the memory address and amount of memory needed for each port and provides it to the Port driver. 

    2. A port driver that creates an FDO for each port. THis driver receives base address of physical memory space and it's length for the port from the controller driver via QUERY_INTERFACE call. THen it maps those physical address space to virtual addresses using MmMapIoSpace. 

    I am using my own Interface structure with WdfFDOQueryInterface call to exchange interfaces between the drivers.

    In the controller driver i am storing the address received from PCM_PARTIAL_RESOURCE_DESCRIPTOR->u.Memory.Start and calculating the memory resources for each port from this stored address. I am sending memory resources to Port driver Via the custom interface structure.  

    In port driver when i receive the address of the Physical  memory  and its length using WdfFDOQueryInterface call, and  map the physical memory using MmMapIoSpace , my port driver is crashing. 

    Is it correct to map a the physical adress this way or is there any mistake in this? 

    Wednesday, June 18, 2014 12:37 PM

Answers

  • This is the correct way to do things, be sure you are using the translated resources in the controller driver.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Wednesday, June 18, 2014 12:57 PM

All replies

  • This is the correct way to do things, be sure you are using the translated resources in the controller driver.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Wednesday, June 18, 2014 12:57 PM
  • I just confirmed, i am using translated resources only. 

    Just to confirm once again I am calling MmMapIoSpace in Child FDO driver (i.e. Port driver) not in Controller driver. 

    in MmMapIoSpace, For the first parameter, I am passing whatever address the framework returned to me in 

    "PCM_PARTIAL_RESOURCE_DESCRIPTOR->u.Memory.Start" in the controller driver. 

    I am giving the memory length as 0x200. Could that be causing the crash? 

    in general what could be the reasons the MmMapIoSpace funciton can crash?

    Wednesday, June 18, 2014 3:06 PM
  • How big is the actual register space for the device?  512 bytes seems large.  Trying to map memory that is not there will cause problems, so if either the start address or the length is off the call will fail.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Wednesday, June 18, 2014 3:10 PM
  • what happens if you call MmMapIoSpace in the parent FDO and return the mapped address to the child PDO in the custom interface? does the MmMapIoSpace call still crash? are you hard coding 0x200 or using the length that is in the assigned resource descriptor?

    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Wednesday, June 18, 2014 4:33 PM
  • Just checked in the data sheet about the register space of teh device in memory mapping mode. It is 512 bytes per  UART. The memory space for each UART is laid out contiguously at offsets of 512 bytes.

    About trying MmMapIoSpace in Parent FDO, i also had the same idea :-) ... I will try it out tomorrow. 

    I am not hard coding the values for length. I am using the length in the assigned resource descriptor. 

    I have a question though. In the device manger, i  checked the properties of the controller device. In the resources tab, i am seeing that 4K bytes are allocated for memory resources. (Although i didn't map the hardware resources in the controller driver). Who is allocating these resources to the controller?

    I think the starting  address of the memory  that i am seeing in the resources tab for the controller is the same as what i am passing to MmMapIoSpace in the port driver. Could this lead to a conflict and lead to crash?

    if the above is true, what should be done to avoid Windows to allocate the memory resources for the controller automatically? 



    Wednesday, June 18, 2014 5:37 PM
  • the resources will always be assigned to the controller. that is the FDO parent which gets the translated resources. there is no conflict with the resources. they are assigned to the device by pci.sys based on the BARs your device reports.

    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Wednesday, June 18, 2014 5:40 PM
  • The memory resources reported by the device manager are what the hardware is reporting to the PCI.SYS driver which manages the PCI bus.  There is no "allocation" in the sense you are thinking of, this is what the device has in its PCI configuration space.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Wednesday, June 18, 2014 5:41 PM
  • I am analyzng the dump file created by the crash, but don't know how to progress with the contents. I am pasting the contents of the dump file below. Can somebody please give a clue?

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

    PAGE_FAULT_IN_NONPAGED_AREA (50)
    Invalid system memory was referenced.  This cannot be protected by try-except,
    it must be protected by a Probe.  Typically the address is just plain bad or it
    is pointing at freed memory.
    Arguments:
    Arg1: c057e004, memory referenced.
    Arg2: 00000001, value 0 = read operation, 1 = write operation.
    Arg3: 830c1342, If non-zero, the instruction address which referenced the bad memory
     address.
    Arg4: 00000009, (reserved)

    Debugging Details:
    ------------------

    *** ERROR: Module load completed but symbols could not be loaded for Unknown_Module_999af000
    *** ERROR: Module load completed but symbols could not be loaded for Wdf01000.sys
    Unknown module 'Unknown_Module_999af000' found on stack, using vad to reload module.
    !vad_reload -1 0xffffffff999af000
    *************************************************************************
    ***                                                                   ***
    ***                                                                   ***
    ***    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!_EPROCESS                                  ***
    ***                                                                   ***
    *************************************************************************
    *************************************************************************
    ***                                                                   ***
    ***                                                                   ***
    ***    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!_EPROCESS                                  ***
    ***                                                                   ***
    *************************************************************************
    Failed to get old VAD root
    ***** 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                                     ***
    ***                                                                   ***
    *************************************************************************
    *************************************************************************
    ***                                                                   ***
    ***                                                                   ***
    ***    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                                     ***
    ***                                                                   ***
    *************************************************************************
    *************************************************************************
    ***                                                                   ***
    ***                                                                   ***
    ***    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.

    FAULTING_MODULE: 83051000 nt

    DEBUG_FLR_IMAGE_TIMESTAMP:  53a1a60f

    WRITE_ADDRESS: unable to get nt!MmSpecialPoolStart
    unable to get nt!MmSpecialPoolEnd
    unable to get nt!MmPoolCodeStart
    unable to get nt!MmPoolCodeEnd
     c057e004

    FAULTING_IP:
    nt!MmMapIoSpace+3fb
    830c1342 894e04          mov     dword ptr [esi+4],ecx

    MM_INTERNAL_CODE:  9

    DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

    BUGCHECK_STR:  0x50

    CURRENT_IRQL:  0

    LAST_CONTROL_TRANSFER:  from 83091ae8 to 830deb3f

    STACK_TEXT: 
    WARNING: Stack unwind information not available. Following frames may be wrong.
    8dd8b614 83091ae8 00000001 c057e004 00000000 nt!IoGetRelatedDeviceObject+0x80d
    8dd8b6f0 83116781 8306046c 00000065 00000003 nt!Kei386EoiHelper+0x27e0
    8dd8b710 999b0098 00000000 00000000 00000000 nt!vsnprintf+0x534
    8dd8b734 8ba236ea 7a3851a8 78cec1e8 7a3b2ef0 Unknown_Module_999af000+0x1098
    8dd8b764 8ba230b2 85d108d0 00000108 00000003 Wdf01000+0x226ea
    8dd8b784 8ba22fc1 85d108d0 85d108d0 8ba6d850 Wdf01000+0x220b2
    8dd8b7b8 8ba22e78 85d108d0 00000108 85d1098c Wdf01000+0x21fc1
    8dd8b7dc 8ba212bc 8dd8b800 85d108d0 85d339a0 Wdf01000+0x21e78
    8dd8b814 8ba233c1 85d108d0 00000002 85d108d0 Wdf01000+0x202bc
    8dd8b828 8ba0db07 85d108d0 8dd8b848 85c7af14 Wdf01000+0x223c1
    8dd8b854 8ba04bc2 873336f0 85c7ad28 873336f0 Wdf01000+0xcb07
    8dd8b87c 8ba04a33 85c7ad28 873336f0 873337a8 Wdf01000+0x3bc2
    8dd8b898 83087c29 85c7ad28 873336f0 8dd8b920 Wdf01000+0x3a33
    8dd8b8b0 832107a0 00000000 85b417b0 886428b8 nt!IofCallDriver+0x64
    8dd8b8cc 830632bb 8dd8b8fc 8306609f 886428b8 nt!IoClearDependency+0x537
    8dd8b930 83207609 8306609f 886428b8 85b415f8 nt!IoAttachDeviceToDeviceStack+0x3c1
    8dd8b98c 832074d2 886428b8 0000000f 00000000 nt!IoSetDevicePropertyData+0x1e1e
    8dd8b9a8 8320eee5 00000000 00000000 883b65c8 nt!IoSetDevicePropertyData+0x1ce7
    8dd8bba4 832deca6 85b415f8 883b65c8 8dd8bbd0 nt!RtlUnicodeStringToOemString+0x1137
    8dd8bbd8 83065ce7 831b6b00 85b02a70 8318d3bc nt!SeAuditingHardLinkEventsWithContext+0x1a0
    8dd8bc00 830ce1eb 00000000 00000000 85b02a70 nt!IoQueueThreadIrp+0x289
    8dd8bc50 8325b07a 00000001 af4962c8 00000000 nt!KeInsertQueueDpc+0x382
    8dd8bc90 83101819 830ce0de 00000001 00000000 nt!RtlAnsiStringToUnicodeString+0x19d
    00000000 00000000 00000000 00000000 00000000 nt!KeInitializeTimerEx+0x3ca


    STACK_COMMAND:  kb

    FOLLOWUP_IP:
    Unknown_Module_999af000+1098
    999b0098 8b4dfc          mov     ecx,dword ptr [ebp-4]

    SYMBOL_STACK_INDEX:  3

    SYMBOL_NAME:  Unknown_Module_999af000+1098

    FOLLOWUP_NAME:  MachineOwner

    MODULE_NAME: Unknown_Module_999af000

    IMAGE_NAME:  Unknown_Module_999af000

    BUCKET_ID:  WRONG_SYMBOLS

    Followup: MachineOwner
    ---------


    • Edited by rajujayanthy Thursday, June 19, 2014 9:07 AM pasted the complete contents of dump file
    Thursday, June 19, 2014 8:57 AM
  • it says invalid memory access. But i am mapping the same memory address the controller driver got ViA Preparehardware call (in translated resources). But i am mapping the address in the Port driver (i.e. Child FDO)

    What could be going wrong here?

    Thursday, June 19, 2014 9:09 AM
  • Fix your symbols, look at http://support.microsoft.com/kb/311503


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Thursday, June 19, 2014 10:22 AM
  • i have copied the path for microsoft  symbol server into WIndbg. .sympath command is not showing any warning. Hence i assumed symbols path is set properly.

    below is the kernel dump after fixing the symbol path.

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

    PAGE_FAULT_IN_NONPAGED_AREA (50)
    Invalid system memory was referenced.  This cannot be protected by try-except,
    it must be protected by a Probe.  Typically the address is just plain bad or it
    is pointing at freed memory.
    Arguments:
    Arg1: c057e004, memory referenced.
    Arg2: 00000001, value 0 = read operation, 1 = write operation.
    Arg3: 830c1342, If non-zero, the instruction address which referenced the bad memory
     address.
    Arg4: 00000009, (reserved)

    Debugging Details:
    ------------------

    *** ERROR: Module load completed but symbols could not be loaded for Unknown_Module_999af000
    Unknown module 'Unknown_Module_999af000' found on stack, using vad to reload module.
    !vad_reload -1 0xffffffff999af000

    WRITE_ADDRESS:  c057e004

    FAULTING_IP:
    nt!MmMapIoSpace+3fb
    830c1342 894e04          mov     dword ptr [esi+4],ecx

    MM_INTERNAL_CODE:  9

    DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

    BUGCHECK_STR:  0x50

    PROCESS_NAME:  System

    CURRENT_IRQL:  0

    TRAP_FRAME:  8dd8b62c -- (.trap 0xffffffff8dd8b62c)
    ErrCode = 00000002
    eax=01b08963 ebx=00000000 ecx=00000000 edx=8442f4ee esi=c057e000 edi=00000fff
    eip=830c1342 esp=8dd8b6a0 ebp=8dd8b710 iopl=0         nv up ei pl zr na pe nc
    cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010246
    nt!MmMapIoSpace+0x3fb:
    830c1342 894e04          mov     dword ptr [esi+4],ecx ds:0023:c057e004=????????
    Resetting default scope

    LOCK_ADDRESS:  831b8be0 -- (!locks 831b8be0)

    Resource @ nt!PiEngineLock (0x831b8be0)    Exclusively owned
        Contention Count = 7
         Threads: 85b02a70-01<*>
    1 total locks, 1 locks currently held

    PNP_TRIAGE:
     Lock address  : 0x831b8be0
     Thread Count  : 1
     Thread address: 0x85b02a70
     Thread wait   : 0x57dd

    LAST_CONTROL_TRANSFER:  from 83091ae8 to 830deb3f

    STACK_TEXT: 
    8dd8b614 83091ae8 00000001 c057e004 00000000 nt!MmAccessFault+0x106
    8dd8b614 830c1342 00000001 c057e004 00000000 nt!KiTrap0E+0xdc
    8dd8b710 999b0098 00000000 00000000 00000000 nt!MmMapIoSpace+0x3fb
    WARNING: Stack unwind information not available. Following frames may be wrong.
    8dd8b734 8ba236ea 7a3851a8 78cec1e8 7a3b2ef0 Unknown_Module_999af000+0x1098
    8dd8b764 8ba230b2 85d108d0 00000108 00000003 Wdf01000!FxPkgPnp::PnpPrepareHardware+0xba
    8dd8b784 8ba22fc1 85d108d0 85d108d0 8ba6d850 Wdf01000!FxPkgPnp::PnpEventHardwareAvailable+0x76
    8dd8b7b8 8ba22e78 85d108d0 00000108 85d1098c Wdf01000!FxPkgPnp::PnpEnterNewState+0x139
    8dd8b7dc 8ba212bc 8dd8b800 85d108d0 85d339a0 Wdf01000!FxPkgPnp::PnpProcessEventInner+0x1c1
    8dd8b814 8ba233c1 85d108d0 00000002 85d108d0 Wdf01000!FxPkgPnp::PnpProcessEvent+0x142
    8dd8b828 8ba0db07 85d108d0 8dd8b848 85c7af14 Wdf01000!FxPkgPnp::_PnpStartDevice+0x1b
    8dd8b84c 8301fba9 8dd8b87c 8ba04bc2 873336f0 Wdf01000!FxPkgPnp::Dispatch+0x1ad
    8dd8b920 8301d7ab 830661bf af496768 8dd8b98c hal!KfLowerIrql+0x61
    8dd8b924 830661bf af496768 8dd8b98c 83207609 hal!KfReleaseSpinLock+0xb
    8dd8b98c 832074d2 886428b8 0000000f 00000000 nt!PnpDeviceCompletionQueueAddDispatchedRequest+0x4b
    8dd8b9a8 8320eee5 00000000 00000000 883b65c8 nt!PipProcessStartPhase1+0x62
    8dd8bba4 832deca6 85b415f8 883b65c8 8dd8bbd0 nt!PipProcessDevNodeTree+0x188
    8dd8bbd8 83065ce7 831b6b00 85b02a70 8318d3bc nt!PiRestartDevice+0x8a
    8dd8bc00 830ce1eb 00000000 00000000 85b02a70 nt!PnpDeviceActionWorker+0x1fb
    8dd8bc50 8325b07a 00000001 af4962c8 00000000 nt!ExpWorkerThread+0x10d
    8dd8bc90 83101819 830ce0de 00000001 00000000 nt!PspSystemThreadStartup+0x9e
    00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x19


    STACK_COMMAND:  kb

    FOLLOWUP_IP:
    Unknown_Module_999af000+1098
    999b0098 8b4dfc          mov     ecx,dword ptr [ebp-4]

    SYMBOL_STACK_INDEX:  3

    SYMBOL_NAME:  Unknown_Module_999af000+1098

    FOLLOWUP_NAME:  MachineOwner

    MODULE_NAME: Unknown_Module_999af000

    IMAGE_NAME:  Unknown_Module_999af000

    DEBUG_FLR_IMAGE_TIMESTAMP:  53a1a60f

    FAILURE_BUCKET_ID:  0x50_Unknown_Module_999af000+1098

    BUCKET_ID:  0x50_Unknown_Module_999af000+1098

    Followup: MachineOwner

    Thursday, June 19, 2014 12:38 PM
  • It is crashing wiht Invalid memory address. I don't understand how the address could be invalid. This address is provided by the PnP manager only.

    Thursday, June 19, 2014 12:42 PM
  • Check your parameters to the MmMapIoSpace call, the stack walkback appears to indicate they are all zero or NULL.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Thursday, June 19, 2014 12:44 PM
  • I am printing the addresses in the log before passing them to MmapIoSpace.. They are showing valid values.

    But when i uncomment the code for MmapIoSpace it gives a crash. 

    Is it possible to map the addresses in controller driver and send the virtual addresses to Port driver and use them there? 

     

    Friday, June 20, 2014 6:20 AM
  • When i map the addresses in Controller driver, i am not getting any error.

    But when i am mapping the same address in Port driver driver I am getting a crash.

    I am a little doubtful about the connections between my controller driver and port driver. If it was WDM, i would have established a connection between  these two drivers by ioattachdevicetodevicestack funciton. But since this is WDF, i am doing any such stuff. How WIll my controller device object and port device object driver be automatically connected to each other? The only way i am seeing that they are connected is like below.

    I am installing the controller driver via an .inf file and creating PDOs with a specific HardwareID and vendor ID.

    I am using the same hardware ID in the port driver's .inf file and hence the port driver is installing over the PDOs created by the controller driver. Is it sufficient to say that a connection is successfully established between the controller driver and port driver? 

    If not, in such case, it it allowed to pass the addresses from controller driver to port driver ? Because it is like passing memory resources across two independent drivers. One driver is trying to map the addresses given by the other driver. 




    • Edited by rajujayanthy Friday, June 20, 2014 2:07 PM corrected serial driver to port driver
    Friday, June 20, 2014 2:05 PM
  • WDF handles the attachment along with other boiler plate.  As long as you are using hardware ID X to create the PDO, and in the INF for the port driver then the port driver will get attached to the PDO.

    Fire up the debugger and see what the difference in the call to MmMapIoSpace between doing it at the port driver or the controller driver.  I've used the bus driver model like this for a dozen years and have never seen the problems you report.   Also, you concern about the connections, it is actually possible to pass a memory resource to an independant driver and have it map it, the problems with such an approach come in ensuring both drivers stay in sync, but it will not fail.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Friday, June 20, 2014 2:19 PM
  • validate that the value you think you are assigning yo the port driver is still valid after the QI results in the port driver. If it is being mangled, you have a place to start debugging

    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Friday, June 20, 2014 2:50 PM
  • Doron,

    After the memory addresses are returned from QueryInterface call, I am printng the memory addresses in the logs and they are same as what the framework provided us. 

    Is there another way to validate the addresses? I mean is there any API which takes an address and validates it?

    Don,

    Does it help to run WDFLogdump command after installing the controller and port driver and see whether the addresses are being mangled?

    Saturday, June 21, 2014 7:59 AM
  • Found out that the same code is working fine for one PDO. That is MmMapIoSpace is executing successfully when i created a single PDO in the controller driver. 

    But it crashes when i create multiple PDOs. Could this be a problem of invalid allocation of memory? or synchronization while mapping the memory?



    Monday, June 23, 2014 8:15 AM