For a function driver, you get the PDO as the 2nd parameter of AddDevice.
Is it equal to 82287360 (from the bugcheck)?
--pa
"PhilG" <> wrote in message
news:9F053EA5-1CF0-4BE1-91B3-...
>
> Hello there, I hope someone will be able to help me with this problem that
> has
> me vexed. I'm developing a kernel function driver and it works except when
> I
> make a call to IoReportTargetDeviceChangeAsynchronous, it bugchecks with
> PNP_DETECTED_FATAL_ERROR (ca), Invalid PDO (first arg = 2). I'm pretty
> sure
> the
> PDO is reasonably correct. What I'm not sure of is what it means for it to
> be
> initialized through QueryDeviceRelations. I added a handler for
> IRP_MN_QUERY_DEVICE_RELATIONS in the Plug and Play dispatch routine with
> the
> HandleQueryRelations function in Oney 2 Ed., p. 549. But this minor IRP
> request
> doesn't get invoked. Fundamental question: how do I initialize a PDO to
> make
> it
> valid for IoReportTargetDeviceChangeAsynchronous? The !analyze output
> follows.
>
> Thanks,
>
> Phil
>
>
>
> Here's the !analyze output:
>
> kd> !analyze -v
> ************************************************** *****************************
> *
> *
> * Bugcheck Analysis
> *
> *
> *
> ************************************************** *****************************
>
> PNP_DETECTED_FATAL_ERROR (ca)
> PnP encountered a severe error, either as a result of a problem in a
> driver or
> a problem in PnP itself. The first argument describes the nature of the
> problem, the second argument is the address of the PDO. The other
> arguments
> vary depending on argument 1.
> Arguments:
> Arg1: 00000002, Invalid PDO
> An API which requires a PDO has been called with either an FDO,
> a PDO which hasn't been initialized yet (returned to PnP in a
> QueryDeviceRelation/BusRelations), or some random piece of
> memory.
> Arg2: 82287360, Purported PDO.
> Arg3: 00000000, Driver object.
> Arg4: 00000000
>
> Debugging Details:
> ------------------
>
>
> BUGCHECK_STR: 0xCA_2
>
> DEVICE_OBJECT: 82287360
>
> DRIVER_OBJECT: 822759c0
>
> IMAGE_NAME: pcidp.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 4c223060
>
> MODULE_NAME: pcidp
>
> FAULTING_MODULE: f89c3000 pcidp
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> PROCESS_NAME: Idle
>
> LAST_CONTROL_TRANSFER: from 80532747 to 804e3592
>
> STACK_TEXT:
> 805509ec 80532747 00000003 80550d48 00000000
> nt!RtlpBreakWithStatusInstruction
> 80550a38 8053321e 00000003 80559c20 805599c0 nt!KiBugCheckDebugBreak+0x19
> 80550e18 8053380e 000000ca 00000002 82287360 nt!KeBugCheck2+0x574
> 80550e38 8051c7dc 000000ca 00000002 82287360 nt!KeBugCheckEx+0x1b
> 80550e54 f89c4c25 82287360 80550e88 00000000
> nt!IoReportTargetDeviceChangeAsynchronous+0x12c
> 80550f08 f89c522d 82287360 82287418 ffdffc50
> pcidp!NotifyRegisteredApp+0x185
> [e:\development\coilpro\pcidp_sys\pcidp.c @ 745]
> 80550f2c 804dbbd4 822873d4 82287360 00000000 pcidp!PCIDPForDpcIsr+0x8d
> [e:\development\coilpro\pcidp_sys\pcidp.c @ 908]
> 80550f50 804dbb4d 00000000 0000000e 00000000 nt!KiRetireDpcList+0x46
> 80550f54 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x26
>
>
> STACK_COMMAND: kb
>
> FOLLOWUP_IP:
> pcidp!NotifyRegisteredApp+185 [e:\development\coilpro\pcidp_sys\pcidp.c @
> 745]
> f89c4c25 89856cffffff mov dword ptr [ebp-94h],eax
>
> SYMBOL_STACK_INDEX: 5
>
> SYMBOL_NAME: pcidp!NotifyRegisteredApp+185
>
> FOLLOWUP_NAME: MachineOwner
>
> FAILURE_BUCKET_ID: 0xCA_2_pcidp!NotifyRegisteredApp+185
>
> BUCKET_ID: 0xCA_2_pcidp!NotifyRegisteredApp+185
>
> Followup: MachineOwner
> ---------
>
|
Linear Mode
