Introductiom

The Zabbix Agent 2 service on a Windows server was repeatedly becoming unresponsive and eventually crashing. The issue caused intermittent monitoring interruptions and required further investigation through Event Viewer messages and Zabbix Agent 2 logs to better understand why the service was no longer responding properly.

While monitoring a Windows server with Zabbix Agent 2, we encountered repeated crashes of the agent service accompanied by the following Event Viewer message:

A timeout (30000 milliseconds) was reached while waiting for a transaction response from the Zabbix Agent 2 service.

A few moments later, Windows reported:

The Zabbix Agent 2 service terminated unexpectedly.

Initial Hypothesis

The first assumption was that a plugin or item was taking too long to execute, causing the agent to become unresponsive. A natural idea was therefore to increase the timeout value. Here the official documentation for the PluginTimout.

Inside the Zabbix Agent 2 configuration, we identified the following parameter:

### Option:PluginTimeout
# Timeout for connections with external plugins.
## Mandatory: no
# Range: 1-30
# Default: <Global timeout>
# PluginTimeout=

However, this parameter only supports values between 1 and 30 seconds.

This raised an important question:

If a timeout already exists, why does the entire agent still become blocked and eventually crash?

Understanding the Problem

Zabbix Agent 2 uses a plugin-based architecture written in Go.
Unlike isolated external processes, many plugins run inside the same agent process.

This means that if a plugin becomes blocked:

• worker threads remain occupied
• new requests start queuing
• the agent gradually stops responding
• Windows eventually considers the service frozen

The 30-second timeout seen in Event Viewer is actually the Windows Service Control Manager (SCM) timeout, not a protection mechanism for the plugin itself.

In other words:

• the plugin blocks first
• the agent becomes unresponsive
• Windows waits 30 seconds
• Windows kills the service

Investigating the Logs

The Zabbix Agent 2 logs quickly pointed toward the real culprit.

[WindowsPerfMon] failed to get performance counters data:'cannot collect value No data to return.'

This indicated that the agent was struggling to collect Windows Performance Counters.

The most important recurring message was:

[WindowsPerfInstance] Cannot refresh object cache:Unable to connect to the specified computer or the computer is offline.

This error appeared continuously for several days.

The key observation here is that the agent was running locally, so the message below should never normally appear:

Unable to connect to the specified computer

This strongly suggested:

• an invalid or corrupted performance counter
• a problematic PerfMon object
• or a failing wildcard instance (Process(*), LogicalDisk(*), etc.)

Agent Becoming Non-Responsive

Later in the logs, additional symptoms appeared:

failed to accept an incoming connection:accept tcp [::]:10050:acceptex: The I/O operation has been aborted because of either a thread exit or an application request.

At this stage, the agent was no longer able to accept incoming connections because its internal workers were saturated or blocked.

This confirmed that the issue was not a traditional crash, but rather a thread starvation / blocking situation.

Why the Existing 30s Timeout Was Not Enough

An important misunderstanding was clarified during the investigation.

The default timeout value of 30 seconds does not immediately protect the agent.

Instead:

• the plugin may block for the full 30 seconds
• multiple blocked requests accumulate
• worker threads remain occupied
• the agent becomes globally unresponsive

By the time Windows notices the issue, the agent is already effectively frozen.

The Solution: Reduce PluginTimeout

Instead of increasing the timeout, the correct approach was to reduce it significantly.

The following configuration was applied:

PluginTimeout=15

This acts as a protection mechanism inside the agent itself.

With this configuration:

• problematic plugin executions are aborted quickly
• blocked threads are released faster
• the agent remains responsive
• only the affected items temporarily fail

Conclusion

The issue was not caused by the timeout itself.

The real root cause was a problematic WindowsPerfInstance plugin execution blocking the Zabbix Agent 2 internal workers.

Reducing the plugin timeout from 30 seconds to 15 seconds prevented the entire agent from becoming unresponsive while still allowing the monitoring system to recover automatically when the plugin started responding again.

This is a good example of why increasing timeouts is not always the right solution. Sometimes, shorter timeouts are actually what keeps a monitoring agent stable.

You can find other blogs regarding Zabbix or database administration or other topics at this link: dbi blogs