Solved Kill process for another user

Windows 11 23H2

I've ran into an issue where I encounter an error when switching users on Windows computers. I have an application that starts with Windows. If another user (Fast User Switching) logs on, they get an error that the application is already running. I have tried disabling auto-start in the application's settings and creating a batch file with something like:


I then create a shortcut for the batch file and place the shortcut in the C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup folder.

I think the problem is that some users are not admin.

Is there anyway to kill an application that is running under an admin account when a non-admin user logs on, and then restart the program under the current user?

You will need to create an elevated Scheduled Task, to allow non-admin users the limited ability to kill that named app.

1. As Administrator, create this scheduled task:

2. Edit your Startup script to include the commands:

While any user can manually invoke this task, they can't do any damage beyond killing someone else's instance of program.exe

Thank you for this

Since Fast User Switching is enabled, using the startup folder to trigger the task will not work. It's only triggered if an account is logged out of before logging in. Simply switching between accounts does not trigger it.

I found a suggestion that uses logon events in the security audit log to trigger the task. However, I can't figure out which event number(s) to use. I see multiple events repeated in the audit log each time an account is logged into. If I use these events as triggers, won't that trigger the task multiple times? I don't see any event numbers that are listed only once per login.

I also see another problem. If starting the application via Task Scheduler, it will run in the background (using specified credentials) so the systray icon will not be visible for the other users to interact with.

It sounds like you're leaving out key details on the problem description.

What's the nature of this shared PC? What type of application does everyone need to have the same app running (but it doesn't allow multiple instances)? Why can't you leave everyone a desktop shortcut which kills/restarts the app, or your users aren't that mindful?

Fast User Switching is logged by events 4778 & 4779

Audit logon events must be enabled:
Group Policy -> Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Audit Policies -> Audit logon events

One of the problems is that the users are not tech savvy so I need to automate as much as possible. A couple of users can barely remember how to login, literally.

The application is a proxy client which does not allow multiple instances. So if I select auto-start in the proxy client settings on a multi-user computer, when users switch accounts, the current user will get a couple of error message alerts. The users don't know what to do with them.

I've tried setting up a task but my account is the only admin account. When I setup the task, it runs under whatever account I specify so it runs in the background for the other users so the systray is not visible for the other users. I guess this is not a deal breaker but I was trying to find a way to kill and restart the proxy client so it runs under the currently logged in account.

After playing around, I'm not confident using the event trigger works that well. First, there's a slight delay before a session disconnect is registered, and by the task execution time, you've already switched to the new user.

The second problem is worse: while you can reliably trigger the new session event -- it doesn't work when you switch back the ORIGINAL user. Simply because the first user didn't log themself on or off, they got displaced by another user.

I would go back and just create a shortcut for the elevated task kill, and have your users click it every time they fast switch.

...it doesn't work when you switch back the ORIGINAL user.

Click to expand...

Yep. I ran into that as well. Thanks for taking the time to play around with this.

At this point, I don't see any way to accomplish what I was after. Using a scheduled task triggered by any user logging in seems to be my best bet. The client app will continue to run in the background and no errors will be thrown when switching users.