I can easily identify running processes by looping through the WMI Win32_Process elements. Is there a similar way to identify "applications" as in Task Manager? I assume that this is comparable to knowing whether the process has an open window. For example, when you exit Outlook, the OUTLOOK.EXE process keeps running. Task Manager no longer shows it as an application, but the process is still there. I want to be able to determine this difference from a script. I think I can handle examples in most any language.
It would appear that the way to do that is to enumerate all of the top-level windows.
http://support.microsoft.com/kb/183009
This looks like it does what you are asking: Running Processes/Applications
Related
I want to be able to detect whether a given exe was shellex'd programmatically or if it was entered and executed interactively in, say, CMD.EXE.
Is there anything about the way an exe is launched that indicates the mechanism that was used to launch it?
Context: Windows XP, Visual Studio 6 languages.
There might be an easier way, but the only way I can think of is to check the parent process name, which involves a few steps:
Get the ID of the parent process.
Get the handle of the process, using the ID.
Use GetModuleFileNameEx with the handle found (and NULL as the module) to get the executable's name.
Check if the executable's name is cmd.exe or whatever.
Bear in mind that the parent process might already be gone when (or while) you do this check.
Edit:
If your program is a console application, you can also check the console it's running in. If it was run from cmd, it will usually use the same console. So, you can use GetConsoleTitle, for instance, and see if it's "Command Prompt". This might not work on localized or different versions of Windows, but it's easy if you have limitated cases. You can also use GetConsoleWindow and GetWindowThreadProcessId instead of steps 1 and 2.
You can differ between say CMD and Explorer by inspecting the parent process, but you can't tell if it happened due to user action or not. Also AFAIK all ways to launch a process result in the same NtCreateProcess/PspCreateProcess call, so you can't tell which API was used either.
Al right! This might sound crazy.
I want to know if it is possible to see the code or something that a specific process is using. I have a scheduled task that is supposed to be ran by a process. The font end to this app says that the scheduled task executed successfully, but I don't see anything in the logs.
I want to know if there is a tool to see what a process is doing.
The best suite is Windows Sysinternals by Mark Russinovich (now bought by Microsoft).
Get it here.
Use Process Explorer.
Ever wondered which program has a
particular file or directory open? Now
you can find out. Process Explorer
shows you information about which
handles and DLLs processes have opened
or loaded.
The Process Explorer display consists
of two sub-windows. The top window
always shows a list of the currently
active processes, including the names
of their owning accounts, whereas the
information displayed in the bottom
window depends on the mode that
Process Explorer is in: if it is in
handle mode you'll see the handles
that the process selected in the top
window has opened; if Process Explorer
is in DLL mode you'll see the DLLs and
memory-mapped files that the process
has loaded. Process Explorer also has
a powerful search capability that will
quickly show you which processes have
particular handles opened or DLLs
loaded.
The unique capabilities of Process
Explorer make it useful for tracking
down DLL-version problems or handle
leaks, and provide insight into the
way Windows and applications work.
I'm not sure which technology you are using, but you could try to remotely debug the application the application, for example using Visual Studio. But to be able to do this you'll need the correct debug information files (.pdb).
If this is your own application you are trying to monitor, inserting some extra logging of some sort will be the easiest solution.
Another option you have is to make a memory dump at the moment you think the application is running. A memory dump is basically a snapshot of the entire memory. YOu can then use a tool like WinDbg to examine the contents of the dump.
Maybe you can give us a little bit more information?
Many Windows apps (like Skype or MSN for instance) don't let you start multiple instances, rather trying to run it a 2nd time just leaves the existing version running.
Is this typically done in some simple way - the start-menu shortcut is a 'wrapper' app around the main app - or is there some registry magic you can do to delegate the problem to Windows itself?
Specifically dealing with Win32 here (unmanaged C++) but happy to hear more general solutions as long as they are workable on Windows XP or later.
EDIT: this seems the best duplicate.
Named Mutex or similar OS-specfic named object. If it exists - app is running.
Lock file somewhere (in temporary directory, etc - create it on program start, remove on program end). Linux software frequently operates this way (some programs store PID in lockfile), but it isn't safe - if you suddenly lose power (electricity cut off), it is possible that lock file won't be deleted.
And you can always enum all running processes and try to find yourself.
There could be more ways to do it, but those are the first ones I could think of.
As far as i remember, there exist system-wide Mutexes. Set Mutex on first launch, if on launch already set, immediately exit.
Use CreateMutex() call an prepend the name with "Global\" should to the trick.
I just check to see if the process is already running: if it's not start the application, if it's already running bring the window to foreground. The check is done in the Main method.
I get the process name with System.Diagnostics.Process.GetCurrentProcess().ProcessName and check if it's already running System.Diagnostics.Process.GetProcessesByName(). If there are more than 1 processes focus the first of them and then exit.
I need to find out exactly what files/directories a Lua program uses so I can try to only pack what it needs into a ZIP file, and come up with a simple way to deploy this script.
I used SysInternals' Process Monitor, but I'm surprised by the small amount of information it returned while it watched the program (For Lua users out there, it's wsapi.exe, which is the launcher for the light-weight Xavante web server).
Does someone know of a good Windows application that can completely monitor what a program does, eg. something like a live version of the venerable PCMag's InCtrl5.
Thank you.
Process monitor will catch everything. If it's not catching the action then it must be happening in a different process. Try filtering based on the files you expect to be used rather than the process you expect it to happen in.
I am using CreateProcessAsUser() to make processes. I would like to tag some of them so that later on, given a process ID/handle I can work out whether or not it was I who launched them.
Are there any techniques for marking a process natively like this. I want my solution to be stateless, hence a table of PIDs is not suitable - nor is checking the parent of the process to see if I made it (the processes are reparented).
Any ideas? Thanks!
if you are targeting Windows Vista or Windows Server 2008, then you may use InitializeProcThreadAttributeList() and add the attribute list to the process through the STARTUPINFOEX structure when calling CreateProcess(). however, you have to destroy the attribute list yourself before the process terminates, and it does not seem to be the case from what i understand...
if the process have a window, you can also use window properties, but here again you have to destroy the property list when the window is destroyed, and you don't control this neither...
i am afraid you will have to resort to something else. can you explain why a table of PIDs is unsuitable ? i suspect it is because your "launcher" may terminate and have to find its processes again when it is restarted. in this case you should consider serializing those informations to disk when starting a process, and read them back when restarting (plus some additional checks to verify the validity of the serialized informations).