I've installed Windows 8 around a month ago and have been having issues where when a process hangs I am unable to end/kill it. Neither task manager nor CMD Taskkill /f /PID #### will do the job, so I figured I'd write up my own process killer in C# and see what issues come up.
After writing up a small app I realized that I'm not all that smart as I thought - I'm still unable to end the process. At first I was able to find the process by name/PID:
Process p = Process.GetProcessById(aPid)
//or
foreach (Process p in Process.GetProcessesByName(aProcessName)
..and was getting "Access denied" exception when I tried to:
process.Kill();
..after a few attempts that changed and I would be unable to find the process anymore. Eg. when I tried to find it by name or PID nothing was returned, while the process still remained in the Task Manager and on my screen.
I have also read up on Process #MSDN and it says that "Access Denied" can be thrown if the process is already terminating or could not be terminated.. :(
Help? Is there really no way to FORCE end process?
Well, you are essentially running into the same problem that prevents Task Manager from terminating the process. There are two possible reasons. One is associated with the access denied exception, the process might have removed the access right to other processes to acquire a handle to the process. Since you are running on Windows 8 you have .NET 4.5 installed. Which provides a new method to the Process class, you can call EnterDebugMode(). That enables the SeDebugPrivilege, might be good enough to now make Kill() work.
The other is a much bigger problem, the process may have a thread active in kernel mode that is not exiting. Best way to diagnose that is by using Task Manager, Details tab, right-click one of the column headers and choose "Select Columns". Tick "Handles". Look at the displayed value for the process. If you see a non-zero value then the process is very likely to have a handle opened and is waiting for a device driver to perform an I/O request. And that device driver is otherwise impervious to Windows asking it to cancel the request. Narrowing down the troublemaker is not that easy, you have to know more about exactly what kind of I/O requests your process performs. Follow up on this by asking a question about it at superuser.com
Related
So I have a background program that starts with Windows, minimized to system tray icon. Once it loads I need it to constantly start checking if a process has started (for example VLC). Once the process has started, It must wait for it to close in order to start doing stuff and then get back to check if it has started. I've been trying to do this for a while now, but I just can't figure out how.
How would I constantly check if a program has started?
One way would be to have the Background Deamon look for aprogramm of a specific name. Unfortunately this not overly reliable (due to name overlaps), would require a lot of polling and runs the risk of race conditions (the process starting when your deamon is still working).
What would be reliable, is if it is the Deamon that actually starts the foreground process. That way it could do work before Process.Start() and after Process.WaitForExit(), with full information when both states happen: https://learn.microsoft.com/en-us/dotnet/api/system.diagnostics.process?view=netcore-3.1
Steam is a good example. It is a single-instance process, so any further requests can be relayed to the running instance. The desktop links to programms/games are actually weblinks - not programm links. Those links use the :steam protocoll, wich is associated with the steam processes. So it goes like this:
user klicks on a WebLink with :steam procotoll
Windows resolves to hand this into a commandline call to the steam programm
A instance is started with the proper order in via commandline. Single instancing will not allow a 2nd instanc to start, but hand the request over a already running one
the already or now suddenly running instance calls the programm, having full data on when it starts and ends - being the actuall logical caller
I want to create a watchdog in c# in which the user selects a process by his pid a then the application watch he consumes of ram and CPU, after, if that application pass over the min consume then restart the process so his CPU and ram go again to 0.
my problem is when I want to restart the process, because I can get the process by his pid, but can't restart again because his want the path of application but I don't want restart entire application I only want restart that specific process
How I can achieve this?
Is possible to do this?
UPGRADE:
well, I think this understand better with an example, so here is:
First, imagine I want to watch the process with pid 12780 of the application Microsoft Edge.
Second, when this process exceeds the min consume of RAM or CPU what I set in my watchdog, that process should restart, begin with RAM and CPU in 0.
But here is the problem if I want to restart that process I can kill it, yes, but I can't start it after, Even if I set the full path of my application (in this case Microsoft Edge) it can't start again.
So, how I can restart only that process don't the full application?
Once you use How to get the full path of running process? to get the executable that was used to start the process you might be able to restart it.
However, if the executable was started in a specific way (think of a working folder, start parameters, environment variables, ...) it might not run the same way it was previously started. These special setting can be retrieved by using this answer: https://stackoverflow.com/a/5497319/563088 (commandline result)
The environment variables can be retrieved by using How to get the Process Environment Block (PEB) from extern process?
No, there is no way to do what you want.
If you wanted to restart a full application, that would be possible, but as you would potentially lose some data.
However, you say that you want to restart only a part of your application, say one of the processes, and that is not possible, unless it is specifically supported by the application itself - which is not generally the case.
Let the explain why.
When an application decides to create a new process, that process gets a copy (simplifying, but still) of the memory of the parent process at that moment, and after that both processes start diverging from that state, so it doesn't exist anymore.
Is it possible to create applications that allow you to restart it's processes? Yes. But most applications don't allow you to do that, and it's not even always clear what would mean to restart a process.
So I am trying to debug a process in MVC4. I send the POST request, watch it manipulate the database, etc etc. However, after I have seen the information I want to see, I click "Stop Debugging". In any typical GUI .NET application, I would think that the process would terminate, but it instead continues to execute. If I make any changes in the file and try to debug again, the breakpoints will not be hit because the files are not out of date from the previously ran process which is still running. I have 2 choices at this point - let it run or kill the w3wp.exe task with the Task Manager in order to continue debugging.
I have tried to click Debug -> Terminate All, but the process still continues to execute. I know this because I attach to the process (Debug -> Attach to Process) and it pauses at one of my many breakpoints throughout its execution.
Let it be mentioned that I am using Google Chrome to send the POST requests to the Controller, so it may not be terminating because I am not using IE - however, I do think that there is a better solution then using the IE browser.
In order to work around this, I have to go into the Windows Task Manager and kill the IIS process (w3wp.exe), which seems downright messy. Any ideas?
If I make any changes in the file and try to debug again, the breakpoints will not be hit because the files are not out of date from the previously ran process which is still running.
Once you modify any code file you require to re build the solution and then again Debug -> Attach to Process.
Please also note that Stop Debugging does not mean that it will kill process always. It will kill only Visual Studio Web Development Server or sometime IIS Express process with Visual Studio. Here you mentioned w3wp.exe. While this process is managed by IIS.
Couple more graceful ways to restart your w3wp worker process:
in command line, run "iisreset"
in IIS Manager console, select the corresponding application pool and click "recycle"
For a graceful shutdown of a long-running business logic, try Application_Shutdown event in global.asax.
For not-so-graceful approach, ThreadPool may help you - threads on it are marked as Background and thus Windows won't wait for them to complete when main thread of w3wp exits. However this approach doesn't always work, because 3-rd party libraries (especially networking) may create non-background threads that, again, will delay shutdown.
For even faster and dirtiest, use Environment.Exit, triggered by some debugging-only event. http://msdn.microsoft.com/en-us/library/system.environment.exit(v=vs.110).aspx
I'm currently writing quite a simple app, but it makes a change to the OS which gets changed back when the program is closed.
The worry of course, is if the program crashes. I can do everything in my power to prevent it from crashing, or handling things if it does crash - but I can't stop someone from force closing the process (unless I can?)
Is there a way to catch that event and run just a very quick cleanup before the process exits?
I don't think there is anything you can do if your process gets killed - one approach would be to have your app spawn a helper process that is just there for this case. When your app terminates that process can detect that and "fix" the OS setting as desired before it shuts down itself - obviously this only would work if that other process doesn't get killed first.
You can hook UnhandledException. You can't stop the application terminating, but you can log or do some clean up. This allows you to handle the case of application crashes.
It terms of someone actually just killing the process there's nothing you can do about that.
Program defensively.
Write the original settings to a file. Delete the file when closing. When starting, check whether the file is there - if it is, your process was killed and you know what to return the settings to.
Programming 201 - the basics of transactions, applied to system settings wit hthe program runtime as transaction boundary.
If you don't mind a little interop to C or C++ code, and if you're running on Windows Vista or newer, you could make use of the Application Recovery and Restart APIs. These APIs tell Windows to intercept your process when something catastrophic happens, so that you can perhaps call a little cleanup code before Windows kills the process completely.
See http://msdn.microsoft.com/en-us/library/cc948909.aspx.
What might cause an executing process from windows service to run slower than running from command line?
When I execute a process(another exe) from teh command line with admin rights, it is four times faster than when a windows service executes the same process. What could be causing this.
Permissions on directories and files are okay for the account. It runs successfully, just 4x slower. Need ideas on what to investigate to figure out the problem.
We have been using sysinternals processexplorer and not seeing anything.
Where is the advances tab with the ability to modify the "priority" to see if that is causing the problem?
In Windows background services may be given less priority, and that is configurable in the advanced tab of computer properties.
Assuming the priority of both applications is the same, you need to profile the app and see which calls are taking the most time. That should at least give you enough detailed information to come back and ask "why is this specific call running slowly" instead of "why is my app running slowly".
Download the sysinternals process monitor tool from www.sysinternals.com and then start tracing the application, that will show you what the process is doing in terms of registry / file access and will potentially show up what to look at when the delays are occuring.
If you have the debug symbols it can also give you the function call name in the dll / app that is being called, but even knowing what is occuring when a delay occurs and what dlls are in use, user mode or kernal gives you a good indication where to start.