Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTDEV
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


Distinguish between Applications connecting to device

remyavu10remyavu10 Member Posts: 36

I have a UMDF2 serial driver and want to get notified when Serial Port application open device. I am using Queue callback to get notified on opening device.
This approach is working fine. I want a serial port application and it get notified with above callback. This is fine and satisfy my need.

But i have property page for the device as well. And inside property page i am using CreateFile and DeviceIOControl to communicate with Device.
So the above callback get notified for Property Sheet related CreateFile API as well.

Is there any way which WDF provide some level of details abt application connecting to device, to distinguish between app opening the device?

Comments

  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,499
    There isn’t. Why should the driver care? Are you trying to create an access control scheme based on the app that creates the handle?
    d
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,845

    Well, there’s WdfRequestGetRequestorProcessId on any Request. That’ll give you the PID, if that’ll help you.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • remyavu10remyavu10 Member Posts: 36

    @Doron_Holan said:
    There isn’t. Why should the driver care? Are you trying to create an access control scheme based on the app that creates the handle?

    Driver need to so some extra tasks when data reader application open the device(i.e. starting underlying communication channel). It need not be done when being opened from Property Page.

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,442

    If it were me, I'd register a device interface with a reference string, and have the property page open that instead. Then, your IRP_MJ_CREATE handler can check the file name to see if it's your special client.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • remyavu10remyavu10 Member Posts: 36

    Thanks! Both methods (get pid and get name AND device interface with a reference string) looks feasible solutions. Thanks Guys!

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,845

    I'd register a device interface with a reference string, and have the property page open that instead

    Easier still: Have the apps and/or property page open different namespaces on the device (or have one open a namespace and the other not) -- On Open, use a name like this: "\.\DeviceName\Namespace" instead of the typical "\.\DeviceName" -- Provide an EvtDeviceFileCreate Event Processing Callback to handle open operations, and then call WdfFileObjectGetFileName in that callback, storing the result in Context associated with the WDFFILEOBJECT.

    Namespaces... one of the most overlooked cool features available in Windows.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,499
    Tim’s suggestion of a second device interface with a reference string is the same, but a little simpler on the calling application as it doesn’t need to append the additional file name on the interface string. I would strongly suggest you use the namespace check and NOT the pid/app name. The pid and app name is too fragile. An app name change or new app that wants to open to configure the driver requires a driver change. If you optimize based on the namespace it doesn’t matter what the app name is, you can even have an app that can open the decide for config and then subsequently for io.
    d
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,845

    a little simpler on the calling application as it doesn’t need to append the additional file name on the interface string

    Either way. I am well know to be a fan of "open by name" as opposed to "open by device interface GUID"... (though not NEARLY as violently as I had been since we've been able to bypass the use of SetupDixxx) so, it all comes down to what you prefer to code and, what you think the user-mode folks would prefer to use.

    I would strongly suggest you ... NOT [use] the pid/app name.

    Exactly. Doron speaks the truth. You can use the PID to differentiate among processes... but relying on the name is asking for a world of hurt. ANYbody can create an application named "explorer.exe", right? Whether or not it's "the" Windows Explorer....

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • MBond2MBond2 Member Posts: 127

    if there are two different workflow, certianly have two different interfaces - do not attempt to 'guess' which workflow to execute based on the PID / image name etc. down that rabit hole lies maddness

    that precept is not specific or unique to Windows or driver development, but happens to be true here too

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Kernel Debugging 30 Mar 2020 OSR Seminar Space
Developing Minifilters 15 Jun 2020 LIVE ONLINE
Writing WDF Drivers 22 June 2020 LIVE ONLINE
Internals & Software Drivers 28 Sept 2020 Dulles, VA