How should I handle symbolic links and IRP_MN_SURPRISE_REMOVAL

For my final entry in surprise removal week (did anyone sense a theme :) ?), let's talk about symbolic links and surprise remove.  The DDK docs state that you should not use a symbolic link with a PnP device, but I understand that practically speaking, drivers need to use a sym link because of legacy app requirements which expect the old sym link name and not the new device interface format.

Symbolic links present similar issues to device interfaces, but with a different twist.  Both the device interface and the symbolic link share the attribute that they will have the same name for a given device instance path, but unlike device interfaces which can have 2 "instances" for the same PDO (one surprise removed, the other a resinssertion of the device), a symbolic link name can not be duplicated across multiple instances of the same device. 

What does that mean?  Plain and simple, you need to delete the symbolic link name in surprise remove handling so that you can recreate the symbolic link name on device reinsertion when it reappears.  The raw device object name that the link points to will not be the same, but the user mode application which uses the symbolic link won't know the difference.

For instance, on initial plugin, \DosDevices\MyFoo links to \Device\MyFoo0.  \Device\MyFoo0 is surprise removed and stays in the s.r. state because an app still has a handle open to it, and deletes the sym link..  The Foo device is plugged back, and driver creates \Device\MyFoo1 (because \Device\MyFoo0 still exists) and recreates the sym link \DosDevices\MyFoo to point to \Device\MyFoo1.

Comments

• Anonymous
  May 03, 2007
  As I wrote about previously, naming your FDO has some side effects that you may not want to incur. But

• Anonymous
  September 20, 2010
  Is there any API for removal of the sym link form the driver? I mean a function which is an opposite for WdfCreateSymbolicLink? Thanks!