none
BSOD in usb class filter driver RRS feed

  • Question

  • Having a simple Usb class filter driver. I am trying to attach it to the device object in DEVICE_RELATIONS::Objects which are received in IRP_MJ_PNP / IRP_MJ_QUERY_DEVICE_RELATION / BusRelations.

    I am testing this on Virtualbox / windows7 / 32bit.

    It is causing BSOD, probably at IoAttachDeviceToDeviceStack() for child device (device objects in DEVICE_RELATION::Objects). Is it correct way to attach filter to child devices?

    Consider code below in which *Hub* relates bus device and *Tgt* to child device.

    ==============================
    ==

    NTSTATUS UsbFilterPnp(PDEVICE_OBJECT ipDeviceObject, PIRP ipIrp)
    {
    ...
    ...
        case IRP_MN_QUERY_DEVICE_RELATIONS:
       
        if (BusRelations == ipStack->Parameters.QueryDeviceRelations.Type)
        {
            status = ForwardAndWait(ipHubExt->pLowerDeviceObject, ipIrp);
            pDevRel = (PDEVICE_RELATIONS) ipIrp->IoStatus.Information;
            if (NT_SUCCESS(status) && NULL != pDevRel)
            {
                ...
                //attach only single child device if no child device is attached
                TargetCreateAndAttach(ipHubExt, pDevRel->Objects[pDevRel->Count-1]);
            }
            IoReleaseRemoveLock(&ipHubExt->ioRemoveLock, (PVOID) ipIrp);
            IoCompleteRequest(ipIrp, IO_NO_INCREMENT);
        }
        else
    ...
    ...
    }

    NTSTATUS TargetCreateAndAttach(PDEVICE_EXTENSION pDevExt, PDEVICE_OBJECT pTgtDevObj)
    {
        NTSTATUS status = STATUS_SUCCESS;

        ntStat = IoCreateDevice(pDevExt->pDriverObject, 0, NULL,
            pTgtDevObj->DeviceType, 0,
            FALSE, &pDevExt->pTgtDevObj);

        if (!NT_SUCCESS(status)){
            DkDbgVal("Error create target device!", ntStat);
            return ntStat;
        }

        IoInitializeRemoveLock(&pDevExt->ioRemLockTgt, 0, 0, 0);

        pDevExt->pNextTgtDevObj = NULL;
        pDevExt->pNextTgtDevObj = IoAttachDeviceToDeviceStack(pDevExt->pTgtDevObj, pTgtDevObj);
         if (pDevExt->pNextTgtDevObj == NULL){
            DkDbgStr("Error attach target device!");
            status = STATUS_NO_SUCH_DEVICE;
        }
    ...
    ...
    }
    ===============================

    Crash Dump
    ===============================
    kd> !analyze -v
    *******************************************************************************
    *                                                                             *
    *                        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: 8000007c, memory referenced.
    Arg2: 00000000, value 0 = read operation, 1 = write operation.
    Arg3: 829c8260, If non-zero, the instruction address which referenced the bad memory
        address.
    Arg4: 00000000, (reserved)

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


    READ_ADDRESS:  8000007c

    FAULTING_IP:
    nt!IopQueryDeviceResources+28f
    829c8260 8b00            mov     eax,dword ptr [eax]

    MM_INTERNAL_CODE:  0

    DEFAULT_BUCKET_ID:  INTEL_CPU_MICROCODE_ZERO

    BUGCHECK_STR:  0x50

    PROCESS_NAME:  System

    CURRENT_IRQL:  0

    TRAP_FRAME:  8a02f8a4 -- (.trap 0xffffffff8a02f8a4)
    ErrCode = 00000000
    eax=8000007c ebx=91f283fc ecx=8542ace8 edx=746c6644 esi=00000000 edi=00000000
    eip=829c8260 esp=8a02f918 ebp=8a02f974 iopl=0         nv up ei ng nz na po nc
    cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00210282
    nt!IopQueryDeviceResources+0x28f:
    0008:829c8260 8b00            mov     eax,dword ptr [eax] ds:0023:8000007c=????????
    Resetting default scope

    LOCK_ADDRESS:  8296f2c0 -- (!locks 8296f2c0)

    Resource @ nt!PiEngineLock (0x8296f2c0)    Exclusively owned
        Contention Count = 1
         Threads: 83fa6a70-01<*>
    1 total locks, 1 locks currently held

    PNP_TRIAGE:
        Lock address  : 0x8296f2c0
        Thread Count  : 1
        Thread address: 0x83fa6a70
        Thread wait   : 0x613

    LAST_CONTROL_TRANSFER:  from 8284b968 to 82871c46

    STACK_TEXT: 
    8a02f88c 8284b968 00000000 8000007c 00000000 nt!MmAccessFault+0xbf
    8a02f88c 829c8260 00000000 8000007c 00000000 nt!KiTrap0E+0xdc
    8a02f974 829ca379 00000001 91f283fc 8a02f99c nt!IopQueryDeviceResources+0x28f
    8a02f9ac 829c9ea1 8a02fa00 91f32dd0 91f28410 nt!PnpGetResourceRequirementsForAssignTable+0x184
    8a02fa08 829c9e3f 00000003 91f28398 00000000 nt!PnpAllocateResources+0x4c
    8a02fa64 829c54b1 00000003 91f28398 8a02fae0 nt!PnpAssignResourcesToDevices+0xaf
    8a02fa94 829c2894 00000000 91f28398 8a02fae0 nt!PnpProcessAssignResources+0xc9
    8a02fc94 82993e0d 83fb44e8 85216ca0 8a02fcc8 nt!PipProcessDevNodeTree+0x9d
    8a02fcd4 8282d2d7 85216ca0 8296d1e0 83fa6a70 nt!PiProcessStartSystemDevices+0x6d
    8a02fd00 8286e043 00000000 00000000 83fa6a70 nt!PnpDeviceActionWorker+0x241
    8a02fd50 829fad16 00000001 22f204d0 00000000 nt!ExpWorkerThread+0x10d
    8a02fd90 8289c159 8286df36 00000001 00000000 nt!PspSystemThreadStartup+0x9e
    00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x19


    STACK_COMMAND:  kb

    FOLLOWUP_IP:
    nt!IopQueryDeviceResources+28f
    829c8260 8b00            mov     eax,dword ptr [eax]

    SYMBOL_STACK_INDEX:  2

    SYMBOL_NAME:  nt!IopQueryDeviceResources+28f

    FOLLOWUP_NAME:  MachineOwner

    MODULE_NAME: nt

    IMAGE_NAME:  ntkrnlmp.exe

    DEBUG_FLR_IMAGE_TIMESTAMP:  4a5bbffc

    FAILURE_BUCKET_ID:  0x50_nt!IopQueryDeviceResources+28f

    BUCKET_ID:  0x50_nt!IopQueryDeviceResources+28f

    Followup: MachineOwner
    ---------
    Saturday, August 3, 2013 6:00 AM

All replies

  • Did you verify the data structure you are using are all allocated as non paged memory? In case you are violating the WDK functions requirements to get non paged objects, it might cause such BSOD.

    Monday, August 5, 2013 6:34 AM
  • I am not allocating any memory. Links between Tgt and Hub devices are maintained within DEVICE_EXTENSION structures.

    Also if I don't IoCreateDevice(RelationTgtDeviceObject) in TargetCreateAndAttach() function above, when corresponding HubDevObj->DeviceType == FILE_DEVICE_CONTROLLER || HubDevObj->DeviceType == 0x8900. Then it doesn't crash and My drivers AddDevice() function is called with RelationTgtDeviceObject as PhysicalDeviceObject. Is this correct way or just a work around?

    0x8900 is TopDeviceObject->DeviceType, where TopDeviceObject is obtained from IoGetAttachedDeviceReference(PhysicalDeviceObject) when PhysicalDeviceObject->DeviceType is FILE_DEVICE_BUS_EXTENDER.

    In summary, after my driver is loaded

    1) I get  FILE_DEVICE_CONTROLLER device, say A. After some IRPs..

    2) I get device A's PNP->QueryDeviceRelation->BusRelation with FILE_DEVICE_BUS_EXTENDER as (target) device Type, say device B. If I Call IoCreateDevice for B right here I get the crash. But if I ignore it...

    3) AddDevice is called with Device B (FILE_DEVICE_BUS_EXTENDER) as PhysicalDeviceObject. From IoGetAttachedDeviceReference(B) I get topDeviceObject with DeviceType = 0x8900 which I use in IoCreateDevice

    4) Now I get B's PNP->QueryDeviceRelation->BusRelation with FILE_DEVICE_UNKNOWN as (target) device Type, say C. If I Call IoCreateDevice for C right here I get the same crash. But if I ignore it...

    5) AddDevice is called with Device C FILE_DEVICE_UNKNOWN as PhysicalDeviceObject. From IoGetAttachedDeviceReference(B) I get topDeviceObject with DeviceType = FILE_DEVICE_UNKNOWN

    6) Calling IoCreatedDevice for Device C PNP->QueryDeviceRelation->BusRelation causes no such crash.

    I have searched online to know what is causing the crash. Is above 'Fix' is the correct way or just a workaround.

    Monday, August 5, 2013 8:45 AM
  • Looks to me like a workaround. I would try as far as I could follow the samples provided in WDK.
    Monday, August 5, 2013 9:09 AM