# Errors with filebeat when trying to integrate any windows integration logs with the agent **URL:** \ **Category:** Elastic Agent\ **Tags:** filebeat\ **Created:** [August 5, 2025, 4:51pm UTC](https://discuss.elastic.co/t/errors-with-filebeat-when-trying-to-integrate-any-windows-integration-logs-with-the-agent/380768 "2025-08-05T16:51:36Z")\ **Posts on this page:** 7\ **Page:** 2
**Author:** ![stephenb](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/stephenb/32/40856_2.png) [@stephenb](https://discuss.elastic.co/u/stephenb)\ **Post date:** [August 6, 2025, 10:29pm UTC](https://discuss.elastic.co/t/errors-with-filebeat-when-trying-to-integrate-any-windows-integration-logs-with-the-agent/380768/21 "2025-08-06T22:29:57Z")
I asked internally… The one thing that keeps bothering me is it's saying they Guid is reused…. If you completely delete the integration policy everything and create a new one, does it still do the same thing? I assume you're doing just the enrollment token version If you just do a base agent with system logs and metrics do you still get the same error? Just do a base policy nothing else ---
**Author:** ![stephenb](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/stephenb/32/40856_2.png) [@stephenb](https://discuss.elastic.co/u/stephenb)\ **Post date:** [August 6, 2025, 10:47pm UTC](https://discuss.elastic.co/t/errors-with-filebeat-when-trying-to-integrate-any-windows-integration-logs-with-the-agent/380768/22 "2025-08-06T22:47:46Z")
@v_i_x_x @f4n-1nh1b1t10n Look what I just found I think this is your Bug!!! so it is NOT you! > > > Fixes a panic in the winlog input that happened because of a conflict in the int…ernal id of its metrics registry https://github.com/elastic/beats/issues/45693. > > When checking whether a registry input id already exists, the check didn't include the ids of input registries with "nested" type (which are unreported containers for cursor-based inputs that can have several sub-inputs inside). > > This is usually not a problem because the default (and what most inputs use even when overriding their id, e.g. I think this is why it probably didn't hit the GCP input) is to use a scoped id like "input\_id::source\_id", so they don't conflict with the container which has bare id "input\_id". > This hit winlog in particular because: > \- winlog always uses a source id that is the same as its input id > \- winlog still used the global input metrics helpers in the \`inputmon\` package instead of the metrics registry provided by the Filebeat inputs API > \- winlog is the only input that did not add a scope prefix on the id provided to \`inputmon.NewInputRegistry\`, so the globally-created registry conflicted with the input manager's container (and this conflict was missed because of the missed "nested" type check above). > > Fixing the missed "nested" collision check would prevent the input panic, but the collision itself would still exist and prevent winlog input metrics from being reported. > > This PR both fixes the missed "nested" conflict check and removes the deprecated global metrics call from the winlog input, replacing it with the API-provided registry. > > \## Checklist > > \- \[x\] My code follows the style guidelines of this project > \- \[x\] I have commented my code, particularly in hard-to-understand areas > \- \[\] ~~I have made corresponding changes to the documentation~~ > \- \[\] ~~I have made corresponding change to the default configuration files~~ > \- \[x\] I have added tests that prove my fix is effective or that my feature works > \- \[x\] I have added an entry in \`CHANGELOG.next.asciidoc\` or \`CHANGELOG-developer.next.asciidoc\`. > > > \## Related issues > > \- Fixes https://github.com/elastic/beats/issues/45693. > > > \`9.1.0\` and \`8.19.0\` do not process Windows event. After repeatedly building an…d testing locally, I traced it down to https://github.com/elastic/beats/pull/44452. This was back-ported to \`8.19.0\`, and I confirmed that it has the same problem. > > Agent diagnostics were taken on \`9.1.0\`(broken) and \`8.18.0\`(working). On \`8.18.0\`, \`components/winlog-default/input\_metrics.json\` shows the expected input stats. However, in diagnostics from \`9.1.0\`, the content of the same file is an empty array. > > For confirmed bugs, please report: > \- Version: \`9.1.0\` \`8.19.0\` > \- Operating System: Windows 10 and 11, server 2022 > \- Discuss Forum URL: N/A > \- Steps to Reproduce: > > \### Reproducing > 1. Deploy Elastic Agent with \`system\` integration on a Windows machine. > 2. Make sure the policy has \`Collect evetns from the Windows event log\` and \`Security\` enabled. > \Image > > 3. Once the Agent is deployed on the system, run attached powershell script as administrator on the Windows box to generate security event. > 4. Note that data flows in with \`8.18.0\`, but not with \`9.1.0\` or \`8.19.0\` > > \### Attachment > > \#### security\_event\_generator.ps1 > > \`\`\`powershell > $FolderPath = "C:\\audit\_test" > $AuditUser = "Everyone" > $AuditRules = "Modify, Delete, CreateFiles, ReadAttributes, ListDirectory" > $InheritType = "ContainerInherit, ObjectInherit" > $AuditType = "Success" > > \# Clear log first > \# Clear-EventLog is not available in powershell 7 > \#Clear-EventLog -LogName security > wevtutil cl security > > \# Set audit policy > auditpol.exe /set /category:"Object Access" /success:enable /failure:enable > auditpol.exe /get /category:"Object Access" > > \# Apply audit policy > New-Item -ItemType Directory -Force -Path $FolderPath > $AccessRule = New-Object System.Security.AccessControl.FileSystemAuditRule($AuditUser, $AuditRules, $InheritType, "None", $AuditType) > $ACL = Get-Acl $FolderPath > $ACL.AddAuditRule($AccessRule) > Set-Acl $FolderPath $ACL > > while ($true) { > # Generate audit log by creating files. > for ($i = 0; $i -lt 10000; $i++) { > $filepath="$FolderPath/$i.txt" > # Write-Output "creating and deleting $filepath" > # this is to hide the output > $null = New-Item -Force -Path $filepath > } > # Generate additional audit log from listing directory. > # This generates far more audit entries. > for ($i = 0; $i -lt 1000; $i++) { > # It is important to store the output to a file, otherwise the command will not generate audit events. > Get-Childitem $FolderPath \> $FolderPath\\list.txt > # sleep so that we dont' overwhelm the OS > Start-Sleep -Milliseconds 500 > } > > Get-ChildItem -Path $FolderPath -File | Remove-Item -Force > > # Wait for 1 seconds > Start-Sleep -Seconds 1 > } > \`\`\` When this will be available trying to find out ---
**Author:** ![f4n-1nh1b1t10n](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/f4n-1nh1b1t10n/32/144539_2.png) [@f4n-1nh1b1t10n](https://discuss.elastic.co/u/f4n-1nh1b1t10n)\ **Post date:** [August 6, 2025, 10:56pm UTC](https://discuss.elastic.co/t/errors-with-filebeat-when-trying-to-integrate-any-windows-integration-logs-with-the-agent/380768/23 "2025-08-06T22:56:39Z")
oh the humanity 🙂 thanks for the investigation/clarification @stephenb ---
**Author:** ![stephenb](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/stephenb/32/40856_2.png) [@stephenb](https://discuss.elastic.co/u/stephenb)\ **Post date:** [August 6, 2025, 11:06pm UTC](https://discuss.elastic.co/t/errors-with-filebeat-when-trying-to-integrate-any-windows-integration-logs-with-the-agent/380768/24 "2025-08-06T23:06:05Z")
Wonder why mine is working….. maybe cuz mine was already deployed or something ---
**Author:** ![stephenb](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/stephenb/32/40856_2.png) [@stephenb](https://discuss.elastic.co/u/stephenb)\ **Post date:** [August 7, 2025, 1:21am UTC](https://discuss.elastic.co/t/errors-with-filebeat-when-trying-to-integrate-any-windows-integration-logs-with-the-agent/380768/25 "2025-08-07T01:21:22Z")
Ok this bug goes a ways back... and it is in the agent libraries not the integration I am running Agent 8.17.5 and it is working... So you could uninstall the agent and try that version.... Then Upgrade the agent when the fix comes out... ---
**Author:** ![v\_i\_x\_x](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/v_i_x_x/32/144537_2.png) [@v\_i\_x\_x](https://discuss.elastic.co/u/v_i_x_x)\ **Post date:** [August 7, 2025, 9:39am UTC](https://discuss.elastic.co/t/errors-with-filebeat-when-trying-to-integrate-any-windows-integration-logs-with-the-agent/380768/26 "2025-08-07T09:39:12Z")
@stephenb I want to say thank you and appreciate the help you provided. It worked out with 8.17.9 (as you suggested), I can see all logs now. ![image](https://us1.discourse-cdn.com/elastic/original/3X/0/7/0705657c899d8cd8eba3761e0c1ae0363c59253a.png) ---
**Author:** ![stephenb](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/stephenb/32/40856_2.png) [@stephenb](https://discuss.elastic.co/u/stephenb)\ **Post date:** [August 7, 2025, 1:50pm UTC](https://discuss.elastic.co/t/errors-with-filebeat-when-trying-to-integrate-any-windows-integration-logs-with-the-agent/380768/27 "2025-08-07T13:50:18Z")
@v_i_x_x @f4n-1nh1b1t10n Closing this out Per the engineers... so Perhaps try one of those versions > The fix is in 9.1.1 and 8.19.1. The root cause was a change to how metrics registries are organized internally in libbeat, which caused a namespace collision in the winlog input specifically. There's a small but key component wrapping winlogbeat code for use as a filebeat input, and that's where there was a test coverage gap, so the namespace collision was missed. [Previous page](https://discuss.elastic.co/t/errors-with-filebeat-when-trying-to-integrate-any-windows-integration-logs-with-the-agent/380768.md?page=1)