Scheduled task fails: "The operator or administrator has refused the request. (0x800710E0)"

vaguerant commented

2025-03-06 13:08:50 +00:00

(Migrated from codeberg.org)

I'm running the standard install (not portable) for LibreWolf with WinUpdater set to automatically check for updates. After initial setup, automated updates were not working at all on my end. I went investigating and found the LibreWolf WinUpdater task in Windows Task Scheduler, with the below error text under Last Run Result:

The operator or administrator has refused the request. (0x800710E0)

The account LibreWolf is running under is an administrator. LibreWolf was left running after initial install (including a period of PC hibernation). I was able to successfully update by closing LibreWolf, which from reading previous issues, I believe triggers another update check? After this, the Last Run Result text read:

The operation completed successfully. (0x0)

Forcing a manual run from the Task Scheduler (right click -> Run) now seems to work without issue, with the updater process running and presumably silently exiting when it finds no update. I will update this issue the next time a scheduled run occurs, which won't be until tomorrow because the machine won't be in use again until then.

I'm running the standard install (not portable) for LibreWolf with WinUpdater set to automatically check for updates. After initial setup, automated updates were not working at all on my end. I went investigating and found the LibreWolf WinUpdater task in Windows Task Scheduler, with the below error text under Last Run Result: > The operator or administrator has refused the request. (0x800710E0) The account LibreWolf is running under is an administrator. LibreWolf was left running after initial install (including a period of PC hibernation). I was able to successfully update by closing LibreWolf, which from reading previous issues, I believe triggers another update check? After this, the Last Run Result text read: > The operation completed successfully. (0x0) Forcing a manual run from the Task Scheduler (right click -> Run) now seems to work without issue, with the updater process running and presumably silently exiting when it finds no update. I will update this issue the next time a scheduled run occurs, which won't be until tomorrow because the machine won't be in use again until then.

ltguillaume commented

2025-03-06 18:00:54 +00:00

(Migrated from codeberg.org)

@vaguerant wrote in https://codeberg.org/ltguillaume/librewolf-winupdater/issues/38#issue-1038823:

I'm running the standard install (not portable) for LibreWolf with WinUpdater set to automatically check for updates. After initial setup, automated updates were not working at all on my end. I went investigating and found the LibreWolf WinUpdater task in Windows Task Scheduler, with the below error text under Last Run Result:

The operator or administrator has refused the request. (0x800710E0)

I have seen this issue before, but I was never able to find out what caused it. It just "went away". I might have something to do with hibernation/standby, because I did see this only on a laptop.

Another possible cause was that the username it was running under had an ampersand (&) in the name. Is that the case for you, too?

The account LibreWolf is running under is an administrator. LibreWolf was left running after initial install (including a period of PC hibernation). I was able to successfully update by closing LibreWolf, which from reading previous issues, I believe triggers another update check?

No, closing LW won't trigger another update check, but if WinUpdater ran successfully (without error 0x800710E0) and found an update, it will notify the user and wait until LW is closed. When closed, it will start the update process.

After this, the Last Run Result text read:

The operation completed successfully. (0x0)

Forcing a manual run from the Task Scheduler (right click -> Run) now seems to work without issue, with the updater process running and presumably silently exiting when it finds no update. I will update this issue the next time a scheduled run occurs, which won't be until tomorrow because the machine won't be in use again until then.

Thank you for making a thorough report, I'd really like to tackle this issue properly.

@vaguerant wrote in https://codeberg.org/ltguillaume/librewolf-winupdater/issues/38#issue-1038823: > I'm running the standard install (not portable) for LibreWolf with WinUpdater set to automatically check for updates. After initial setup, automated updates were not working at all on my end. I went investigating and found the LibreWolf WinUpdater task in Windows Task Scheduler, with the below error text under Last Run Result: > > > The operator or administrator has refused the request. (0x800710E0) I have seen this issue before, but I was never able to find out what caused it. It just "went away". I might have something to do with hibernation/standby, because I did see this only on a laptop. Another possible cause was that the username it was running under had an ampersand (&) in the name. Is that the case for you, too? > The account LibreWolf is running under is an administrator. LibreWolf was left running after initial install (including a period of PC hibernation). I was able to successfully update by closing LibreWolf, which from reading previous issues, I believe triggers another update check? No, closing LW won't trigger another update check, but if WinUpdater ran successfully (without error 0x800710E0) and found an update, it will notify the user and wait until LW is closed. When closed, it will start the update process. > After this, the Last Run Result text read: > > > The operation completed successfully. (0x0) > > Forcing a manual run from the Task Scheduler (right click -> Run) now seems to work without issue, with the updater process running and presumably silently exiting when it finds no update. I will update this issue the next time a scheduled run occurs, which won't be until tomorrow because the machine won't be in use again until then. Thank you for making a thorough report, I'd really like to tackle this issue properly.

vaguerant commented

2025-03-07 12:06:19 +00:00

(Migrated from codeberg.org)

Another possible cause was that the username it was running under had an ampersand (&) in the name. Is that the case for you, too?

I don't have any ampersands or other special characters in my user name, just upper and lower-case Latin letters.

No, closing LW won't trigger another update check, but if WinUpdater ran successfully (without error 0x800710E0) and found an update, it will notify the user and wait until LW is closed. When closed, it will start the update process.

That's interesting, that would seem to indicate that it was able to run successfully on a previous instance.

Nothing overly helpful to report from today. I woke the machine from hibernate at ~4 PM. The previous check (11 PM the night before) had run successfully. I initiated a run manually and Task Scheduler reported that the last run, at 4:28 PM, had failed, with the same error as earlier. The scheduled 7 PM task, however, ran without issue (0x0). At this point, I enabled the History feature in Task Scheduler (Actions sidebar, Enable All Tasks History). The 11 PM run once again ran without issue.

Hopefully, the History tab will have some useful information when or if another failed run occurs.

> Another possible cause was that the username it was running under had an ampersand (&) in the name. Is that the case for you, too? I don't have any ampersands or other special characters in my user name, just upper and lower-case Latin letters. > No, closing LW won't trigger another update check, but if WinUpdater ran successfully (without error 0x800710E0) and found an update, it will notify the user and wait until LW is closed. When closed, it will start the update process. That's interesting, that would seem to indicate that it was able to run successfully on a previous instance. --- Nothing overly helpful to report from today. I woke the machine from hibernate at ~4 PM. The previous check (11 PM the night before) had run successfully. I initiated a run manually and Task Scheduler reported that the last run, at 4:28 PM, had failed, with the same error as earlier. The scheduled 7 PM task, however, ran without issue (0x0). At this point, I enabled the History feature in Task Scheduler (Actions sidebar, Enable All Tasks History). The 11 PM run once again ran without issue. Hopefully, the History tab will have some useful information when or if another failed run occurs.

ltguillaume commented

2025-03-07 13:49:22 +00:00

(Migrated from codeberg.org)

Thanks, hope so, too, since I cannot reproduce this anymore.

Could you tell me your Windows version and build? For me, this used to happen on Windows 10 LTSC 2019.

Here's an explanation of the error that would be the ideal case (i.e. no real issue, just a warning): https://overflow.adminforge.de/questions/36281197/the-operator-or-administrator-has-refused-the-request-task-scheduler#50475409

In my case, the error message "The operator or administrator has refused the request" meant that a previous instance of the task has still been running and the task was configured to not start a new instance if it's already running (the default configuration), so the Task Scheduler refused to start a new instance when the task was triggered.

You can find that option in a select box on the task's Settings tab, under the caption "If the task is already running, then the following rule applies". The default value is "Do not start a new instance".

It's helpful to check the History tab of a task. That's where I have found out what's actually going on. There was an event "Launch request ignored, instance already running".

I figure you would be able to see that in the history as soon as it happens again.

If it's just that, I might be able to prevent this error from showing for too long (except for in the History tab) by simply enabling "Run task as soon as possible after a scheduled start is missed".

Thanks, hope so, too, since I cannot reproduce this anymore. Could you tell me your Windows version and build? For me, this used to happen on Windows 10 LTSC 2019. Here's an explanation of the error that would be the ideal case (i.e. no real issue, just a warning): https://overflow.adminforge.de/questions/36281197/the-operator-or-administrator-has-refused-the-request-task-scheduler#50475409 >In my case, the error message "The operator or administrator has refused the request" meant that a previous instance of the task has still been running and the task was configured to not start a new instance if it's already running (the default configuration), so the Task Scheduler refused to start a new instance when the task was triggered. > >You can find that option in a select box on the task's Settings tab, under the caption "If the task is already running, then the following rule applies". The default value is "Do not start a new instance". > >It's helpful to check the History tab of a task. That's where I have found out what's actually going on. There was an event "Launch request ignored, instance already running". I figure you would be able to see that in the history as soon as it happens again. If it's just that, I might be able to prevent this error from showing for too long (except for in the History tab) by simply enabling "Run task as soon as possible after a scheduled start is missed".

vaguerant commented

2025-03-13 04:51:39 +00:00

(Migrated from codeberg.org)

I'm on Windows 10 Pro 22H2.

As is tradition, the issue seems to have stopped happening as soon as we started trying to diagnose it. 🫤

I do get a Warning in the history log each time the system wakes about the previous missed schedule, but updates seem to be working as expected now. The logged warnings look like this (on wake, after being off for ~12 hours):

Level	Date and Time	Event	Task Category	Operational Code	Correlation Id
Warning	2025-03-13 2:51:03 PM	153	Missed task start rejected	Info

Going into the right click > Event Properties, there's slightly more info:

Task Scheduler did not launch task "\LibreWolf WinUpdater (Vague)" as it missed its schedule. Consider using the configuration option to start the task when available, if schedule is missed.

There was just a LibreWolf update today, which I think landed after the 3 PM check local time, so I'm currently waiting for the 7 PM check to pick it up. Will edit if anything interesting happens there, but I expect it will probably run without issue.

I'm on Windows 10 Pro 22H2. As is tradition, the issue seems to have stopped happening as soon as we started trying to diagnose it. 🫤 I do get a Warning in the history log each time the system wakes about the previous missed schedule, but updates seem to be working as expected now. The logged warnings look like this (on wake, after being off for ~12 hours): | Level | Date and Time | Event | Task Category | Operational Code | Correlation Id | | --- | --- | --- | --- | --- | --- | | Warning | 2025-03-13 2:51:03 PM | 153 | Missed task start rejected | Info | | Going into the right click > Event Properties, there's slightly more info: > Task Scheduler did not launch task "\LibreWolf WinUpdater (Vague)" as it missed its schedule. Consider using the configuration option to start the task when available, if schedule is missed. There was just a LibreWolf update today, which I think landed after the 3 PM check local time, so I'm currently waiting for the 7 PM check to pick it up. Will edit if anything interesting happens there, but I expect it will probably run without issue.

ltguillaume commented

2025-03-14 00:15:44 +00:00

(Migrated from codeberg.org)

Consider using the configuration option to start the task when available, if schedule is missed.

I've already added this to the script. If it could make sure this confusing error message won't be there for long after resuming a session, I consider it an improvement.

How did the 7PM check go?

>Consider using the configuration option to start the task when available, if schedule is missed. I've already added this to the script. If it could make sure this confusing error message won't be there for long after resuming a session, I consider it an improvement. How did the 7PM check go?

Rows
Columns

Scheduled task fails: "The operator or administrator has refused the request. (0x800710E0)" #38