I need a way to check if a specific webcamera device is currently active (used by another application, for example Skype). Is there any method in WIA, DirectX or other API to accomplish this check?
For example, I have a software which pops up when capture is started and closes automatically upon disconnection.
Related
I do have two computers which are used to control an industrial plant. One of them controls the plant, the other is used as a failsafe. They are directly connected over ethernet, and the inactive" one just mirrors the display of the main controller.
I did capture the network traffic between the two and when i open it up in wireshark i see its all X11 traffic. It does include the initial connection request and also includes all the "draw calls" in plain text.
I now want to "replay" this captured stream and recreate the screen content from it. Is there any program available which can do so? Ideally directly from the wireshark capture file
My thoughts so far:
I can easily replay the network data itself and send it to some socket, but the communication is specific to the session, e.g. some commands refer to specific handle values set up earlier. Its unlikely a new session would work with the same values so i cant just pipe it into some program
What you see from your connection is only your connection requests + events relevant to the windows created by you ( or other's client windows where your connection sets an event mask ), and because of that quite a lot is lost. I'm not aware of the programs that can reconstruct best possible version of the screen from one client traffic but it's certainly not possible to have 100% accurate copy of the screen and best possible model will be far away from real screen (unless your connection periodically polls for backing store content of each mapped window).
I have been using Windows APIs for NFC communication. I am successful in getting and sending NFC messages from Windows PC, using a local console app. However, I want the communication to be done using a Windows service. Here is what I have:
A C# plugin (DLL), which makes the API calls.
C++/CLI Wrapper that allows unmanaged C++ code, to use the above plugin.
A C++ plugin, that the service will load (this is a requirement, it has to be a plugin)
If I load the C++ plugin into a local console app, and run, it can catch all NFC events (NFC device arrives in proximity, departs from proximity, can read and write to it). But, when I use the same plugin with a service, it is not able to catch those events. I can clearly hear the ping sound that comes when an NFC device comes close to Windows PC, however, none of the event handlers are called (For device arrival, device departure, read or write).
I also tried impersonation thinking that perhaps the context of who calls the method might result in blocking of the events. I could impersonate local user on the service, but the results were the same, no events could be identified.
Is there a reason why I cannot see any NFC events from a service, where as a local console app can get all of them? Again, I am able to hear the ping sound signifying that NFC device is close to Windows PC, but there is no handler getting called for it, suggesting there is blockage of something. Any ideas of what is going on?
Appreciate your time guys!
First off, I know some proper ways of making a truly interactive Windows Service.
The situation is, I do have a tool that does not interact with the user as such. However, it does display non-blocking notifications both via popup windows and via the Windows Notification Area (aka System Tray). It also writes a logfile of the notifications it displays.
This tool is normally spawned by a main user application and as long as the main application is a normal application, these notifications do work as intended.
When this tool is spawned by a Windows Service, no notifications are displayed, naturally. (The Desktop Session for the service isn't visible.) But this would be OK, we have the logfile and these notifications are just - notifications, nothing the user absolutely must see under all circumstances.
The question now becomes: Is a process running in the context of a Service (the Service itself or any process it starts) "allowed" to make Windows API calls that display a visible GUI?
Will most Windows API calls (e.g. creating and showing a window, using Shell_NotifyIcon, etc.) behave the same in the invisible session of the service?
Or would I have to make sure throughout the source code, that no GUI displaying/modifying stuff is called in the context of the service?
And yes, calling ::MessageBox is a bad idea because it will block. But I can handle these calls.
And yes, this could be designed better, but it's what I have at the moment and it would be nice if I hadn't to rip the whole tool apart to make sure no GUI related code is run in the service.
GUI elements from a Windows Service are shown on Session 0. On Windows XP & 2003, users were allowed to log in to Session 0 and interact normally with the windows created by a service, but Microsoft put a knife in the heart of interactive services in Vista (and beyond) by isolating Session 0.
So, to answer your specific questions:
Is a process running in the context of a Service (the Service itself
or any process it starts) "allowed" to make Windows API calls that
display a visible GUI?
Will most Windows API calls (e.g. creating and showing a window, using Shell_NotifyIcon, etc.) behave the same in the invisible session
of the service?
Yes, GUI calls are allowed and should succeed as normal. The only notable exceptions that I know of are those related to tray icons because the process providing the task bar (explorer.exe) is not running in the isolated Session 0.
Or would I have to make sure throughout the source code, that no GUI displaying/modifying stuff is called in the context of the service?
That should not be necessary, though you should proceed cautiously with any GUI interaction from your service. Test thoroughly!
I would like to provide some info wrt. Raymonds Chen's comment to the other answer
You should avoid presenting UI in a service because you may trigger
the UI Detection Service which will switch the user to your service UI
temporarily. – Raymond Chen
I find these good articles:
What is Interactive Services Detection and Why is it Blinking at Me?
Inside Session 0 Isolation and the UI Detection Service, Part1, Part2
Where one can find explanation on what the UI detection service (UI0Detect) is and does and how it's supposed to work.
Interactive Services Detection (the blinking button on the taskbar) is
a mitigation for legacy applications that detects if a service is
trying to interact with the desktop. This is handled by the
Interactive Services Detection (UI0Detect) service.
However, one must note that this only can work if the service that is trying to view a GUI has the flag "Allow service to interact with desktop" set, because only then the service process will be running on WinSta0of Session0 even allowing it to show anything at all.
Alex Ionescu mentions this:
If UI0Detect.exe ...
the SCM has started it at the request of the Window Hook DLL. The
service will proceed ...
The service first does some
validation to make sure it’s running on the correct WinSta0\Default
windowstation and desktop and then notifies the SCM of success or
failure.
So, to come back to Raymond's comment: As far as I can see, as long as a service doesn't tick the type= interact option (see sc.exe), and normally you don't tick this, the UI0Detect service doesn't do anything and there shouldn't be any "danger" of triggering it.
Note: The information above is based on my limited research and tests on only a single Windows 7 PC.
Colleagues, I have need to run a script/program on certain basic OS level events. In particular when a file in Windows is opened. The open may be read-only or to edit, and may be initiated by a number of means, either from windows explorer (open or ), be selected from a viewing or editing application from the native file chooser, or drag-n-drop into an editing or viewing application.
Further, i need the trigger to "hold" the event from completing the action until the runtime on the program has completed. The event handler program may return a pass state, or fail state. If fail state has been returned, then the event must disallow the initially requested action.
Lastly, I need to add to the file in question a property or attribute that will contain metadata that will be used by the above event trigger handler program to make a determination as to the pass/fail condition that will ultimately determine if the user is permitted to open the file.
Please note that this is NOT a windows event log situation, but one at the OS level file open event.
thanks very much for your help.
Edit
What I had hoped that someone was aware of was an OS level trigger, similar to how you can enable a trigger on an event-log writer occurance in Windows (ie: send an email, run a script when an event hits the event logger).
The application environment I work in, a PLM system, allows for event handling. So, when a user initiates an action, say a checkout of a file from an object, there are 3 available handlers or triggers that can be programmed. The "check" or "pre-action" trigger is a process that fires when the user starts initiates the event, but before the system permits it to be processed. So, one can block or otherwise alter the response of the system programmatically based on some condition, like user context.
I have also enabled startup/shutdown script firing via group policy, so i can delay a server shutdown until a database has closed properly. This was done in Windows server 2003. So, with that hook, i could manage shutdown or startup.
Hence, I had hoped someone might be aware of an OS trigger that would do the same for a file-open operation. This would be deployed on all workstations and desktops.
Again, if there are any ideas, it would be greatly appreciated.
Thanks again.
regards,
j
A couple strategies come to mind. One is to run the app with your own DLL to intercept API calls like WriteFile. Another would be to run the app under the debugger interface.
I have an executable that can run normally or as service. At the startup it may show an error message if there is an error (using MessageBox api). This can cause failure if the application is running as service but not allowed to interact with desktop.The process may appear to be hanging. Is there a programmatic way to detect if the application can interact with desktop ? I can then use some other error notification mechanism (log file etc)
You could specify MB_SERVICE_NOTIFICATION when calling MessageBox(), which will display the message in the currently active session.
But, displaying a message box from within a service is not what you really want.
Services are supposed to run in the background and not interact with users directly. One of their characteristics is that they can (and often do) run even when no user is logged on. In Windows Vista they even run in a totally different session than all other users'. Displaying a MessageBox could result in your services being blocked, because the message was invoked in your service's own session without the user knowing about it.
Writing to some sort of a log file or using windows' EventLog is the prefered method.
From MSDN:
To determine whether a service is running as an interactive service,
call the GetProcessWindowStation function to retrieve a handle to the
window station, and the GetUserObjectInformation function to test
whether the window station has the WSF_VISIBLE attribute.
In .NET you can use Environment.UserInteractive
The UserInteractive property reports false for a Windows process or a
service like IIS that runs without a user interface. If this property
is false, do not display modal dialogs or message boxes because there
is no graphical user interface for the user to interact with.
From http://msdn.microsoft.com/en-us/library/ms683502(VS.85).aspx:
To determine whether a service is running as an interactive service, call the GetProcessWindowStation function to retrieve a handle to the window station, and the GetUserObjectInformation function to test whether the window station has the WSF_VISIBLE attribute.