Duplicate PDO problem (CardBus)
Udo Eberhardt
I encountered the following problem with a cardbus device. The device is
hot-plugged in. The function driver gets loaded. An application is started
and it opens a handle for the device. Everything is fine so far.
Now the card is hot-removed. The application is still running and owns the
handle for the device! The function driver gets IRP_MN_SURPRISE_REMOVAL.
But, no IRP_MN_REMOVE_DEVICE is sent by the PnP manager due to the open
handle. REMOVE is deferred. Still no problem so far.
Now the card is hot-plugged in again. The app is still open!
Before the function driver sees any call or any PnP IRP the system crashes
with a blue screen complaining about a duplicate PDO. See the WinDbg
bugcheck information below. The crash is caused by the PDO that is created
by pcmcia.sys. Pcmcia seems not to handle the situation caused by the
deferred REMOVE correctly.
I'm quite sure all the PnP IRPs are handled correctly in my function driver
(according to DDK rules).
Any ideas?
--
Udo Eberhardt
Thesycon GmbH, Germany
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: 00000001, Duplicate PDO
A specific instance of a driver has enumerated multiple PDOs with
identical device id and unique ids.
Arg2: 8149ed70, Newly reported PDO.
Arg3: 81464630, PDO of which it is a duplicate.
Arg4: 00000000, Varies depending on argument 1
kd> !devobj 8149ed70
Device object (8149ed70) is for:
NTPNP_PCI0011 \Driver\PCI DriverObject 816910b0
Current Irp 00000000 RefCount 0 Type 00000022 Flags 00001040
DevExt 8149ee28 DevObjExt 8149ef08 DevNode 814a7288
ExtensionFlags (0x00000010) DOE_START_PENDING
AttachedDevice (Upper) 81490130 \Driver\Pcmcia
Device queue is not busy.
kd> !devobj 81464630
Device object (81464630) is for:
NTPNP_PCI0010 \Driver\PCI DriverObject 816910b0
Current Irp 00000000 RefCount 0 Type 00000022 Flags 00001040
DevExt 814646e8 DevObjExt 814647c8 DevNode 8146b128
ExtensionFlags (0x00000008) DOE_REMOVE_PROCESSED
AttachedDevice (Upper) 8146a030 \Driver\Pcmcia
Device queue is not busy.
David J. Craig
one, you have to cleanup and invalidate the handle. You can't talk to
something that is not there.
"Udo Eberhardt" <Udo...@gmx.de> wrote in message
news:ae6v0d$6h8$04$1...@news.t-online.com...
Udo Eberhardt
SURPRISE_REMOVAL handler:
"... but leaves its device object attached to the device stack until the PnP
Manager sends a subsequent IRP_MN_REMOVE_DEVICE request."
The problem is that the PnP manager does not send the IRP_MN_REMOVE_DEVICE
irp because there are still open handles to my device object. The app should
close these handles but it is not aware on the device removal.
However, removal is not really the problem. The problem occurs when the user
re-plugs the device without closing the app first.
Let me summarize the sequence of events that causes my problem:
- device is hot plugged in and is enumerated by pcmcia.sys
- my function driver is loaded, it creates a FDO and attaches it to the PDO
- an app is started and opens a handle for the FDO, app talks to the device
- device is hot removed
- my function driver gets IRP_MN_SURPRISE_REMOVAL irp and does what the DDK
says (releasing resources, stop talking to the device, but leaving the FDO
in place and attached to the stack)
- my function driver never gets a IRP_MN_REMOVE_DEVICE irp; it is deferred
by pnp manager due to the open handle (this behavior is documented in the
DDK)
- app is still active; it is not aware of pnp events
- device is hot plugged in again and is enumerated by pcmcia.sys
- before my function driver gets called the system crashes with the blue
screen described in my original posting: PNP_DETECTED_FATAL_ERROR (0xCA)
The problem seems to be that pcmcia.sys does not handle correctly the
deferred REMOVE state of the first PDO. When the re-insertion occurs
pcmcia.sys creates a new PDO that causes a conflict with the still existing
first PDO because it uses a identical device id and unique id.
Can anyone confirm this?
Any comments are welcome.
Thanks.
Udo Eberhardt
"David J. Craig" <Da...@yoshimuni.com> wrote in message
news:PLIN8.142163$ec1.2...@twister.tampabay.rr.com...
Eliyas Yakub
--
-Eliyas
This posting is provided "AS IS" with no warranties, and confers no rights.
http://www.microsoft.com/hwdev/driver/KB-drv.asp
"Udo Eberhardt" <Udo...@gmx.de> wrote in message
news:ae7s1q$vfc$05$1...@news.t-online.com...
Udo Eberhardt
Udo Eberhardt
"Eliyas Yakub" <eli...@microsoft.com> wrote in message
news:3d077f9d$1...@news.microsoft.com...
Jean
Udo Eberhardt
Eliyas.
I do not complete the SURPRISE_REMOVE irp in my function driver. I pass it
down to the bus driver pcmcia.sys. This is conform with the DDK rules for
handling of pnp irps. The bus driver completes the irp with the default
status, which is STATUS_UNSUPPORTED. This seems to be a problem in the W2K
pcmcia.sys implementation.
I observe this problem on W2K only. On XP pcmcia.sys completes the
SURPRISE_REMOVE irp with STATUS_SUCCESS and everything works as expected.
Actually, I implemented a work-around in my function driver. Now I handle
the SURPRISE_REMOVAL irp synchronously (pass down and wait for completion).
If the bus driver fails the irp (which is always the case on W2K) I complete
it with STATUS_SUCCESS. This seems to work on both systems W2K and WXP.
--
Udo Eberhardt
Thesycon GmbH, Germany
Udo.Eb...@re-move.thesycon.de
www.thesycon.de
"Eliyas Yakub" <eli...@microsoft.com> wrote in message
news:3d077f9d$1...@news.microsoft.com...
Walter Oney
> I do not complete the SURPRISE_REMOVE irp in my function driver. I pass it
> down to the bus driver pcmcia.sys. This is conform with the DDK rules for
> handling of pnp irps. The bus driver completes the irp with the default
> status, which is STATUS_UNSUPPORTED. This seems to be a problem in the W2K
> pcmcia.sys implementation.
Does this happen even when you change the IRP's status to STATUS_SUCCESS
before passing it down? As I understand the way things are supposed to
work, the W2K driver is actually doing the right thing to not change the
status, as this tells the PnP Manager that no driver in the stack
actually processed the IRP. The Driver Verifier should have been
complaining about this as well.
--
Walter Oney
Consulting and Training
http://www.oneysoft.com
Eliyas Yakub
IRP_MN_SURPRISE_REMOVAL, ie the IRP wasn't marked with STATUS_SUCCESS. If a
resource consuming stack didn't succeed surprise removal, Win2K's PnP
manager would leave the devnode in the tree, possibly causing this scenario.
-Eliyas
"Udo Eberhardt" <Udo...@gmx.de> wrote in message
news:ae9l89$k8q$05$1...@news.t-online.com...
Walter Oney
> This might happen on Win2K (but not XP) if you did not succeed
> IRP_MN_SURPRISE_REMOVAL, ie the IRP wasn't marked with STATUS_SUCCESS. If a
> resource consuming stack didn't succeed surprise removal, Win2K's PnP
> manager would leave the devnode in the tree, possibly causing this scenario.
When I looked at the doc recently, I realized it was not at all clear
that you're supposed to change the IRP status to STATUS_SUCCESS *before*
passing the IRP down.
Eliyas Yakub
driver must not fail this IRP. This IRP is handled first by the driver at
the top of the device stack and then passed down to each lower driver in the
stack.
Basically that means:
Irp->IoStatus.Status = STATUS_SUCCESS;
IoSkipCurrentIrpStackLocation(...);
return IoCallDriver(...);
A bus driver typically doesn't change the status. On Win2k, PCI leaves the
status of the IRP unchanged, and on XP, it completes it STATUS_SUCCESS.
--
-Eliyas
This posting is provided "AS IS" with no warranties, and confers no rights.
http://www.microsoft.com/hwdev/driver/KB-drv.asp
"Walter Oney" <walt...@oneysoft.com> wrote in message
news:3D159E6F...@oneysoft.com...