Camera Class - Kernel Stream/Frameserver - Find caller

NTDEV
1

I have a driver attached as a filter in the Camera and Image class stack. Overall the code is working/INF is correct. Whenever a new UM application tries to enumerate and access my USB camera I see the IRP and Kernel Streamming IOCTL IOCTL_KS_PROPERTY, then PKSSTATE flag of KSSTATE_ACQUIRE.

Originally pre WIN10 1607, all UM applications (UWP and win32) we’re synchronous in there call to accessing the camera (as seen in the image below), i.e. the calling process context can be seen and then checked if it should be allowed to access this other camera. However in Windows 10 1607+ introduced the Frameserver which proxies the camera feed to all UM applications that have registered for the feed through svchost.exe. Now I can’t check who is trying to access this camera, as seen in the image below from MSDN:

I know in UWP you can allow/deny camera usage, but how do I restrict standard win32 applications from enumerating my camera and accessing the feed. So my question is how I get the context of the calling process (whether it is UWP or win32), when the KSSTATE_ACQUIRE flags arrives at my filter. I have looked at Frameserver dll public globals via windbg, looked at Ks.h, I can’t find any anything relevant to determine the original process caller that’s proxied through svchost.exe.

N.B. I know I could edit the regkey to disable the frameserver/dshow bridge, this is a last resort, as I will negatively affect customers machine if he uses multiple camera applications (like zoom, skype, teams etc) and prevent concurrent use.
N.B.B The UM application (built by 3rd party) could be win32 or UWP, I may or may not have control whether the UM program can send the filter some special command to verify it’s them.
N.B.B.B. All the posts I read online regarding Camera class on OSR are answered by @Tim_Roberts (:

2

RIght. Much the same limitation exists in the audio stack. All audio apps talk to the Audio Engine process, and the Audio Engine owns the pipeline into the driver. There is no solution. Controlling access to the device is now the job of the operating system. Just look at the diagram above. Unless you opt out, you simply do not have access at the points where applications connect. If an app is already using the camera, and another app connects, the driver will not be notified. There’s no renegotiation; the stream just keeps flowing.

The Frameserver is a technology in search of a problem.