0X80040210

Fix 0x80040210: PerUser subscription owner not logged on

Windows Errors Intermediate 👁 0 views 📅 May 29, 2026

This error hits when a scheduled task or event subscription runs before the user logs in. The fix: change the task to run whether user is logged on or not.

You're setting up a scheduled task or an event-triggered subscription on Windows—maybe a backup script, a log collector, or something that kicks off when a specific event hits. Everything looks fine in the wizard. Then you test it, and boom: 0x80040210 with the message "The owner of the PerUser subscription is not logged on to the system specified."

This is a classic gotcha. It almost always happens when you create a task while logged in as an admin but the task is set to run under your user account—and the system tries to fire that task before you've logged on for the session. I've seen it bite people setting up event-forwarding subscriptions on Windows Server 2019, and just last month a client's backup script silently failed for two weeks because of this exact error.

Root cause

Under the hood, Windows Task Scheduler and Event Subscriptions store the user context (the SID) for any task set to "Run only when user is logged on." If the machine boots up or an event triggers before that specific user logs in interactively, there's no active user session, no SID loaded, and the task can't run. You get 0x80040210.

The fix is simple: stop tying the task to a user logon session. You have two real options:

  • Option A: Change the task to run whether the user is logged on or not (and store the password).
  • Option B: Switch to a built-in account like SYSTEM or NETWORK SERVICE.

Option B is cleaner if the task doesn't need network-specific user permissions. Option A works when you need a specific domain account to access shares or resources.

Fix: Change the task to run regardless of user logon

  1. Open Task Scheduler (taskschd.msc).
  2. Find your failing task. It's probably under Task Scheduler Library or Event Viewer Tasks.
  3. Right-click the task and select Properties.
  4. Go to the General tab.
  5. In the Security options section, you'll see two radio buttons:
○ Run only when user is logged on
● Run whether user is logged on or not
  1. Select Run whether user is logged on or not.
  2. Click OK. Windows will ask for the user's password (if it's a domain account). Enter it twice.
  3. Test the task manually: right-click → Run. It should complete without the 0x80040210 error.

Alternative: Use SYSTEM or NETWORK SERVICE

If the task doesn't need your specific user context (like reading your personal profile directories), switch to a built-in account:

  1. In the General tab, click Change User or Group.
  2. Type SYSTEM or NETWORK SERVICE and click Check Names, then OK.
  3. Make sure Run with highest privileges is checked if required.
  4. Test it.

This bypasses the whole "user not logged on" problem because SYSTEM is always available. Downside: some network resources might not be accessible if they require explicit domain user authentication.

What if it still fails?

If you've changed the setting but still get the error, check these:

  • Is the task stored on a remote computer? If you're using Event Subscriptions (wecutil or Event Viewer subscriptions), the subscription might be pointing to a user account that doesn't exist on the remote machine. Check the Subscription PropertiesAdvancedUser Account.
  • Did you save the password correctly? For domain accounts, the password hash is cached. If the password has changed since you configured the task, re-enter it.
  • Is the task running from a GPO? Group Policy preferences can override your local settings. Check gpedit.msc under Computer Configuration → Windows Settings → Scripts for any conflicting tasks.
  • Last resort: Delete the task and recreate it from scratch. Sometimes the SID metadata in an existing task gets corrupted. Recreating forces Windows to write a fresh SID entry.

In nine out of ten cases, switching to "Run whether user is logged on or not" kills this error dead. If you're still stuck after that, it's almost always a wrong account name or a stale password. Check the Task Scheduler history tab for the exact error code—it'll tell you which account it's trying to use.

Was this solution helpful?