We have a very critical process that needs to be monitored. If it crashes for some reason the admin needs immediate notification. We have tried different scenario's but none work for their own reasons:
VBScript SELECT * FROM Win32_Process WHERE Name LIKE '%IPRUN%'
This doesn't work because the process doesn't exit on crash it goes a WER window. So when you hit close in WER window only then the process exits (i.e. disappears from the task manager) so until the process doesn't disappear this code is useless.
EventViewer: The application produces Start and Close events but does not for crashed events (for reasons understood) as application thread has exited abnormally, and might be its handled in an unusal way
Is there any other way of monitoring this?
Related
I have an UWP that starts a background task that got fired every 15 Minutes.
On the MainPage of the UI the Complete Event for that task is set and called.
I played a bit to see how events where handled if the application goes to the background or even got suspended.
I came to the expression that all events got queued and are processed when the application leaves the suspended state.
This is not what I had in mind. I need an option to only process an event once and ignore all other events raised during the suspend of the UI.
The work I have to process during the OnComplete event is quite time consuming so it is very ineffective to call that multiple times and the result would not change either.
One option would be to set the last run time of the event and ignore calls inside a given timespan, but is there no default way to handle these inside the event system?
I took the MS example for background tasks um UWP. In this example application you can register a task and when the task got called it counts from 0 to 100 in steps of then and displays the percentage on the main windows. It is quite an easy example an can be downloaded from github (https://github.com/Microsoft/Windows-universal-samples).
The example uses the OnProcess event but it makes no difference.
What I done
1) Start the Application
2) Register Background Task
3) Run the Task though Visual Studio Process Location Toolbar
4) While the task is running set the Application to Suspended via the Process Location Toolbar
5) Wait a bit and that Resume the Application
6) With a breakpoint in the OnProcess Method of the example I could see now that this method is know called several times (Once for each Raise Event Call in the Background Task.
What I want is that if the Application Resumes the EventMethod will only processed once for all RaiseEvents that are waiting to be processed
When I debug my program, which consists of looping over thousands of entries in vectors multiple times, it simply freezes the program but does not provide any error messages whatsoever. Does Visual Studio have some sort of auto-time out that I am experiencing?
Check may be your program is going into infinite loop Or doing some heavy task that makes your UI unresponsive(if you have windows form). Since you are debugging this program then why dont you set breakpoint in code and check where your program is causing issue.
And yes there is no time out for Visual Studio,But for program window.This is known as Hang Status.
When an application (or more accurately, a thread) creates a window on the desktop, it enters into an implicit contract with the Desktop Window Manager (DWM) to process window messages in a timely fashion. The DWM posts messages (keyboard/mouse input and messages from other windows, as well as itself) into the thread-specific message queue. The thread retrieves and dispatches those messages via its message queue. If the thread does not service the queue by calling GetMessage(), messages are not processed, and the window hangs: it can neither redraw nor can it accept input from the user. The operating system detects this state by attaching a timer to pending messages in the message queue. If a message has not been retrieved within 5 seconds, the DWM declares the window to be hung. You can query this particular window state via the IsHungAppWindow() API.
Detection is only the first step. At this point, the user still cannot even terminate the application - clicking the X (Close) button would result in a WM_CLOSE message, which would be stuck in the message queue just like any other message. The Desktop Window Manager assists by seamlessly hiding and then replacing the hung window with a 'ghost' copy displaying a bitmap of the original window's previous client area (and adding "Not Responding" to the title bar). As long as the original window's thread does not retrieve messages, the DWM manages both windows simultaneously, but allows the user to interact only with the ghost copy. Using this ghost window, the user can only move, minimize, and - most importantly - close the unresponsive application, but not change its internal state.
A nice article is written in this following link.
How program window works
Notification-area icons for killed processes will disappear if you mouseover them, as this makes Windows check whether the associated process is still running.
Is there a way to trigger this cleanup process programatically?
Is there a way to trigger this cleanup process programatically?
No there is not. I've seen some programs use SendInput to put the cursor over the notification area, but that feels rather dirty to me.
Refer to the MSDN documentation for SetForegroundWindow
Windows intentionally refuses many requests to set a particular window to foreground, with the stated goal that:
An application cannot force a window to the foreground while the user is working with another window.
The conditions under which SetForegroundWindow will succeed are documented as:
The system restricts which processes can set the foreground window. A process can set the foreground window only if one of the following conditions is true:
The process is the foreground process.
The process was started by the foreground process.
The process received the last input event.
There is no foreground process.
The process is being debugged.
The foreground process is not a Modern Application or the Start Screen.
The foreground is not locked (see LockSetForegroundWindow).
The foreground lock time-out has expired (see SPI_GETFOREGROUNDLOCKTIMEOUT in SystemParametersInfo).
No menus are active.
This documentation does not sound correct. I believe that it started as a shorter list, in which only one of the conditions needed to be met. But the actual behavior is more complex.
Can anyone confirm the actual behavior? Is it:
A process can set the foreground window only if all the following hold:
One or more of the following conditions is true:
The process is the foreground process.
The process was started by the foreground process.
The process was identified in an AllowSetForegroundWindow call made by the foreground process
The process received the last input event.
There is no foreground process.
The process is being debugged.
The foreground process is not a Modern Application or the Start Screen.
One of the following two conditions is true:
The foreground is not locked (see LockSetForegroundWindow).
The foreground lock time-out has expired (see SPI_GETFOREGROUNDLOCKTIMEOUT in SystemParametersInfo).
No menus are active.
If other experts concur that the documentation is erroneous here, I will file a bug report on Connect referencing this question.
I understand that Chrome using re-parenting in order to have child plugins such as Flash render from different processes.
I have experimented with this, and I have got it working using the SetParent Win32 call.
However, when I force the child GUI thread to block, the parent process will also hang as soon as the mouse moves over a the window area owned by the child process. Presumably this is because the message loop in the parent application is calling down to the child and it never responds. How does Chrome get around this?
Flash uses the re-parenting trick. It has its own .exe and renders to its own window. That doesn't prevent hangs, any message that is sent from that window to its owner is going to block when the owner isn't pumping messages. As you found out.
Browsers uses a different trick. They create an invisible helper process for each tab and render to a memory device context. And blits the result to their desktop window. Any input messages are shuttled back to that process. That makes them immune from crashes and hangs in that process, killing that helper process keeps the browser going. Much harder to do yourself.