API Monitor has a feature to automatically watch for a new process starting and ask if you want to monitor it. However I have not been able to get this to actually work. The only option in the program I can find which seems to be related is the File menu "Pause Process Notifications" option. However, this is disabled which gives me the impressions that it can't be turned off but also that it is supposed to work automatically "out of the box". But whenever I start a new process, nothing happens.
Specifically I'm referring to the feature described here:
Process Notification
API Monitor intercepts process creation and allows you to select the
process for monitoring. Each time a process is created by the system,
a notification window is displayed with options to monitor, skip or
terminate the process. This is especially useful for monitoring
processes with a short lifespan or processes that are automatically
launched in the background. Process Notification can also be used to
monitor applications such as consent.exe (UAC prompt), which run on a
different desktop.
The following screenshot shows an example of the Process Notification
window that is displayed when launching an application that requires
elevation
I've tried both the 32-bit and 64-bit versions of API Monitor (Version 2.0 Alpha-r13) running both as regular user and as admin; makes no difference.
How can this feature be activated?
The specific reason I'd like to use this feature is that I have process A which starts process B, and it is B I need to monitor. A and B each run for only a few seconds so I can't manually get it to monitor fast enough.
Finally after reading through API Monitor forums I found some information. Unfortunately (for now at least) it seems the answer is that this feature no longer works (since Windows 8.1).
As posted on http://www.rohitab.com/discuss/topic/40418-process-notification-on-81/?p=10093378
rohitabPosted 11 October 2013 - 03:38 AM
Due to security related changes in Windows 8.1, the Process
Notifications feature of API Monitor does not work. I will try to
resolve this issue as soon as possible and post a hotfix.
But a later update in 2014 indicated that it hadn't been fixed yet, and seems not to have been since then either.
It was implied that running in a Windows 7 (or 8.0?) virtual machine might be a workaround, or obviously finding another tool which has this capability.
Related
I want to make a windows application whose GUI will be streamed to another device (allowing remote control). The point is that I'm not willing to rely on creating Windows Sessions to isolate the GUI I/O's (1)
To achieve this, I started observing some existing solutions that are able to enable remote access using this premise to see if I could get a clue about where to start.
One of these solution is Winflector (BTW: it is free up to 2 connections).
I got interested in this solution because it seems (I'm guessing) it detects only the repainted regions. What I took from my observations are that:
While the streamed application is "invisibly" running locally in the same session I'm logged in (it shows the application process in my task manager), the application window seems not to be created anyhow - at least Inspect can't get any window information/handle of the application process - It looks like sort of a "GUI StdOut Redirection".
Apparently, no additional Desktop is created;
Also apparently, no Mirror Driver is installed;
Using Process Explorer, I found out Winflector adds some thread's to the original application process. I suspect it is about the GUI redirection (by the thread's names);
The application is started by the Winflector server - that is, it has control about the CreateProcess arguments.
What is the most likely technique to be used in this case?
Windows Hook?
Windows Messages interception?
Special Display Driver?
Sort of Memory Device Context?
Where should I start researching to get a similar approach? Any open source project regarding this subject would also be very welcomed.
PS: By my programming experience, this is sort of a whole "new world" - sorry if my questions are redundant/obvious/non-sense.
(1) That is, this application could be spawned, streamed and interact
with the remote client using the same session which a local user is
already logged in, without conflicting the IO (like a regular VNC
would do, for example). PS: At this moment, I'm focusing only at the
output.
Other similar question mostly target Windows XP, where everything was easier. =)
I'd like my application to be able to postpone the windows shutdown transparently, without having windows show this screen:
Is there any option left to me after the Vista changes to the WM_QUERYENDSESSION handling?
The target here is Windows 7 standard embedded on an embedded device that runs only my application. Before shutting down the user needs to perform some manual steps that can not be postponed until the next start and must not be forgotten. I'd like to have the user confirm these steps before shutting down.
I've come to the conclusion, that there is no way to do this. =/
The workaround I've found is to allow shutdown only via the software at opportune moments. The start menu or task manager is not available to the user, and the hardware power button behavior can be configured to do nothing in the systems power options.
When running a program, such as notepad, as a service do you not see the program visually?
I see notepad running in the task manager but I can't actually see its instance running. Why is this?
Services are meant as background applications, not foreground applications. Generally they run without direct user input or with user input through IPC (often providing a centralized point for multiple applications to communicate).
It's not common to setup any applications to just run as a service. Applications that run as a service are generally specifically engineered to do so because they perform certain tasks and may want to always be running to perform such tasks.
An application actually needs to support running as a service - typically it is done by recognizing the "\service" command line key. Some applications will recognize the absence of the "\service" key and either do nothing or show a warning.
When an application is started "as a service" it usually means that it has to work continuously in background and there's a chance that no user is currently logged on. That's why it should not expect any user input and therefore doesn't show the window.
Adding on #Quintin Robinson's answer, the reason why they doesn't show up on task manager is because they are (usually) run from an umbrella process.
To give you a better picture, download and run Microsoft's Process Explorer, then hold your mouse over one of the "svchost.exe" process running.
You should see some of the services that are running under it.
All user interaction in Windows takes place via Windowstations. By default, Windows services "interact" with a non-interactive station. It's not the station you're connected to, so you don't see any output.
You can change this behavior by changing the service properties, and enabling "Allow service to interact with desktop".
You can read more about this here.
Applications that run as a service (or that are launched by other applications that run as a service) by default run on a separate desktop that cannot interact with the desktop you see.
If you want to be able to interact with a service, you have set the service properties accordingly.
That being said, what you're seeing with Notepad almost certainly has nothing to do with services.
I have a console application (written in VB6 ) which is behaving strangely on my machine. I kick it off from the command line and what should be a two minute job drops straight back to the prompt - if I run this on another machine the executable will sit and wait until the job finishes before returning control back to the prompt. If I check process explorer I can see that the executable is running as a background process and other than this strange background-ness is running as expected.
Any thoughts on why this could be happening? (Running on 32-bit Windows XP Pro SP3.)
It's totally unclear whether this is an application you wrote and have the source code for. If that's the case, you need to get in and start debugging. At the least, use OutputDebugString to send information about what's going on to any number of potential viewers. Taking that a step further, consider rewiring the app using the Console module I wrote, along with vbAdvance to recompile. This combination will allow you the full power of the VB6 IDE to debug within. No more guessing about what's going on.
Then again, if it's not your app, I'm not sure what VB6 has to do with it and wish you the best of luck trying to figure out what's up.
It sounds to me as though the app isn't being recognised as a console app on one of your machines. Console apps weren't officially supported in VB6, although there are some well-known hacks for creating them (particularly the free add-in vbAdvance). Possibly your console app is a bit unreliable? If Windows thinks your app is a GUI rather than a console app, it won't wait for it to finish.
As a pragmatic workaround: try launching with start /wait rather than just using the exename. That forces the command prompt to wait for the program to finish, whether it's a GUI app or a console app.
Sounds like an error is occurring that is being 'swallowed' by the application. Do you have the source code?
Errors in VB6 apps are often due to some COM component not installed and/or registered.
Download SysInternals Process Monitor and this will show up accesses to ProgIDs that fail (uninstalled/unregistered COM components).
Check out: Process Monitor - Hands-On Labs and Examples.
Have you checked permissions? Is the application accessing any network based resources?
The product we are working on allows the user to easily set it up to run automatically whenever the computer is started. This is helpful because the product is part of the basic work environment of most of our users.
This feature was implemented not so long ago and for a while all was well, but when we started testing this feature on Vista the product started behaving really weird on startup. Specifically, our product makes use of another product (lets call it X) that it launches whenever it needs its services. The actual problem is that whenever X is launched immediately after log-on, it crashes or reports critical errors related to disk access (this happens even when X is launched directly - not through our product).
This happens whenever we run our product by registering it in the "Run" key in the registry or place a shortcut to it in the "Startup" folder inside the "Start Menu", even when we put a delay of ~20 seconds before actually starting to run. When we changed the delay to 70 seconds, all is well.
We tried to reproduce the problem by launching our product manually immediately after logon (by double-clicking on a shortcut placed on the desktop) but to no avail.
Now how is it possible that applications that run normally a minute after logon report such hard errors when starting immediately after logon?
This is the effect of a new feature in Vista called "Boxing":
Windows has several mechanisms that allow the user/admin to set up applications to automatically run when windows starts. This feature is mostly used for one of these purposes:
1. Programs that are part of the basic work environment of the user, such that the first action the user would usually take when starting the computer is to start them.
2. All sorts of background "agents" - skype, messenger, winamp etc.
When too many (or too heavy) programs are registered to run on startup the end result is that the user can't actually do anything for the first few seconds/minutes after login, which can be really annoying. In comes Vista's "Boxing" feature:
Briefly, Vista forces all programs invoked through the Run key to operate at low priority for the first 60 seconds after login. This affects both I/O priority (which is set to Very Low) and CPU priority. Very Low priority I/O requests do not pass through the file cache, but go directly to disk. Thus, they are much slower than regular I/O.
The length of the boxing period is set by the registry value:
"HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\DelayedApps\Delay_Sec".
For a more detailed explanation see here and here
The program probably needs some more info put into its properties. It needs to "Run As", instead of just running.
Maybe this application should be developed as a service, instead of a program to be launched, or you could have service that launches the program when its determined the best window of opportunity.