Windows Event Logs are one of the most valuable sources of security telemetry in a Windows environment.

When Windows Event Logs suddenly stop appearing in Wazuh, your visibility into endpoint activity drops significantly.

The Wazuh Dashboard may continue showing agent heartbeats, Syscollector inventory, or File Integrity Monitoring (FIM) events while Security, System, or Application logs disappear entirely.

This can create dangerous blind spots where attackers perform actions that go undetected.

The “Wazuh Windows Event Logs Missing” issue can occur for many reasons, including disabled event channels, incorrect agent configuration, insufficient permissions, Windows Event Log service failures, network problems, or filters that unintentionally exclude important events.

In this guide, you’ll learn how Wazuh collects Windows Event Logs, why providers or channels may appear to be missing, and how to systematically diagnose and fix the problem.

We’ll also cover validation steps and best practices to ensure Windows event collection remains reliable over time.

If your Windows agent is completely offline, start with How to Install a Wazuh Agent on Windows Server and Wazuh Agent Not Connecting to Manager? 12 Proven Fixes before troubleshooting missing logs.

How Wazuh Collects Windows Event Logs

Understanding how Windows events flow into Wazuh makes troubleshooting much easier.

Missing logs can occur at multiple stages, from Windows itself to the Wazuh agent, the manager, or the dashboard.

Windows Event Channels

Windows organizes events into channels.

Each channel stores a specific category of operating system or application events.

Common channels include:

• Security
• System
• Application
• Setup
• Microsoft-Windows-PowerShell/Operational
• Windows Defender Operational
• Sysmon Operational
• DNS Server
• Terminal Services
• Task Scheduler

Each channel contains thousands of events generated by Windows components or installed applications.

If a channel is disabled, Wazuh cannot collect events from it because Windows never exposes them through the Event Log API.

Microsoft documents the Windows Event Log architecture and channel model in its official Event Log documentation.

Event Providers vs Event Channels

Many administrators confuse providers with channels, but they are different concepts.

An event provider is the software component that generates events.

Examples include:

• Microsoft-Windows-Security-Auditing
• Microsoft-Windows-PowerShell
• Microsoft-Windows-Windows Defender
• Sysmon
• DNS Server

An event channel is where those provider-generated events are written.

For example:

A missing provider often indicates:

• the software isn’t installed
• auditing isn’t enabled
• the provider isn’t writing events
• the Wazuh agent isn’t monitoring the associated channel

How the Wazuh Agent Reads Windows Events

The Wazuh agent does not read Windows EVTX files directly.

Instead, it uses the Windows Event Log API to subscribe to configured event channels listed in ossec.conf.

A typical configuration looks like:

<localfile>
  <location>Security</location>
  <log_format>eventchannel</log_format>
</localfile>

<localfile>
  <location>System</location>
  <log_format>eventchannel</log_format>
</localfile>

Whenever Windows records a new event, the Event Log API notifies the Wazuh agent, which collects and normalizes the event before forwarding it to the manager.

This subscription model is efficient because the agent only processes new events instead of repeatedly scanning entire log files.

How Events Reach the Wazuh Manager

After collecting events, the Wazuh agent:

1. Parses the Windows event
2. Adds metadata about the agent
3. Compresses the payload
4. Encrypts the communication
5. Sends the event to the Wazuh manager

The manager then:

• decodes the event
• evaluates detection rules
• applies correlation logic
• generates alerts when appropriate
• forwards indexed data to the Wazuh Indexer

If communication between the agent and manager is interrupted, events may never reach the dashboard even though Windows logging is functioning correctly.

If you suspect communication issues, see Wazuh Agent Not Connecting to Manager? 12 Proven Fixes.

How Logs Appear in the Dashboard

Once indexed, Windows events become searchable inside the Wazuh Dashboard.

You should be able to search by fields such as:

• event.provider
• event.channel
• win.system.eventID
• agent.name
• rule.id

If the dashboard shows the agent as active but searches return no Security or System events, the problem usually exists earlier in the data pipeline.

This flow can be summarized as:

Windows Event Provider → Event Channel → Windows Event Log API → Wazuh Agent → Wazuh Manager → Wazuh Indexer → Dashboard

Knowing where events disappear allows you to isolate the root cause much faster.

Common Reasons Windows Event Logs Are Missing

Several independent issues can prevent Windows events from reaching Wazuh.

The following are the most common causes.

Wazuh Agent Is Not Running

If the Wazuh agent service is stopped or repeatedly crashing, no Windows events will be collected.

Common indicators include:

• agent marked as disconnected
• no recent heartbeats
• stale event timestamps
• service startup failures

Verify that the Wazuh service is running before investigating more complex configuration issues.

 See Why the Wazuh Windows Agent Service Starts Then Stops (And How to Fix It) for service startup troubleshooting.

Event Channels Are Not Enabled

Many Windows event channels are disabled by default.

Examples include:

• PowerShell Operational
• Sysmon Operational
• Windows Defender Operational
• DNS Server logs

If the channel isn’t enabled, Windows never generates events for Wazuh to collect.

This is particularly common after deploying Sysmon or enabling advanced auditing without activating the corresponding operational channel.

Incorrect ossec.conf Configuration

One of the most common causes is an incorrect ossec.conf.

Problems include:

• missing <localfile> entries
• incorrect channel names
• XML syntax errors
• unsupported log formats
• duplicate definitions

Even a small typo in the channel name can prevent event subscriptions from being created.

See How to Fix ossec.conf Syntax Errors in Wazuh Agents for configuration validation techniques.

Missing Permissions

The Wazuh agent must have sufficient privileges to subscribe to protected Windows event channels.

Restricted environments may block access through:

• Group Policy
• hardened endpoint configurations
• endpoint security software
• custom service account permissions

The Security log is especially sensitive because Windows protects access to authentication events.

Microsoft recommends granting only the minimum required permissions while ensuring monitoring software retains access to necessary event channels.

Windows Event Log Service Problems

The Windows Event Log service is responsible for maintaining all event channels.

If this service is:

• stopped
• corrupted
• failing
• overloaded

applications including Wazuh cannot retrieve events.

Symptoms often include:

• Event Viewer errors
• missing live events
• delayed logging
• subscription failures

Because Wazuh relies entirely on the Windows Event Log API, problems with this service affect every monitoring solution that depends on Windows events.

Event Volume Filtering

Administrators sometimes configure filters to reduce noise.

Overly aggressive filtering may unintentionally exclude:

• authentication failures
• PowerShell events
• Defender detections
• Sysmon process creation
• service installation events

Always review exclusion rules before assuming events are not being generated.

As noted by the security guidance published by the Center for Internet Security (CIS), retaining sufficient Windows logging is essential for effective threat detection and incident response.

Network Connectivity Issues

The agent may successfully collect events locally but fail to transmit them to the manager because of:

• firewall rules
• VPN interruptions
• packet loss
• TLS failures
• manager outages

In these situations, Windows logging appears healthy, but no new alerts arrive in the dashboard.

See Wazuh Agent Not Connecting to Manager? 12 Proven Fixes for detailed connectivity diagnostics.

Corrupted Agent Configuration

Unexpected shutdowns, incomplete upgrades, or manual edits can leave the agent configuration in an inconsistent state.

Corrupted configuration files may prevent:

• event subscriptions
• log forwarding
• module initialization
• agent startup

If configuration corruption is suspected, validating or rebuilding the configuration is often faster than manually troubleshooting every setting.

Unsupported or Custom Event Providers

Some enterprise applications create custom Windows Event Providers that Wazuh does not monitor automatically.

Examples include:

• proprietary business applications
• custom security software
• specialized industrial systems
• internally developed services

In these cases, you may need to:

• enable the associated event channel
• add the channel to ossec.conf
• create custom detection rules
• validate parsing using Wazuh Logtest

 If custom events are not being parsed correctly, see Custom Decoder Isn’t Matching: Wazuh Logtest Deep Dive andHow to Create Custom Detection Rules in Wazuh (With Examples).

Step 5: Verify Event Providers

If the required Windows Event Channels are enabled but events are still missing, the next step is to verify that the underlying event providers are functioning correctly.

A provider that isn’t registered or isn’t generating events leaves Wazuh with nothing to collect.

List Available Event Providers

Windows includes hundreds of built-in event providers, while additional software such as Sysmon, Microsoft Defender, SQL Server, and Hyper-V installs its own providers.

To list registered providers, open PowerShell as Administrator and run:

Get-WinEvent -ListProvider *

To search for a specific provider:

Get-WinEvent -ListProvider "Microsoft-Windows-Security-Auditing"

Or, for Sysmon:

Get-WinEvent -ListProvider "Microsoft-Windows-Sysmon"

If the expected provider does not appear, the associated Windows feature or application may not be installed correctly.

Confirm Provider Registration

After locating the provider, verify that it is properly registered.

PowerShell displays information such as:

• Provider name
• Supported event levels
• Keywords
• Linked event channels
• Supported event IDs

For example:

(Get-WinEvent -ListProvider "Microsoft-Windows-PowerShell").LogLinks

This confirms which Event Channels the provider writes to.

If the provider isn’t linked to the expected channel, review the application’s installation or configuration.

Check Provider Health

A registered provider can still fail to generate events.

Common causes include:

• Disabled Windows auditing
• Application misconfiguration
• Corrupted software installation
• Disabled Windows features
• Failed services

For example, if Sysmon is installed but its service isn’t running, its provider will stop producing new events.

Likewise, PowerShell Operational logs remain empty unless PowerShell logging has been enabled.

Validate Provider Event Generation

The final validation step is confirming that the provider is actively writing events.

Generate an action that should trigger an event.

Examples include:

• Log into Windows (Security provider)
• Run a PowerShell command (PowerShell provider)
• Start or stop a Windows service
• Launch an application monitored by Sysmon

Then check Event Viewer to verify that new events appear.

If Event Viewer doesn’t receive new events, Wazuh cannot collect them.

If you’re troubleshooting Security or PowerShell events specifically, see How to Monitor Windows Event Logs Using Wazuh.

Step 6: Test Windows Event Collection

Rather than waiting for normal system activity, intentionally generate events and verify they travel through the entire Wazuh pipeline.

This helps determine exactly where events stop flowing.

Generate Test Security Events

The easiest test is creating authentication activity.

Examples include:

• Lock and unlock the workstation
• Sign out and sign back in
• Attempt an incorrect password
• Log in using Remote Desktop (if available)

These actions should generate Security log events such as:

• Successful logon
• Failed logon
• Logoff
• Session unlock

After generating the activity, verify that the Security log contains the corresponding events.

Generate Application Events

Open several applications or services that normally produce Application log entries.

You can also manually create an Application event using PowerShell if event sources are configured.

The goal is simply to confirm that the Application channel is actively recording new entries.

Generate System Events

System events occur frequently.

Examples include:

• Starting or stopping a Windows service
• Connecting or disconnecting hardware
• Restarting Windows
• Updating a device driver

These actions should create entries within the System log almost immediately.

Verify Events Appear in Event Viewer

Before checking Wazuh, always verify that Windows itself recorded the event.

Open Event Viewer and confirm:

• The expected channel contains the event.
• The timestamp matches your test.
• The Event ID is correct.
• The provider is the one you expected.

If the event isn’t present here, the issue exists within Windows, not Wazuh.

Compare with Wazuh Dashboard

Once the event is visible in Event Viewer:

1. Wait one or two minutes.
2. Open the Wazuh Dashboard.
3. Search for the event using:
   • Event ID
   • Agent name
   • Provider
   • Time range

If the event exists locally but not in Wazuh, you’ve narrowed the issue to event collection, transmission, indexing, or filtering.

Step 7: Review Agent Logs

The Wazuh agent log often provides the fastest explanation for why Windows Event Logs are missing.

Errors related to subscriptions, permissions, parsing, or connectivity are usually recorded here.

Locate ossec.log

On Windows, the primary agent log is typically located at:

C:\Program Files (x86)\ossec-agent\logs\ossec.log

or

C:\Program Files\ossec-agent\logs\ossec.log

Open the log using a text editor or PowerShell:

Get-Content "C:\Program Files (x86)\ossec-agent\logs\ossec.log" -Tail 100

Review the most recent entries after restarting the agent.

Search for Eventchannel Errors

Look for messages containing keywords such as:

• eventchannel
• eventlog
• subscription
• WinEvt
• channel

Examples include:

• Failed to subscribe to channel
• Cannot open event channel
• Invalid channel name
• Failed reading Windows events

These messages often point directly to the problematic configuration.

Identify Parsing Errors

If events are collected but cannot be interpreted correctly, parsing errors may appear.

Examples include:

• Invalid XML
• Unsupported event format
• Malformed event
• Decoder errors

Although parsing problems are less common with standard Windows logs, they can occur with custom providers or third-party software.

Detect Access Denied Messages

Permission-related problems typically generate messages such as:

• Access denied
• Permission denied
• Unauthorized
• Failed opening Security log

These errors usually indicate the Wazuh service lacks sufficient privileges to subscribe to protected event channels.

Microsoft recommends ensuring monitoring software has the necessary rights to read the Security log while following the principle of least privilege.

Verify Successful Event Collection

Healthy agent logs typically show ongoing event collection without repeated errors.

Look for evidence that:

• Channels were successfully subscribed.
• Events are being processed.
• Data is being forwarded to the manager.
• No recurring Eventchannel errors appear.

If the log remains clean while events are still missing, continue investigating permissions and filtering.

Step 8: Verify Permissions

Windows protects many Event Channels, especially the Security logfrom unauthorized access.

Incorrect permissions can prevent the Wazuh agent from reading events even when everything else is configured correctly.

Run the Agent with Appropriate Privileges

By default, the Wazuh Agent service runs under the Local System account.

Verify the configured service account:

1. Open Services.
2. Right-click Wazuh Agent.
3. Select Properties.
4. Open the Log On tab.

Running under a less privileged account may prevent access to protected event channels.

Verify Access to Security Logs

Test whether the account can actually read the Security log.

From an elevated PowerShell session:

Get-WinEvent -LogName Security -MaxEvents 5

If this command returns access-related errors, Windows permissions should be corrected before continuing.

Check Local Security Policies

Review any Local Security Policy or Group Policy settings that may restrict access to Windows Event Logs.

Pay particular attention to:

• User Rights Assignment
• Event Log permissions
• Security Options
• Audit Policy configuration

Organizations with hardened security baselines sometimes unintentionally block monitoring agents.

Validate Service Account Permissions

If the Wazuh Agent runs under a custom service account:

Verify that it has permission to:

• Read Event Logs
• Access protected Windows APIs
• Read Security events
• Communicate with the Wazuh manager

After updating permissions, restart the Wazuh Agent and repeat your event collection tests.

Step 9: Check Event Filtering Rules

Even when events are collected successfully, filtering rules may prevent them from being forwarded to the manager.

Review any filters that intentionally reduce event volume.

Review Query Filters

Some configurations use Windows Event Log queries to collect only specific events.

Examples include:

• Only Security events
• Specific Event IDs
• Particular providers
• Selected severity levels

Carefully review these queries to ensure they don’t unintentionally exclude required events.

Check XPath Filters

Wazuh supports XPath expressions for filtering Windows Event Logs.

Although powerful, XPath filters can accidentally remove large portions of the event stream.

For example, a filter targeting only successful logons will ignore all failed authentication attempts.

Verify that each XPath expression matches the events you actually want to collect.

Microsoft provides detailed guidance on constructing valid Windows Event Log XPath queries.

Verify Ignore Rules

Review any rules that intentionally ignore:

• Event IDs
• Providers
• Keywords
• Channels
• Severity levels

Older configurations often contain legacy exclusions that are no longer appropriate.

Document every ignore rule before making changes.

Remove Overly Restrictive Filters

If troubleshooting is inconclusive, temporarily simplify the configuration.

Remove or comment out restrictive filters so that Wazuh collects all events from the affected channel.

This approach helps determine whether filtering is responsible for the missing logs.

Once event collection is working again, reintroduce filters gradually until the problematic rule is identified.

Test Without Filters

After disabling filters:

1. Restart the Wazuh Agent.
2. Generate several test events.
3. Confirm they appear in Event Viewer.
4. Verify they reach the Wazuh Dashboard.

If events now appear successfully, one or more filters was excluding them.

Re-enable filters individually until the offending rule is found.

If you need to validate how Wazuh processes collected events after filtering, see How to Test Wazuh Rules and How to Create Custom Detection Rules in Wazuh (With Examples).

Step 10: Verify Communication with the Wazuh Manager

If Windows is successfully generating events and the Wazuh agent is collecting them, the next step is to verify that the events are reaching the Wazuh manager.

Communication failures can prevent logs from ever being analyzed or indexed.

Confirm Agent Connectivity

Begin by confirming that the agent maintains an active connection to the manager.

From the Wazuh Dashboard:

Agents → Select the affected agent

Verify:

• Status is Active
• Recent Last Keep Alive
• No communication errors
• Correct manager assignment

If the agent repeatedly disconnects, Windows Event Logs may accumulate locally without being forwarded.

 See Wazuh Agent Not Connecting to Manager? 12 Proven Fixes for a comprehensive communication troubleshooting guide.

Check Agent Registration

An agent that has not been properly registered cannot send events.

On the manager, verify that the agent appears in the registered agent list:

/var/ossec/bin/agent_control -l

Confirm that:

• The agent ID is correct.
• The hostname matches the endpoint.
• The agent status is Active.

If duplicate agent IDs or conflicting registrations exist, remove the obsolete registration and register the endpoint again.

 See Resolving Duplicate Name or IP Errors in Wazuh Agent Registration for registration-related issues.

Verify Port Connectivity

The agent must be able to communicate with the manager over the configured communication port (typically 1514/TCP).

From the Windows endpoint, test connectivity:

Test-NetConnection <Wazuh_Manager_IP> -Port 1514

Verify:

• TCP connection succeeds
• No firewall blocks the traffic
• VPN tunnels are functioning
• NAT rules are configured correctly (if applicable)

If connectivity fails, resolve the networking issue before continuing.

Review Manager Logs

If the agent is connected but events still do not appear, inspect the manager logs.

Typical locations include:

/var/ossec/logs/ossec.log

Look for messages related to:

• Agent communication
• Authentication failures
• Queue overflows
• Event processing
• Decoder errors
• Dropped events

Healthy logs should show the manager continuously receiving messages from the Windows agent.

Confirm Event Delivery

Generate a fresh Windows Security event and immediately monitor the manager log.

A successful workflow should be:

1. Event generated on Windows.
2. Agent collects the event.
3. Manager receives the event.
4. Decoder processes it.
5. Alert is indexed.

If the manager receives the event but it never appears in the Dashboard, the issue likely lies within indexing rather than event collection.

Step 11: Validate Dashboard Indexing

Sometimes Windows events successfully reach the manager but never appear in searches because of indexing or dashboard-related issues.

Confirm Events Reach the Indexer

Verify that the Wazuh manager is successfully forwarding events to the Wazuh Indexer.

Common indicators include:

• No indexing errors in manager logs
• Healthy Filebeat service
• Active communication with the Indexer
• Growing alert indices

If indexing has stopped, newly collected events won’t be searchable.

Verify Index Health

Check the health of your Wazuh indices.

A healthy cluster should report:

• Green status (preferred)
• Yellow status (acceptable for single-node deployments)
• Active primary shards
• No unassigned shards

If the cluster is unhealthy, indexing delays or missing events may occur.

See How to Fix a Yellow Cluster Status in Wazuh Indexer and How to Build a Wazuh Indexer Cluster.

Search for Recent Windows Events

Use broad searches before assuming the events are missing.

Try searching by:

• Agent name
• Event ID
• Provider
• Channel
• Hostname

Avoid overly restrictive search filters.

If necessary, search only the last few minutes after generating a fresh test event.

Check Time Range Filters

One of the most overlooked causes of “missing” events is an incorrect Dashboard time filter.

Verify that:

• The selected time range includes your test event.
• The system clocks are synchronized.
• Windows and the Wazuh server use the correct time zone.
• NTP is functioning correctly.

Incorrect timestamps can make events appear to disappear when they are simply outside the selected search window.

Refresh Index Patterns

If newly indexed fields are unavailable, refresh the Dashboard index patterns.

Refreshing allows the Dashboard to recognize:

• New event fields
• Newly indexed providers
• Additional Windows Event Log attributes

This is especially helpful after upgrading Wazuh or enabling new Windows Event Channels.

If Dashboard indexing appears inconsistent, see Troubleshooting “No Matching Indices Found” Error in Wazuh Dashboard.

Step 12: Restart the Collection Pipeline

If every previous step checks out but Windows events are still missing, restart the complete collection pipeline.

Temporary synchronization issues are sometimes resolved by restarting the relevant services in the proper order.

Restart the Wazuh Agent

Begin with the Windows endpoint.

Restart the agent:

Restart-Service Wazuh

Or:

net stop Wazuh
net start Wazuh

Allow the agent several minutes to reconnect before generating another test event.

Restart the Manager

If restarting the agent does not resolve the issue, restart the Wazuh manager.

On Linux:

sudo systemctl restart wazuh-manager

After restarting, verify:

• Manager starts successfully.
• Agents reconnect automatically.
• No startup errors appear in ossec.log.

Monitor the logs for new Windows events arriving immediately after the restart.

Restart the Indexer (If Necessary)

Restart the Wazuh Indexer only if you suspect indexing issues.

Typical command:

sudo systemctl restart wazuh-indexer

Allow sufficient time for:

• Cluster recovery
• Shard allocation
• Index synchronization

Avoid restarting the Indexer unnecessarily in production environments unless maintenance windows are available.

Verify Event Flow After Restart

Generate several fresh Windows events and verify they successfully complete the full pipeline:

1. Event appears in Event Viewer.
2. Agent collects the event.
3. Manager receives the event.
4. Indexer stores the event.
5. Dashboard displays the event.

If all stages succeed, Windows Event Log collection has been restored.

Troubleshooting Specific Error Messages

Certain error messages immediately point to specific configuration or environmental problems.

The following are among the most common messages encountered when Windows Event Logs fail to appear in Wazuh.

“Unable to Open Event Channel”

This error usually indicates that Wazuh cannot subscribe to the configured Windows Event Channel.

Common causes include:

• Incorrect channel name
• Disabled Event Channel
• Insufficient permissions
• Corrupted Event Log configuration

Verify that the channel exists in Event Viewer and that its name exactly matches the value specified in ossec.conf.

“Access Is Denied”

This message almost always indicates a permissions problem.

Possible causes include:

• Wazuh Agent running under an account with insufficient privileges
• Restricted Security log access
• Group Policy restrictions
• Hardened Windows security settings

Verify that the service account has permission to read protected Event Channels, particularly the Security log.

Microsoft recommends following the principle of least privilege while ensuring monitoring software retains the permissions required for event collection.

“The Specified Channel Could Not Be Found”

This error typically occurs when:

• The channel name is misspelled.
• The provider isn’t installed.
• The associated Windows feature is disabled.
• The application creating the channel has been removed.

Copy channel names directly from Event Viewer instead of entering them manually.

“Eventchannel Module Failed”

An Eventchannel module failure often points to configuration or initialization problems.

Common causes include:

• Invalid XML syntax
• Unsupported channel names
• Corrupted ossec.conf
• Agent startup failures

Review both the agent log and the configuration file for detailed error messages.

See How to Fix ossec.conf Syntax Errors in Wazuh Agents for configuration troubleshooting.

“No Windows Events Received”

If Windows events are not reaching Wazuh at all, systematically verify each stage of the collection pipeline:

• Windows is generating events.
• Event Channels are enabled.
• Providers are functioning.
• Wazuh Agent is collecting events.
• Manager is receiving events.
• Indexer is storing events.
• Dashboard is displaying them.

Following the troubleshooting steps in this guide usually isolates the exact point where event collection stops.

“Provider Not Registered”

This error indicates that Windows cannot locate the requested Event Provider.

Possible causes include:

• Application not installed
• Provider registration failure
• Damaged installation
• Incorrect provider name
• Windows component corruption

Reinstall or repair the affected application, then verify the provider appears when running:

Get-WinEvent -ListProvider *

If the provider registers successfully and begins generating events, restart the Wazuh agent and confirm that the events appear in the Dashboard.

If custom providers require additional parsing, see Custom Decoder Isn’t Matching: Wazuh Logtest Deep Dive and How to Create Custom Detection Rules in Wazuh (With Examples).

Troubleshooting Checklist

If you’re still unable to collect Windows Event Logs in Wazuh, use the following checklist to systematically verify each component of the collection pipeline.

Confirm the Wazuh Agent Is Running

Before troubleshooting configuration files or Windows services, ensure the Wazuh agent is operational.

Verify that:

• The Wazuh Agent service is running.
• The agent status is Active in the Wazuh Dashboard.
• No startup or crash errors appear in ossec.log.
• The agent reconnects successfully after a restart.

If the agent cannot communicate with the manager, Windows events will never leave the endpoint.

Verify Windows Event Log Service

Confirm that the Windows Event Log service is:

• Running
• Configured for Automatic startup
• Free from errors in Event Viewer
• Able to generate new events

If Windows itself is not recording events, Wazuh cannot collect them.

Check Event Channels

Verify that every required Event Channel is enabled, including:

• Security
• System
• Application
• Microsoft-Windows-PowerShell/Operational
• Microsoft-Windows-Sysmon/Operational
• Windows Defender Operational

Generate a few test events and confirm they appear in Event Viewer before checking Wazuh.

Validate ossec.conf Configuration

Review the agent configuration to ensure:

• Correct <localfile> entries exist.
• Channel names are accurate.
• <log_format> is set to eventchannel.
• XML syntax is valid.
• No duplicate or conflicting entries exist.

Even a small configuration error can prevent event subscriptions.

Confirm Event Providers Exist

Verify that the required Event Providers are:

• Installed
• Registered
• Associated with the expected Event Channels
• Actively generating events

A missing provider often indicates an application installation or configuration problem rather than a Wazuh issue.

Review Agent Logs

Inspect ossec.log for messages involving:

• Eventchannel
• Windows Event Log
• Subscription failures
• Access denied
• XML parsing errors
• Communication failures

Agent logs frequently identify the exact cause of missing events.

Verify Permissions

Ensure the Wazuh Agent has permission to:

• Read protected Event Channels
• Access the Security log
• Subscribe to Windows Event Log APIs
• Communicate with the manager

If a custom service account is used, verify its assigned privileges.

Test Event Generation

Generate fresh Windows events rather than relying on historical data.

Examples include:

• Successful logon
• Failed logon
• Starting or stopping a service
• Executing a PowerShell command

Confirm that:

1. The event appears in Event Viewer.
2. The Wazuh agent processes it.
3. The manager receives it.
4. The Dashboard displays it.

Confirm Manager Connectivity

Verify that:

• The agent is registered.
• Port 1514/TCP is reachable.
• No firewall blocks communication.
• The manager receives incoming events.
• No queue or decoding errors exist.

Verify Dashboard Indexing

Finally, ensure the indexing layer is functioning properly.

Confirm:

• The Wazuh Indexer is healthy.
• Alert indices are updating.
• Time filters are correct.
• Searches include the latest events.
• Index patterns have been refreshed when necessary.

Working through this checklist in order usually identifies the exact point where Windows Event Logs stop flowing.

Best Practices to Prevent Missing Windows Event Logs

Many Windows Event Log issues can be prevented through routine monitoring and periodic configuration reviews.

The following best practices help maintain reliable log collection over time.

Monitor Agent Health Continuously

Configure monitoring to detect:

• Disconnected agents
• Missed heartbeats
• High resource usage
• Repeated service restarts
• Communication failures

Early detection prevents prolonged visibility gaps.

See Why Is Wazuh Using High CPU? Troubleshooting Guide if resource utilization begins affecting agent stability.

Audit Event Channel Configuration

Review monitored Event Channels periodically.

Confirm that:

• Required channels remain enabled.
• Newly deployed applications have their channels added.
• Legacy channels are removed when no longer needed.
• Audit policies continue generating the desired events.

Configuration drift is a common cause of missing logs.

Keep Windows Updated

Windows updates frequently include improvements and fixes for:

• Event Logging
• Event Providers
• Windows APIs
• Security Auditing
• Reliability

Keeping systems current reduces compatibility issues between Windows and monitoring software.

Microsoft recommends applying security and quality updates regularly to maintain logging reliability.

Monitor Agent Logs Regularly

Review agent logs as part of routine maintenance.

Look for recurring:

• Eventchannel warnings
• Subscription failures
• Permission errors
• Network issues
• Parsing failures

Resolving small issues early helps prevent larger monitoring gaps.

Validate Event Collection After Configuration Changes

Any modification to:

• ossec.conf
• Windows Audit Policy
• Group Policy
• Event Channels
• Security software

should be followed by validation testing.

Generate test events immediately after making changes to ensure collection still functions correctly.

Test Custom Event Providers Before Production

If your organization uses custom applications that register their own Event Providers:

• Test in a staging environment first.
• Verify provider registration.
• Confirm events appear in Event Viewer.
• Ensure Wazuh successfully collects them.
• Create custom rules where necessary.

This minimizes unexpected production issues.

Document Event Collection Policies

Maintain documentation covering:

• Monitored Event Channels
• Custom providers
• Agent configurations
• Filtering rules
• Audit policies
• Troubleshooting procedures

Well-maintained documentation makes future troubleshooting significantly faster, especially in larger environments with multiple administrators.

Frequently Asked Questions (FAQ)

Question: Why are Windows Event Logs missing in Wazuh?

Missing Windows Event Logs are typically caused by one or more of the following:

• Wazuh Agent is not running
• Windows Event Log service has failed
• Event Channels are disabled
• Incorrect ossec.conf configuration
• Missing permissions
• Event filtering rules
• Network communication issues
• Indexing problems

Following the troubleshooting process in this guide helps isolate the exact point where the events stop.

Question: How do I verify that Wazuh is collecting Windows Event Logs?

The simplest approach is to:

1. Generate a new Windows event.
2. Confirm it appears in Event Viewer.
3. Verify the Wazuh agent receives it.
4. Search for the event in the Wazuh Dashboard.

This validates the complete collection pipeline from Windows to Wazuh.

Question: What is the difference between an Event Provider and an Event Channel?

An Event Provider is the software component that generates events.

Examples include:

• Microsoft-Windows-Security-Auditing
• Microsoft-Windows-PowerShell
• Sysmon

An Event Channel is the destination where those events are stored.

Examples include:

• Security
• System
• Application
• Microsoft-Windows-PowerShell/Operational

Wazuh subscribes to Event Channels rather than directly monitoring providers.

Question: Why is only the Security log missing?

The Security log has stricter access controls than most other Windows logs.

Common causes include:

• Insufficient service permissions
• Disabled auditing
• Group Policy restrictions
• Incorrect channel configuration

Verify both Windows Audit Policy and the Wazuh Agent’s permissions.

Question: Can Wazuh collect custom Windows Event channels?

Yes.

Any Event Channel that Windows exposes through the Windows Event Log API can generally be monitored by adding the appropriate <localfile> configuration using the eventchannel log format.

Custom detection rules may also be required depending on the application’s event structure.

Question: Do I need administrator privileges to collect Windows Event Logs?

In most environments, the Wazuh Agent runs under the Local System account, which provides the permissions required to access protected Event Channels.

If the agent runs under a custom service account, additional permissions may need to be granted to read the Security log and other restricted channels.

Question: Why do events appear in Event Viewer but not in Wazuh?

This usually indicates that Windows is generating events successfully, but the issue exists later in the pipeline.

Possible causes include:

• Incorrect ossec.conf
• Event filtering
• Agent communication failures
• Manager processing errors
• Indexing failures
• Dashboard search filters

Verify each stage individually until the missing events are located.

Question: How can I test whether event collection is working?

A simple test consists of:

1. Logging into Windows.
2. Confirming the event appears in Event Viewer.
3. Waiting one or two minutes.
4. Searching for the corresponding event in the Wazuh Dashboard.

If the event appears in both locations, the collection pipeline is functioning correctly.

Conclusion

Missing Windows Event Logs can significantly reduce your organization’s visibility into authentication activity, system changes, application behavior, and other critical security events.

While the problem may initially appear to be a Wazuh issue, the root cause often lies elsewhere such as disabled Event Channels, incorrect ossec.conf settings, insufficient permissions, communication failures, or indexing problems.

The most effective way to troubleshoot these issues is to validate each stage of the event collection pipeline in sequence.

Start by confirming that Windows is generating events in Event Viewer, verify that the Wazuh agent can subscribe to the appropriate Event Channels, ensure events reach the Wazuh manager, and finally confirm that they are indexed and searchable in the Wazuh Dashboard.

This structured approach helps isolate the failure point quickly and avoids unnecessary configuration changes.

Finally, proactive maintenance is the best defense against future log collection issues.

Continuously monitor agent health, review Event Channel and audit policy configurations after system changes, test new Event Providers before deploying them to production, and regularly inspect agent logs for early warning signs.

These best practices help ensure that Windows Event Logs remain a reliable source of security telemetry, allowing Wazuh to provide accurate detection, alerting, and incident response across your Windows infrastructure.