Affected item keys (examples)
 
{{perf_counter_en["\Memory\Pages/sec"]
perf_counter_en["\Memory\Cache Bytes"]
perf_counter_en["\Memory\Page Faults/sec"]
perf_counter_en["\Memory\Pool Nonpaged Bytes"]
perf_counter_en["\Memory\Free System Page Table Entries"]
perf_counter_en["\PhysicalDisk(0 C:)\Disk Reads/sec",60]
perf_counter_en["\PhysicalDisk(0 C:)\Avg. Disk Read Queue Length",60]
perf_counter_en["\PhysicalDisk(0 C:)\Current Disk Queue Length",60]}}
Unaffected item keys (control group, same host, same key syntax)
 
{{perf_counter_en["\Processor Information(_total)\% DPC Time"]
perf_counter_en["\Processor Information(_Total)\% Processor Time",60]}}
Steps to reproduce:

1. Configure the above Memory/PhysicalDisk perf_counter_en items on a Windows 11 26H2 host with Agent 2 7.4.15, active checks, standard polling interval (60s).
2. Set DebugLevel=5 and restart the agent.
3. Observe the log: items log parsed performance counter ... and executed exporter task for itemid:... key 'perf_counter_en[...]' every cycle, exactly on schedule.
4. Search the same log for "request":"agent data" payloads and check whether the affected itemids ever appear inside the data array.

Result:
See log file Debug5log

The affected itemids (Memory/PhysicalDisk) never appear in any outgoing agent data payload. The control itemid (Processor Information) appears in outgoing payloads within 1–2 cycles of execution, consistently.
Expected:
All successfully executed perf_counter_en items should be queued and sent in the next outgoing agent data batch, as happens for other performance objects.
Additional diagnostics:

• Confirmed via Get-Counter -ComputerName localhost that the OS-level PDH/English counter-name resolution path is healthy for all affected counters.
• Confirmed item Value type in Zabbix matches the data type returned (float where applicable).
• Confirmed no preprocessing steps are applied to the affected items.
• Ruled out Defender/EDR interference (Defender process exclusion added — no change; no ASR or Code Integrity events logged).
• Ruled out Group Policy / domain security baseline (reproduced on vanilla environment matching host configuration).
• Ruled out a discovery-rule or WindowsPerfInstance plugin interaction (that plugin reports active: false, 0 tasks when disabled; disabling made no difference).
• Confirmed via zabbix_agent2.exe -t that simple test-mode checks aren’t representative (plugin requires persistent sampling state the one-shot test process doesn’t have), so this test method is not useful for this specific bug.
• Confirmed server/proxy are not rejecting data — the itemids never leave the agent’s outbound queue in the first place, visible directly in the Debug5log.txt “sending” log lines.