Killing a Windows System.Process on application crash?

Unity Engine
1

Working on a performance tracker in Unity that uses Windows32 System.Process to run typeperf.exe (command line performance monitor).

Works well, except when the Unity app crashes this process does not get killed, which is causing our Steam application to fail to shut down properly (and consequently fail to launch properly the next time). The process is closed correctly when the user quits the application normally.

Does anybody know a way to ensure a Process gets killed when Unity crashes?

It almost seems like we need to write a second external process that maintains a connection with Unity, and then shuts itself and the typeperf process down if the connection is lost… But maybe there is an easier way?

Thanks a bunch!

Kill Process on Unity crash
2

I think that’s the only way. The second process could just check the list of running processes every few seconds and if the Unity exe isn’t there, it would close typeperf and itself. There’s not really a way for a process to catch itself crashing since at that point it has crashed and isn’t in a stable state.

1 Like
3

Is this for debugging purposes? If so, why not make the performance tracker a separate application from the Unity app?

And yeah, this is pretty much the same solution as starting a second process to monitor the first process. :confused:

1 Like
4

Thank you for your replies; I’m currently looking into using TaskKill as a second process to manage the lifecycle of typeperf

5

Have come up with a working solution that is not perfect but better than nothing. I now start another process (schtasks.exe) that schedules a call to taskkill.exe to kill typeperf, with a short delay, then use InvokeRepeating to call the code that deletes the scheduled task, and creates a new one for another in the future. That way, the task never gets killed while Unity is running, but does if Unity crashes.

This approach has a few limitations. There can be a significant delay (up to 2 minutes currently) between when Unity crashes and when the process gets killed. This is not ideal, but schtasks ignores seconds so I have not yet found a way to make the delay shorter while also avoiding cases when the performance tracker gets killed while Unity is running.

Another issue is performance; the repeated invoke causes significant spikes in CPU usage every time. Will need to do more optimization on how the processes are managed in order to reduce the impact on the CPU…

Now waiting on a QA build to test the solution in an actual Steam beta build (hopefully I didn’t just kill one task that keeps the Steam app running to replace it with another!).