locked
multiple symbolic links for same wdfdevice object RRS feed

  • Question

  • Is it possible for my driver to call WdfDeviceCreateSymbolicLink twice successfully to create 2 symbolic links to the same device ? 

    I have one device driver, which controls one physical device, which performs two separate functions and i would like the applications to use different symbolic links to refer to the different functions. 

    Calling WdfDeviceCreateSymbolicLink twice fails so what other options do i have to solve this ?

    Thursday, January 22, 2015 2:33 PM

Answers

All replies

  • You have several possibilities here, you can create two FDO's for the device one for each function, this gives you the model you desire, but has some challenges on managing PnP .  A simpler approach is to use a namespace model by using WdfDeviceInitSetFileObjectConfig to have a create device call so you can use an identifier "file name" with the device open to indicate the function.  This keeps the single device model, but uses the file object to allow distinguishing which function is being requested.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com

    Thursday, January 22, 2015 2:41 PM
  • Thanks Don. Appreciate the help. I will give you suggestion a try..

    Will i have the same issue with trying to create 2 device interfaces using WdfDeviceCreateInterface for the same device object ? 

    Thursday, January 22, 2015 2:53 PM
  • I don't believe you will have the problem, but I honestly have never tried it.  I typically use the namespace model, since it is messy to know what device interface or symbolic link is being used to open the device with the multiple links to one device.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com

    Thursday, January 22, 2015 2:58 PM
  • Thanks Don. The apps communicate to my driver through IOCTL's so i thought i could differentiate the requested function through the input buffer/IOCTL name. 
    Thursday, January 22, 2015 3:01 PM
  • you can have WDF manage as many device interface guids as you want. If you want to understand which interface is being opened, you need to specify a unique ReferenceString for each.

    WDF does limit you to one WDF managed symbolic link. If you want more than one, you can create it by calling IoCreateSymbolicLink yourself. you will then have to delete on your own too. If you have control over which path, use multiple device interfaces

    further reading

    http://blogs.msdn.com/b/doronh/archive/2006/08/18/706717.aspx

    http://blogs.msdn.com/b/doronh/archive/2006/02/24/538790.aspx


    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Thursday, January 22, 2015 6:31 PM
  • Thanks Don and Doron. Great resources.
    Friday, January 23, 2015 1:39 PM
  • If your driver uses reference strings and a third party wants to put an upper filter on top of it, will it be difficult? I mean, when e.g. IRP_MJ_WRITE comes down, the filter may need to know which device interface was opened, so that it can interpret the data correctly. Because you would presumably not document your FsContext structures, the filter would have to recognize the reference string during IRP_MJ_CREATE and save the information to an RTL_GENERIC_TABLE or something. Then if you changed the reference strings between driver versions, the filter would no longer be compatible. Even worse if you generated reference strings at run time.

    I guess anyone who wanted to specifically recognize the device interfaces of your driver should first ask you to document the reference strings you support for such use.

    Friday, January 23, 2015 4:44 PM
  • a upper filter driver cannot just be added to any stack. it has to understand the stack it is on and the semantics (including FS namespace) that the stack uses. You can't just add a filter to any stack. He doesn't have to document anything publicly if he doesn't want to.

    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Friday, January 23, 2015 6:29 PM