Some links on this page are affiliate links: if you buy through them we may earn a commission, at no extra cost to you.
Task Scheduler’s Last Run Result 0x3 means Windows returned ERROR_PATH_NOT_FOUND: the task could not find a path it needed. The missing path may be the executable in Program/script, a file named in Add arguments, the Start in working directory, a mapped drive, or a file that the program itself opens. Correct those references, test the command outside Task Scheduler, then run the task manually and review its history and operational log.
A path that works in your desktop session can still fail when the task runs under another account, without your network mappings, or in a non-interactive session. The sequence below separates a bad path from an account, network, application, service, or task-definition problem.
As an Amazon Associate I earn from qualifying purchases.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsWhat does Task Scheduler error 0x3 mean?
0x3 is the hexadecimal form of Windows ERROR_PATH_NOT_FOUND. It is a configuration result, not a diagnosis of one particular application. Task Scheduler started the action, but Windows could not resolve a location required to launch it or to complete its first operation.
Check every location involved in the action, not only the first executable. A task can point to a valid program while an argument names a deleted input file, while the program’s working directory no longer exists, or while a script refers to a dependent file with a relative path.
Popular on Amazon
- The executable or script in Program/script.
- A file, folder, or executable named in Add arguments.
- The directory in Start in.
- A mapped drive that is not mapped in the task’s logon session.
- A local or network file opened by the script or application after launch.
Windows checks the working-directory path when a task is registered. Therefore, correcting the field and re-registering the task is important when that value was invalid.
What should I record before changing the task?
Capture the current definition before editing it. This gives you a rollback reference and preserves triggers, conditions, accounts, and arguments that are easy to lose when recreating a task.
- Open Task Scheduler and select the failing task.
- Use Action > Export and save the task as an XML file.
- Note the task’s General security setting, trigger schedule, and the exact value shown in Last Run Result.
- Open the History tab and record the latest start, action-start, and failure events.
If the task is stored on a machine that is being upgraded or repaired, keep the XML backup somewhere outside the task store. Do not edit the registry while troubleshooting a normal path error; registry changes are relevant only to specific service or corruption cases and should be backed up first.
How do I check the action that returns 0x3?
Most 0x3 cases are fixed by correcting one of the three action fields. Open the task, choose Properties, and inspect the Actions tab.
Verify Program/script
Use a fully qualified local path, such as C:WindowsSystem32WindowsPowerShellv1.0powershell.exe, rather than relying on a command that is found only through your interactive PATH. Browse to the file from the field’s Browse button, then confirm that the selected file still exists. If the application was uninstalled, moved, or changed from a 32-bit to a 64-bit location, update the action to its current installation path.
Do not put the entire command line in this field. The executable belongs in Program/script; switches and file names belong in Add arguments. Keeping those parts separate avoids quoting and parsing errors.
Check Add arguments
Read every argument as a possible path. Correct drive letters, folder names, extensions, and quotation marks. A path containing spaces must be enclosed in matching quotes, for example "C:Scriptsinput file.txt". Remove an argument that points to a file no longer used, or replace it with a location that exists for the task’s run-as account.
If an argument invokes another script or executable, verify that item independently. A valid first executable does not prevent 0x3 when a second path in the command line is missing.
Set Start in correctly
Start in is the working directory, not an optional comment. Set it to the directory containing the executable or the files it uses. Enter the directory without surrounding quotes in the field unless the interface specifically preserves them; the field should contain a directory, not a complete command.
Relative paths in a script are resolved from this working directory. If the field is blank and the script assumes a particular folder, add that folder explicitly. After changing it, re-register the task so Windows validates the new working-directory path.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Also popular on Amazon
How can I prove that each path exists?
Test the same executable and script outside the scheduler before trying another scheduled run. This separates a missing file from a scheduler-account problem.
- Open Command Prompt or PowerShell.
- Use the exact executable path from the task. In PowerShell,
Test-Path "C:Scriptsbackup.ps1"should returnTruefor an existing file. - Run the script or command with the same arguments shown in the task. For a PowerShell script, call it with the full interpreter and script path, for example
powershell.exe -NoProfile -File "C:Scriptsbackup.ps1". - Change to the intended working directory first, then run the command again. A command that works only after
cdconfirms that the task needs a correct Start in value or absolute paths.
Microsoft’s Task Scheduler guidance recommends testing a script before placing it in a task. If the command fails in the shell, repair the script, installation, or referenced files before changing scheduler settings.
Could a mapped drive be the missing path?
Yes. Drive letters mapped in your desktop session are not automatically available to a task running under another account or in a non-interactive session. A task that uses Z: may therefore return 0x3 even while the same command succeeds when you launch it manually.
Prefer a local path when the data is local. For a network resource, use a reachable UNC path such as \serversharefolder and ensure the task’s account has permission to it. Confirm that the network is available at the time the trigger runs; a UNC path is not a cure for an offline server or denied access.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
When testing, sign in or run a shell under the same identity configured on the task. This exposes differences in drive mappings, environment variables, profile folders, and network credentials.
How do I check the account and session used by the task?
A path can be valid for an administrator at the console and unavailable to the identity selected on the task’s General tab. Review the account, whether the task is set to run only when that user is logged on, and the permissions on every local and network folder involved.
- Open Properties > General and identify the account in When running the task, use the following user account.
- Compare that account’s read, execute, and folder-traversal permissions with the paths in the action and script.
- Check whether the target application is installed for that account and whether it depends on a per-user profile location.
- As a diagnostic comparison, select Run only when user is logged on, save, and test manually. If that works while the non-interactive setting fails, investigate credentials, profile access, network availability, or session-specific environment variables rather than treating the path as universally valid.
Changing this option is a diagnostic step, not a guarantee that the task is repaired. Choose the least-privileged account and the execution mode required by the task once the cause is understood.
What should I inspect after running the task manually?
Select the task and click Run. A manual run gives you a controlled test without waiting for the next trigger.
Free tools Windows power users keep installed
One-click scans. No signup required.
- Confirm the task is enabled and normally shows Ready; Microsoft notes that a task should be in Ready status to be manually or automatically triggered.
- Wait for the action to finish, then refresh the task view.
- Read Last Run Result and open History for the exact action and trigger events.
- Open Event Viewer and inspect Applications and Services Logs > Microsoft > Windows > TaskScheduler > Operational for the corresponding time.
- Compare the event’s account, action, and path with the XML export and the values in the task properties.
If the history shows the action launching but the application then reports its own missing file, the scheduler path is valid and the next repair belongs in the application or script. If the action never starts, continue checking the fields, identity, and availability described above.
How do I isolate the scheduler from the application?
Replace the complex action temporarily with a minimal command that writes a marker to a known local directory. For example, a command that creates a text file in C:WindowsTemp can show whether the task can launch anything under its configured account.
Also popular on Amazon
- Export the original task first.
- Create a temporary test action using a system executable and a fully qualified local output path.
- Run it manually and inspect the output file, History, and the Operational log.
- Restore the original action and test the script separately if the minimal command succeeds.
A successful minimal action points toward the original executable, its arguments, working directory, or a dependent file. A failing minimal action points toward the task’s identity, permissions, service state, or definition rather than the application itself.
When should I re-register or recreate the task?
Re-register the task after correcting an invalid action or working-directory value so the scheduler stores and validates the new definition. Use the exported XML as the source for a controlled repair rather than retyping a complicated task.
Recommended Free Tools
- Save the corrected properties, or edit a copy of the exported XML only if you understand each changed element.
- Use Action > Import Task to register a repaired XML as a new task, or delete and recreate the damaged definition after preserving the original export.
- Recheck the account, triggers, conditions, and actions before enabling the replacement.
- Run the replacement manually and confirm a successful history entry before waiting for its schedule.
Recreation is appropriate when the definition is corrupted, contains invalid references that cannot be saved, or became incompatible after an operating-system upgrade. It is not a substitute for fixing a missing executable or inaccessible share.
What if the path is correct but 0x3 remains?
Broaden the check to the target application and the environment in which it runs. Microsoft identifies three broad classes of scheduled-task failures: incorrect task configuration, a target application or script that is no longer available or valid, and tasks that become incompatible after an operating-system upgrade.
Application or script no longer available
Confirm that the program is still installed, that its dependent files are present, and that the account used by the task can execute it. Review changes to installation folders, removable media, profile directories, and configuration files. Run the exact command under the task’s account to distinguish an installation problem from scheduler behavior.
Upgrade-related incompatibility
If the task worked before a Windows upgrade, compare its exported XML and action paths with the current installation. Re-register or recreate the definition after backing it up, then test under the current security and logon settings.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Environment differences
Check environment variables, current directory assumptions, permissions, and network availability. Convert fragile relative references to absolute local or UNC paths where that fits the task’s design. Avoid assuming that an interactive user profile, mapped drive, or graphical session exists when the trigger runs.
How do I handle a Task Scheduler service or corruption problem?
A service-unavailable message is a different branch from an ordinary 0x3 action error. Investigate whether obsolete at tasks or corrupted task definitions are involved, and back up before making registry changes.
- Record the service error, affected task name, and time in the Operational log.
- Export unaffected tasks and the failing task before deleting or editing definitions.
- Check for obsolete
at-created tasks if the failure began after a migration or upgrade. - If one definition is corrupted, recreate that task from its XML backup instead of altering unrelated tasks.
- After any service or definition repair, confirm the task returns to Ready, run it manually, and review the new history entry.
Do not delete the entire task store to fix one failing action. A service repair or registry change can affect every scheduled task on the computer.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Which fix should I try first?
Use the symptom that best matches your case. The table keeps the decision focused on the five distinctions that matter: the missing path, execution identity, path type, behavior outside the scheduler, and an operating-system upgrade.
Also popular on Amazon
| Observed situation | Most relevant check | Reason |
|---|---|---|
| Executable, script, or working directory was moved | Correct Program/script, Add arguments, or Start in; re-register | 0x3 directly represents a path that Windows cannot find |
| Command works interactively but fails on schedule | Compare the task account, permissions, profile, environment, and logon mode | The scheduled session may not share your mappings or credentials |
| Action uses a mapped drive | Use a reachable local or UNC path and verify network availability | Drive letters can be session-specific |
| Script fails in PowerShell or Command Prompt too | Repair the script, installation, or dependent files first | The scheduler is not the original failure point |
| Failure began after a Windows upgrade | Export, compare, re-register, or recreate the task | Definitions can become incompatible after an upgrade |
| Task or service reports corruption or unavailability | Back up definitions, investigate obsolete at tasks, and recreate only affected tasks |
Service and definition faults require a separate recovery path |
How can I prevent another 0x3 result?
- Use absolute paths for executables, scripts, and important data files.
- Set Start in explicitly when a script uses relative paths.
- Prefer local or UNC paths over drive letters that exist only in an interactive session.
- Keep the task’s XML export whenever you make a major change to its action or security settings.
- After moving or upgrading an application, run the task manually and inspect History before relying on its schedule.
- Keep the task’s run-as account permissions aligned with every folder, share, and application dependency.
These practices reduce configuration drift, but they cannot make an offline network share or a deleted application available. Treat each new 0x3 result as a request to identify the exact path and execution context that changed.
If you prefer an optional shortcut after trying the manual checks, Outbyte PC Repair can look for common Windows issues, invalid redirects, shared DLL problems, and related system conditions, while its app-crash log can help organize failures. It complements antivirus software rather than replacing it; results vary, and no tool repairs every crash. It runs on Windows 11, 10, 8, and 7, with a free trial by category for at least two days before a paid subscription.
Task Scheduler 0x3 FAQ
Does 0x3 mean the scheduled application itself crashed?
No. The code specifically identifies a path-not-found condition. The application may never have launched, although the application or script can also produce the missing-path failure after it starts; History and the Operational log help distinguish those cases.
Why does the task show Ready even though Last Run Result is 0x3?
Ready describes whether the task is available to be triggered; it does not erase the result of a previous run. A task can return to Ready after a failed action, so use the latest History timestamps and event details when checking whether a new test succeeded.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOutdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchIs a UNC path always better than a mapped drive?
Not automatically. A UNC path avoids session-specific drive-letter mappings, but the server must be reachable and the task account must have access. Test the UNC location under the same identity and timing conditions as the scheduled run.
When is recreating a task safer than editing it?
Recreate it when the definition is corrupted, cannot be saved with valid references, or is incompatible after an operating-system upgrade. Export the original first and verify every trigger, condition, account, and action on the replacement before enabling it.
Frequently Asked Questions
Does 0x3 mean the scheduled application itself crashed?
No. The code identifies a path-not-found condition. The application may never have launched, although an application or script can also report a missing path after it starts; History and the Operational log distinguish those cases.
Why does the task show Ready even though Last Run Result is 0x3?
Ready indicates that the task is available to be triggered; it does not clear a previous run result. Check the newest History timestamps and event details after a fresh test.
Is a UNC path always better than a mapped drive?
Not automatically. UNC avoids session-specific drive-letter mappings, but the server must be reachable and the task account must have access. Test it under the same identity and timing as the scheduled run.
When is recreating a task safer than editing it?
Recreate a definition when it is corrupted, cannot be saved with valid references, or became incompatible after an operating-system upgrade. Export the original and verify every trigger, condition, account, and action on the replacement.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
