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/


Camera Class - Kernel Stream/Frameserver - Find caller

AvalonAvalon Member Posts: 26
edited October 2019 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,403

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