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

Sept/Oct 2019 Issue of The NT Insider available


Download PDF here: http://insider.osr.com/2019/ntinsider_2019_01.pdf

It’s a particularly BIG issue, too: 40 pages of technical goodness, ranging from WDF to Minifilters. Check it out.
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

Camera Class - Kernel Stream/Frameserver - Find caller

AvalonAvalon Member Posts: 16
edited October 8 in NTDEV

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 (:

Comments

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,102

    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.

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

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
Writing WDF Drivers 21 Oct 2019 OSR Seminar Space & ONLINE
Internals & Software Drivers 18 Nov 2019 Dulles, VA
Kernel Debugging 30 Mar 2020 OSR Seminar Space
Developing Minifilters 27 Apr 2020 OSR Seminar Space & ONLINE