How to Troubleshoot Windows Task Scheduler Using Windows Server Log Files
Troubleshoot your Windows Task Scheduler in minutes.
Join the DZone community and get the full member experience.
Join For FreeIf you are responsible for managing your organization’s Windows servers, simply monitoring and managing your machines is a full-time job.
Tools such as the Windows Task Scheduler help you keep your servers up and running by automating tasks.
These tasks can be scheduled to run at set times or when triggered by system events. As much as you rely on the Scheduler, it can sometimes let you down, and often at the worst possible time.
Follow the next steps or download XpoLog7 free and troubleshoot your scheduled tasks automatically.
Getting Started
When a single task, running on a local machine, fails, you can fix it without breaking a sweat. In large organizations, tasks are far more complex and run across hundreds or thousands of remote hosts.
The Good News
Windows server gives you comprehensive logging tools to locate and fix issues.
Even with these tools – do you know which logs are available, and what are they telling you?
In this article, you get a complete guide to troubleshooting Windows Server scheduled tasks with log files. The article explains:
- How events are scheduled
- What information is logged
- Where it is stored
- How to get through common troubleshooting scenarios
You will get the answers you need and understand how to make sense of the data that Windows event logging gives you.
We start by giving you a detailed overview of Scheduled Tasks. Next, we set out a practical step-by-step troubleshooting guide.
We will also show you how you can set it up in less than 5 minutes with automation.
Cutting to the chase: After reading this article, you will be able to proactively identify Windows Task Scheduler issues, as well as use Windows events logs and related data to resolve real-world issues.
Windows Tasks Scheduler: Understanding Scheduled Tasks
A Windows Task is a group of actions that automate system management and maintenance procedures such as installing patches, auditing, backing up storage media, or dealing with security issues.
You create and schedule tasks using the Task Scheduler user interface or programmatically using PowerShell or the .NET framework.
Once you have created a task, you use the Task Scheduler Service to schedule the task’s execution.
The Task Scheduler Service is a Windows service that lets you manage, schedule, and monitor tasks.
Each task includes the following components:
- General Information: Metadata that describes the task, such as the task’s name, description, and location.
- Triggers: Conditions that schedule task execution at a specific time, or in response to specific criteria.
- Actions: List of one or more actions to achieve the tasks' desired outcome.
- Security Principals: Defines security credentials, permitted access levels, and system privileges required for task execution.
- Conditions: Determines when a task can run, i.e only running when the targeted host is idle or connected to power.
- Settings: Configures how the tasks run, including when to restart a failed action and how long the task is permitted to run.
- History: Logs task execution data.
Windows Task Scheduler – Troubleshooting Scheduled Events
Let’s look at what happens when a scheduled task fails to run and see how we can use event logs to locate and fix the problem.
Step 1: Understanding the Big Picture
To find the immediate reason why a task failed open the Event Viewer and locate the event.
- Double-clicking the event opens a dialog box that tells us the immediate cause of the problem. It provides the event’s source, ID, level, and category.
- The dialog also tells us when the event was recorded and on which machine it occurred.
Task Scheduler did not launch the task “\Microsoft\Windows\MemoryDiagnostic\ProcessMemoryDiagnosticEvents” because instance “{92e4bd81-96af-4a12-987f-3e83d80dd116}” of the same task is already running.
Log Name: Microsoft-Windows-TaskScheduler/Operational
Source: Microsoft-Windows-TaskScheduler
Date: 10/28/2018 1:21:28 PM
Event ID: 322
Task Category: Launch request ignored, instance already running
Level: Warning
Keywords:
User: SYSTEM
Computer: BILBO.mordor.local
Step 2: Diving Deeper
For detailed contextual information to help understand why an event occurred, you can use the related events logged by Windows across multiple Windows Event Log (evtx) files.
The log’s System section presents a summary of this additional environmental data that helps you resolve the problem, such as the task’s Process ID, the thread on which it ran, and its Security ID.
Guid=”{DE7B24EA-73C8-4A09-985D-5BDADCFA9017}” />
322
0
3
322
0
0x8000000000000000
200241
Microsoft-Windows-TaskScheduler/Operational
BILBO.mordor.local
Step 3: Comprehending Event Context
To understand the actual nature of the event and to get contextual clues, you need to look at the log file’sEventData
section.
Here, we can see that part of the reason that the task failed to run is related to a memory issue.
\Microsoft\Windows\MemoryDiagnostic\ProcessMemoryDiagnosticEvents
{92E4BD81-96AF-4A12-987F-3E83D80DD116}
Step 4: Get the Full Picture by Investigating Related Logs
In most cases, investigating a single log file by itself is not enough to find and fix a specific problem.
Since many scheduling issues are security related, a good place to start is to examine security-related audit logs, such as the Windows Security Event log.
Privileges: SeTcbPrivilege
Audit Failure 10/28/2018 13:21:28 BILBO MORDOR Microsoft-Windows-Security-Auditing 13056 4673 — a privileged service was called Privilege
Use Sensitive Privilege Use/Non-Sensitive Privilege Use 0x00000000000D10EB
BILBO.mordor.local A privileged service was called.
In this case, the Windows Security Event shows us that the reason the task failed was related to a broader security issue, the log tells us that the event tried to perform an action which required SeTcbPrivilege level privileges.
The action performed by the task was assigned a lower privilege level, therefore, the host on which the task was scheduled to run, prevented it from running.
In addition to showing that the task failed due to the tasks assigned privileges, it also shows information that indicates the root cause of the problem.
Process:
Process ID: 0x0000000000000EBC
Process Name: C:\Windows\System32\taskhostw.exe
Here, we can see that the security log indicates that the problem was caused by an executable process called taskhostw.exe.
The log shows us the executable’s Process ID and the process’s full path.
In the final step, we will understand why this information is important and how we can use it.
Step 5: Research the Problem
Now that we know the origin of the problem, let’s use our available resources to find out more about it.
By searching the Internet, we can see logs that identify a problem with taskhostw.exe. Problems with this process are usually related to malware exploits or a defective Windows component, which controls folder access.
For more information on taskhostw.exe and related issues, see this article from Microsoft.
Conclusions: How to Get the Most From Windows Server Logging?
Windows Scheduler Tasks are a great way to get things done.
In this article, we showed you what tasks are and how they work. We also took you through a five-step process according to the following steps:
- Understanding the big picture: how to use the Event Viewer to discover problems.
- Diving deeper: how to read an event log file to learn more.
- Comprehending event context: using Event Data to understand the problem’s context.
- Getting the full picture: using other log files to locate the root cause.
- Researching the problem: how to use the data you gathered to find a viable solution.
Now, you can deal with complex situations involving multiple servers and large amounts of logged data to ensure that:
- Your system continues to fulfill your organization’s mission
- The user’s you support can do their work.
Published at DZone with permission of tal lior. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments