Hello

I am trying to debug a 1394 driver (source available here
http://www-2.cs.cmu.edu/~iwan/1394/d...ds/index.html).
This driver is intended for cameras which are DCAM compliant. When
performing an hibernation with a camera connected, a blue screen occurs
at resume.
I looked at the sample driver in the DDK (1394vdev) and it seems that
the power.c has been simply copied from the sample driver.

I have been playing with windbg to debug the driver at resume and it
gives the following trace:

nt!RtlpBreakWithStatusInstruction
nt!KiBugCheckDebugBreak+0x19
nt!KeBugCheck2+0x574
nt!KeBugCheckEx+0x1b
nt!MmAccessFault+0x9a8
nt!KiTrap0E+0xd0
nt!IoBuildDeviceIoControlRequest+0xf
1394cmdr!t1394_GetGenerationCount(struct _DEVICE_OBJECT * DeviceObject =
0x00d5aeb8, struct _IRP * Irp = 0x00000000, unsigned long *
GenerationCount = 0x85d5810c)+0x65
1394cmdr!t1394Cmdr_DeviceSetPowerIrpCompletion(str uct _DEVICE_OBJECT *
DeviceObject = 0x85d5aeb8, unsigned char MinorFunction = 0x02 '', union
_POWER_STATE state = union _POWER_STATE, struct
_POWER_COMPLETION_CONTEXT * PowerContext = 0x00000000, struct
_IO_STATUS_BLOCK * IoStatus = 0x86430278)+0xb9
nt!PopCompleteRequestIrp+0x55
nt!IopfCompleteRequest+0xa2
1394BUS!Bus1394Power+0xd4
nt!IopfCallDriver+0x31
nt!PopPresentIrp+0x57
nt!PoCallDriver+0x195
1394cmdr!t1394Cmdr_Power(struct _DEVICE_OBJECT * DeviceObject =
0x00000001, struct _IRP * Irp = 0x86430260)+0x202
nt!IopfCallDriver+0x31
nt!PopPresentIrp+0x57
nt!PoCallDriver+0x195
nt!PoRequestPowerIrp+0x129


It seems to me that DEVICE_OBJECT pointer passed to t1394Cmdr_Power is
quite likely to be incorrect (0x0000001), and quite different of the
adress that was passed before hibernation.
Any idea about what to look to understand what happens ?

Thanks in advance
best regards

Nicolas Aspert wrote:
After investigating a little more, it seems that the power management in
the 1394 samples from the ddk is not really cleanly done.
As I am not really into driver programming, any help about decent
samples would be appreciated.

I have looked here
http://www.intel.com/technology/usb/...ent_in_wdm.pdf

and the sample driver here
http://www.codeproject.com/KB/system...velopment.aspx

and they all have more elaborated processing of IRP_MN_SET_POWER

the pdf from Intel says:
"When any device receives a set system power irp, it should set its
device power to the
appropriate state (as specified in the device capabilities structure
saved in the device extension).
If this is not implemented (i.e., the driver simply passes the power irp
down the stack),
during system suspend, the device will receive the PnP
IRP_MN_REMOVE_DEVICE irp
followed by an IRP_MJ_UNLOAD. This means that the driver is actually
unloaded from the
system. On resume, the driver will be reloaded with the DRIVER_ENTRY
routine being
executed followed by the normal PnP irps that are dispatched during
enumeration (i.e.
IRP_MN_START_DEVICE, IRP_MN_QUERY_CAPABILITIES, etc.). If an application
has a
handle to the driver, that handle will be valid when the system resumes."

Is it really the case ? Apparently this is what the sample 1394 driver
from the ddk does, but is it the correct approach ?

regards
Nicolas

Write your driver in KMDF. You don't have worry all these pnp/power
management issues. The 1394 sample is already rewritten in KMDF
(src\kmdf\1394).

-Eliyas

"Nicolas Aspert" <elhefe@noemail.noemail> wrote in message
news:#Fv3tPfqIHA.1240@TK2MSFTNGP02.phx.gbl...

Eliyas Yakub [MSFT] wrote:
You mean power management is _that_ broken in wdm ?
If you diff the driver against the wdm sample, you can see there the
amount of undocumented stuff is not negligible, so I was still hoping to
fix the existing code...