Distinguish between Applications connecting to device

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?

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?

1 Like

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

Peter

1 Like

@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.

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.

1 Like

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

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

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.

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

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