karthiksharmasg@xxxxxxx wrote: > Thanks Tim, > > I have sent only a snap of the code, the complete code of adapter.cpp > is attatched to this mail, can you please look in to that Please keep this exchange on the mailing list. I am not a free private consulting service. I believe I may have given you incorrect advice. I did not realize that you were just trying to create a "control device object" as a back door into a standard PortCls PnP device. That changes things. Your device object is not part of a PnP stack, so it will never get an IRP_MN_REMOVE_DEVICE request. Instead, I believe you will need to watch for IRP_MN_REMOVE_DEVICE requests for the PortCls device object, and delete your device in response to THAT. Note that you will still need to pass that request on to PcDispatchIrp. There's still a potential issue here, however. IF an application still has an open file handle to your control device when you go to delete it, the system can't really delete the device. The device can't be deleted until the application actually closes its handle. But if the last remaining device object in your driver is not a PnP device, then the operating system doesn't automatically trigger an unload when it is closed. That only happens with PnP devices. There is no solution to this -- it's just an ugly side effect of mixing PnP and non-PnP devices within a single driver. It's not really a problem, except that you can't update your driver binary in that case without rebooting. -- Tim Roberts, timr@xxxxxxxxx Providenza & Boekelheide, Inc. ****************** WDMAUDIODEV addresses: Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx Subscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe Unsubscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe Moderator: mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx URL to WDMAUDIODEV page: http://www.wdmaudiodev.com/