# Winlogbeat 9.4.3 parsing fields wrong unless include\_xml is supplied

**URL:** <https://discuss.elastic.co/t/winlogbeat-9-4-3-parsing-fields-wrong-unless-include-xml-is-supplied/388680>\
**Category:** Beats\
**Tags:** winlogbeat\
**Created:** [July 23, 2026, 8:13am UTC](https://discuss.elastic.co/t/winlogbeat-9-4-3-parsing-fields-wrong-unless-include-xml-is-supplied/388680 "2026-07-23T08:13:52Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![tt-ah](https://avatars.discourse-cdn.com/v4/letter/t/35a633/32.png) [@tt-ah](https://discuss.elastic.co/u/tt-ah)\
**Post date:** [July 23, 2026, 8:13am UTC](https://discuss.elastic.co/t/winlogbeat-9-4-3-parsing-fields-wrong-unless-include-xml-is-supplied/388680/1 "2026-07-23T08:13:52Z")

</div>

Hello everyone!

I noticed at least one field being processed incorrectly after updating our Elasticsearch and Winlogbeats to 9.4.3 (from 8.x.x). I do not have other findings yet, but I doubt this is the only case.

Applocker-Events include a field called `winlog.user_data.FileHash` which is a String with 64 characters. Since the update to 9.4.3 this field contains a string, that begins with the 64 character Filehash but then continues to include the raw content of the fields `winlog.user_data.fqbn` and `winlog.user_data.FullFilePath` in Hex-code. However the fields `winlog.user_data.fqbn` and `winlog.user_data.FullFilePath` still exist separately in the parsed document.

When checking the Windows Eventlog the FileHash-Field is unchanged and only includes the hash itself. For debugging purposes I enabled "include\_xml" in the winlogbeat.yml and the FileHash-Field was then promptly parsed correctly again.

Here you see the difference in FileHash between Clients with Winlogbeat 8.19 and 9.4:

 ![Bildschirmfoto 2026-07-21 um 15.07.00](https://us1.discourse-cdn.com/elastic/original/3X/d/4/d4d6b3dfce5d112e8c739c090cffc119ca310389.jpeg)

Example Document from winlogbeat 9.4.3:

 ![Bildschirmfoto 2026-07-21 um 14.55.03](https://us1.discourse-cdn.com/elastic/original/3X/6/7/674ac9328d1322d74bedfc0ee87309068ab6e414.png)

You can see that the FileHash-Field contains the Hash and then further information in HEX, which translates to:

```auto
O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US\

MICROSOFT® WINDOWS® OPERATING SYSTEM\

WMIC.EXE\

10.0.20348.2849

<NUL>

SysC:\Windows\SYSTEM32\WBEM\WMIC.exe

<NUL>

15

```

Is this a bug related to: [https://github.com/elastic/beats/pull/42275](https://github.com/elastic/beats/pull/42275) ? As I said the behaviour returns to normal if `include_xml` is enabled in winlogbeat - however this produces a big overhead according to the documentation, so I do not want to use this as a workaround.

---

<div class="post-metadata">

**Author:** ![tt-ah](https://avatars.discourse-cdn.com/v4/letter/t/35a633/32.png) [@tt-ah](https://discuss.elastic.co/u/tt-ah)\
**Post date:** [August 5, 2026, 7:08am UTC](https://discuss.elastic.co/t/winlogbeat-9-4-3-parsing-fields-wrong-unless-include-xml-is-supplied/388680/2 "2026-08-05T07:08:42Z")

</div>

Since I havent heard anything back, is it ok to open a gitlab issue for this?

---

<div class="post-metadata">

**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, 2026, 1:50pm UTC](https://discuss.elastic.co/t/winlogbeat-9-4-3-parsing-fields-wrong-unless-include-xml-is-supplied/388680/3 "2026-08-06T13:50:15Z")

</div>

Hi @tt-ah

Sorry you did not get a response and yes you can open an issue in the repo.

One comment, posting images of text is not a great ideas hard to read if at all hard to debug reproduce etc., many forum members will just skip. Next time try to past formatted text.