I need to obtain an exact time of fire'ing process
(not the time of the creation of the proces which
as I know is some time later) I need to obtain
the time of 'running' program yet before its image
is loaded into memory. Is it obtainable?
Side question - all running processes in winapi
are created thru CreateProcess/Ex function
calls (Then the time I need would be the
time of calling such function) or ther are
some other ways of running processes in windows
under the hood?
GetProcessTimes() should do the trick. It returns the process creation time, which corresponds to when the kernel object was actually created irrespective of when/if the image's code is executed.
Related
Is it possible at all to read the value (presumably a variable, since it changes every few seconds and is shown on screen) from a process in Windows? This is some custom, fairly old (10y) Windows GUI application that shows values (part counter) from manufacturing machine connected to it via some proprietary protocol (even using a dedicated PCI commmunications card).
I got the idea when reading about people modifying settings in a game (change high-score, change difficulty level, etc).
On Windows, there is an official API ReadProcessMemory for reading data from a process's memory:
ReadProcessMemory copies the data in the specified address range from the address space of the specified process into the specified buffer of the current process. Any process that has a handle with PROCESS_VM_READ access can call the function.
While I am hopeful that it works once the address/offset of the value in question is known, I am not so sure if this application will allocate memory differently when started the next time.
This is how I would approach it:
continuously, e.g. every second
take a screen shot of the application,
take a process dump (procdump from sysinternals) of the application
analyse the process dump and try to find the location/offset of the value in question
compare process dumps from different startups of the application to see if the value is at the same offset
Is this feasible, or is it completely obvious that memory allocation is very dynamic (between restarts and even during runtime) and using an offset-based approach will be doomed?
I am working on a program to start a long running process (afplay, with long sound files) using system() and at a later time possibly decide to terminate this process. It seems that it would be straightforward to invoke a system("prog") call and then later a system("killall prog") call. Using pthreads, I fire up a thread to invoke the initial system("prog") call and then later if application detects that its time to terminate early, the main thread will call system("killall prog"). Through print statements I can see that the main thread properly detects the logic to stop but the subsequent system call blocks until the original system call is finished (the main thread doesn't appear to block until this time, other activity does progress past the thread creation for the initial system call). If I try the killall from a separate shell after my program invokes the prog, killlall works (as you'd expect). I know that macOS has requirements on programs that interact with the ui libraries need to handle such activity from the main thread only. Are there other requirements for programs shelling out to system(3) that I clearly am ignorant of?
On windows, the only difference in the code is the choices for "prog", and the behavior works as I expect.
system() is expected to block until the launched program exits -- if it didn't, there would be no way for system() to return the exit-status of the child process as part of its return value.
If you want your thread to continue executing in parallel with the child process, you will need to use a different API (typically fork() followed by calling exec() from the child-process's branch of the fork) instead.
Edit: I rephrased my question, please ignore all of the comments below (up to the 7th of May).
First off, I'll try to explain the problem:
My process is trying to show a Deskband programmatically using ITrayDeskBand::ShowDeskBand.
It works great at any time except for when the OS is loading all of its processes (after reset or logout).
After Windows boots and starts loading the various applications\services, the mouse cursor is set to wait for a couple of seconds (depends on how many applications are running \ how fast everything is).
If the mouse cursor is set to wait and the process is running during that time, the call will fail.
However, if my process waits a few seconds (after that time the cursor becomes regular) and then invokes the call, everything works great.
This behavior was reproduced both on Windows 7 and Windows Vista.
So basically what I'm asking is :
1) Just for basic knowledge, What the OS does when the cursor is set to busy?
2) The more important question : How can i detect programmatically when this process is over?
At first, I thought that explorer hadn't loaded properly so I've used WaitForInputIdle but it wasn't it.
Later I thought that the busy cursor indicates that the CPU is busy so I've created my process using IDLE_PRIORITY_CLASS but idle times were received while the cursor was busy.
Windows never stops loading applications and/or services!
As a matter of fact, applications come and go, some of these interactively some of these without any user interaction. Even Services are loaded at different points of time (depending on their settings and the external conditions - e.g the Smard Card Resource Manager Service might start only when the OS detects that a Smard Card device has connected). Applications can (but must not) stop automatically so do some Services.
One never knows when Windows has stop to load ALL applications and/or Services.
If ITrayDeskBand::ShowDeskBand fails, then wait for the TaskbarCreated message and then try again. (This is the same technique used by notification icons.)
The obvious approach would be to check whether ShowDeskband worked or not, and if not, retry it after a few seconds. I'm assuming you've already considered and rejected this option.
Since you seem to have narrowed down the criteria to which cursor is being displayed, how about waiting for the particular cursor you are wanting? You can find which cursor is being shown like this:
CURSORINFO cinfo;
ICONINFOEX info;
cinfo.cbSize = sizeof(cinfo);
if (!GetCursorInfo(&cinfo)) fail();
info.cbSize = sizeof(info);
if (!GetIconInfoEx(cinfo.hCursor, &info)) fail();
printf("szModName = %ws\n", info.szModName);
printf("wResID = %u\n", info.wResID);
Most of the simple cursors are in module USER32. The relevant resource IDs are listed in the article on GetIconInfo.
You apparently want to wait for the standard arrow cursor to appear. This is in module USER32, and the resource ID is 32512 (IDC_ARROW).
I suggest that you check the cursor type ten times a second. When you see the arrow cursor ten times in a row (i.e., for a full second) it is likely that Explorer has finished starting up.
Is there any way to find out what was the last Exit Code of an application the last time it run?
I want to check if application wasn't exit with zero exit code last time (which means abnormal termination in my case) And if so, do some checking and maybe fix/clean up previously generated data.
Since some applications do this (they give a warning and ask if you want to run in Safe Mode this time) I think maybe Windows can tell me this.
And if not, what is the best practice of doing this? Setting a flag on a file or something when application terminated correctly and check that next time it executed?
No, there's no permanent record of the exit code. It exists only as long as a handle to the process is kept open. And returned by GetExitCodeProcess(), it needs that handle. As soon as the last handle is closed then that exit code is gone for good. One technique is a little bootstrapper app that starts the process and keeps the handle. It can then also do other handy things like send alerts, keep a log, clean up partial files or record minidumps of crashes. Use WaitForSingleObject() to detect the process exit.
Btw, you definitely want to exit code number to mean the opposite thing. A zero is always the "normal exit" value. This helps you detect hard crashes. The exit code is always non-zero when Windows terminates the app forcibly, set to the exception code.
There are other ways, you can indeed create a file or registry key that indicates the process is running and check for that when it starts back up. The only real complication with it is that you need to do something meaningful when the user starts the program twice. Which is a hard problem to solve, such apps are usually single-instance apps. You use a named mutex to detect that an instance of the program is already running. Imprinting the evidence with the process ID and start time is workable.
There is no standard way to do this on the Windows Platform.
The easiest way to handle this case is to put a value on the registry and to clear it when the program exits.
If the value is still present when the program starts, then it terminated unexpectedly.
Put a value in the HKCU/Software// to be sure you have sufficient rights (the value will be per user in this case).
I need to run a ruby script for one week and check whether it is running for every hour.
Could you please suggest me some way? I need to check this in windows machine.
For ex:- I have script called one_week_script.rb which will run for one week, in between i want to check whether the script is running or not? if it is not running, then running that script from another script
A typical solution is to use a "heartbeat" strategy. The "to be monitored" notifies a "watchdog" process on a regular interval. A simple way of doing this might be to update the contents of some file every so often, and the watchdog simply checks that same file to see if it's got recent data.
The alternative, simply checking if the process is still 'loaded' has some weaknesses, The program could be locked up, even though it's still apparently 'running'. Using the heartbeat/watchdog style means you know that the watched process is operating normally, because you're getting feedback from it.
In a typical scenario, you might just write the current time, and some arbitrary diagnostic data, say the number of bytes processed (whatever that might mean for you).