Agent package incompatibilities with old Windows systems

[jotacarma90]

Wazuh version	Component	Install type	Install method	Platform
5.0.0	Wazuh package	Agent	Packages	Windows

Description

After the creation of the Windows package for the new version of Wazuh Agent 5.0, we have found some incompatibility problems and missing libraries in the old Windows systems.

This issue is to analyze and deepen in which is the correct method to solve those problems.

Related Windows package development issue: #134 (comment)

Tested Windows systems

#191 (comment)

Windows Version	Installation Successful	Notes
Windows XP	❌	The installation package is not supported by this processor type.
Windows Server 2003	❌	The installation package is not supported by this processor type.
Windows Server 2008 R2	❌	api-ms-win-crt-runtime-l1-1-0.dll is missing
Windows Server 2012 R2	❌	api-ms-win-crt-runtime-l1-1-0.dll is missing
Windows Server 2016	✅
Windows Server 2019	✅
Windows Server 2022	✅
Windows 10	✅
Windows 11	✅

[vikman90]

@jotacarma90 the Agent 5.0 is not required to run on Windows XP or Server 2003.

Let's focus on Windows Server 2008 and 2012. Is this .dll required for the package or for the agent executable? If the latter, we may be able to fix this with static linking.

[jotacarma90]

Update 05/05/2025

• I have been reviewing the latest changes to the installation postinstall script, among others, it has been decided to leave the configuration file in the program files folder: Latest changes required to Windows scaffolding #738
• I have lifted the windows 2008 and 2012 environments.
• The error keeps occurring.
  • Installation log:
    log.log
  • Postinstall script execution:

WixQuietExec:  Creating directory: C:\ProgramData\wazuh-agent
WixQuietExec:  Creating directory: C:\ProgramData\wazuh-agent\config
WixQuietExec:  Creating directory: C:\ProgramData\wazuh-agent\config\shared
WixQuietExec:  Creating directory: C:\ProgramData\wazuh-agent\var
WixQuietExec:  Creating directory: C:\ProgramData\wazuh-agent\run
WixQuietExec:  Directories created successfully.
WixQuietExec:  Installing service wazuh-agent.
WixQuietExec:  Error wazuh-agent installing service. Error code: -1073741515.
WixQuietExec:  Error 0x80070001: Command line returned an error.
WixQuietExec:  Error 0x80070001: QuietExec Failed
WixQuietExec:  Error 0x80070001: Failed in ExecCommon method
CustomAction PostInstall returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)

• Event viewer:

Faulting application name: wazuh-agent.exe, version: 0.0.0.0, time stamp: 0x6818b91e
Faulting module name: api-ms-win-core-heap-l2-1-0.dll, version: 6.3.9600.17415, time stamp: 0x5450559e
Exception code: 0xc0000135

• The missing library is required when running the executable. I'm investigating possible solutions.

Update 06/05/2025

• After much trial and error analysis. It seems that it is not possible to simply add the missing dll. Since they are not common libraries. I was able to find this: https://learn.microsoft.com/en-us/windows/win32/apiindex/windows-apisets
• Windows API Sets (api-ms-win-*) are a modern way of structuring system APIs in Windows 8 and later. They are not traditional DLLs, but internal system interfaces redirected by the Windows loader. Therefore, they cannot be manually copied to older versions such as Windows Server 2008 R2 or 2012 R2, as those systems do not have native support for them.
• For the agent to work on Windows Server 2008/2012, it is necessary to compile with the toolset v141 or earlier and use the Windows 8.1 SDK (not complete testing done).
• I have been making some basic attempts to see how dependent we are on compiling to use these versions. Using this branch, which includes some minor changes to cmake to use visual studio 16, and a windows-2019 host runner:
  main...enhancement/525-old-windows-support
• Build from testing, the compile has failed in multiple places, probably caused by incompatibilities that would need to be resolved:
  https://github.com/wazuh/wazuh-agent/actions/runs/14859846523/job/41721725251
• In conclusion, we must decide if we really want to have support for these systems, since it involves modifying the compilation in depth, adapting it to previous versions of VS and SDK. @vikman90 @MarcelKemp