You are right. And Bill McKenzie is also right. There is a bug in the W2K pcmcia.sys.
By doing more analysis I found out that the SURPRISE_REMOVAL Irp has been completed with STATUS_UNSUPPORTED, which of course fails the removal which is never a good idea. The problem is: I did not complete the irp in my function driver. Conforming to WDM PnP irp handling rules I pass it down to the bus driver pcmcia.sys which completes it with the default status STATUS_UNSUPPORTED. This seems to be a bug in the W2K pcmcia.sys implementation.
Tests on XP did show that pcmcia.sys behaves well on that system. SURPRISE_REMOVAL gets completed with STATUS_SUCCESS. I do not have any problems with the scenario described in my original posting.
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.
Thanks for all the help.
–
Udo Eberhardt
Thesycon GmbH, Germany
xxxxx@thesycon.de
www.thesycon.de
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Graham, Simon
Sent: Tuesday, June 18, 2002 7:55 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Duplicate PDO problem (CardBus)
There is a ‘feature’ in Win2K such that IF a SURPRISE_REMOVAL Irp
is failed,
some information in the registry (specifically the
DeviceReference value as
I recall) does not get tidied up. If you then get the REMOVE, this data is
tidied up but if, as you stated, there is an app holding a handle open on
the device, the REMOVE does not happen and therefore the registry data is
left lying around.
When the device us plugged back in, PnP checks this registry
value and if it
is present it generates the DUPLICATE_PDO BSOD.
Now; many drivers don’t really do anything with surprise-removal
and tend to
just complete it with the incoming status - this is initialised to
STATUS_UNSUPPORTED by PnP hence you often end up with this Irp
being failed.
Bottom line - make sure surprise-remove always completes successfully and
this problem will (should!) go away.
/simgr
-----Original Message-----
From: Udo Eberhardt [mailto:xxxxx@thesycon.de]
Sent: Friday, June 14, 2002 4:43 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Duplicate PDO problem (CardBus)
Windows 2000
–
Udo Eberhardt
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Bill McKenzie
> Sent: Wednesday, June 12, 2002 11:53 PM
> To: NT Developers Interest List
> Subject: [ntdev] Re: Duplicate PDO problem (CardBus)
>
>
> What OS are you trying this on?
>
> –
> Bill McKenzie
>
>
>
> “Udo Eberhardt” wrote in message
> > news:xxxxx@ntdev…
> >
> > Hi all,
> >
> > 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.
> >
> > All the PnP IRPs are handled correctly by the function driver
> > (according to
> > DDK rules).
> >
> > Any ideas?
> >
> > –
> > Udo Eberhardt
> > Thesycon GmbH, Germany
> > xxxxx@thesycon.de
> > www.thesycon.de
> >
> >
> >
> > 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.
> >
> >
> >
> >
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@thesycon.de
> > To unsubscribe send a blank email to %%email.unsub%%
> >
> >
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@stratus.com
> To unsubscribe send a blank email to %%email.unsub%%
>
> —
> You are currently subscribed to ntdev as: xxxxx@thesycon.de
> To unsubscribe send a blank email to %%email.unsub%%
>
>