Windows 10 Pro x64

we seem to have this problem every now and then :

• ZBX-1829
• ZBX-7875
  wondering whether there's something to do more proactively ?

Strange ...
According to the mentioned ZBX-7875 development I supposed similar issue should newer happen in future.

Indeed, this is true. Verified while working on ZBX-10063.

zalex_ua, quoting comment from ZBX-7875:

Nikolajs Agafonovs: yes, you are correct about detection of future windows versions. This function will work till microsoft change version key location in windows registry. Let's hope they will not do that

Well, they did. Starting from Windows 10 the items under SOFTWARE\\Microsoft\Windows NT\CurrentVersion are different than before. In particular CurrentVersion still contains value 6.3 while the new keys CurrentMajorVersionNumber and CurrentMinorVersionNumber contain the values 10 and 0.

The reason why we continue using registry instead of documented APIs for version checking is backwards compatibility. We target our agent to Windows XP and we build it using Windows 7 SDK. Some of the API functions are sensitive to build target. Others are not available in older releases of Windows.

Conclusions after long and painful investigation of Windows 2000 - Windows Server 2016 Technical Preview 4.

There is no Windows API for retrieving Windows version and product name (including OS edition) that is:

• backwards compatible to Windows 2000 or at least Windows Vista;
• future proof;
• supported by Microsoft;
• independent of compatibility modes (GetVersionEx() and the usual functions for getting version from registry take into account the compatibility mode);
• independent of localization, translation (e,g, English U.S. locale not guaranteed to be present in desktop class Windows OSes, even if it is present there are translation issues, see below);

WMI (see Win32_OperatingSystem class) came closest to meeting all of these requirements. The only thing where it trips up is localization, translation. For some reason when querying for the Windows product name WMI provides the name translated to the current users display language regardless of the locale specified. Another issue - U.S. English is not guaranteed to be present on all Windows installations.

# Try this in PowerShell after installing Russian or French as display language.
(Get-WmiObject -class Win32_OperatingSystem -locale MS_409).Caption

# Note that at least on Windows 8 the first ten minutes or so after boot the command still returns the English name (see the attached screenshot).

# Alternatively: the same with Zabbix...
zabbix_get -s 127.0.0.1 -k wmi.get[root\cimv2,"select Caption from Win32_OperatingSystem"]

For completeness I must mention that when running agentd as a service I get the English OS name however this might be due to me starting off with an English version of Windows. Whether this remains true with a single language (say - French) edition of Windows remains to be seen. UPDATE: running agentd as service on French Windows 7 Home Premium didn't help - the OS name is translated to French.

So currently the plan is as follows.

• For product name on systems that have it use prodspec.ini file (Windows 2000, Windows XP) which includes the OS edition. The file must not be edited by users as that might create problems with upgrades, etc. On more recent systems use HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProductName registry key via NtOpenKey() or WMI API (to prevent compatibility mode hiding the real version). For product name we'll use WMI (Caption). It is the same information as returned by systeminfo.
• For product version let's use WMI (Version).
• For service pack information we can also use WMI (CSDVersion).
• For the machine architecture we'll use WMI (Architecture, AddressWidth of Win32_Processor class).

Unfortunately we cannot use NtOpenKey() etc. in Zabbix as this would require us to add Windows driver development toolkit as a build dependency.

Some issues with the current implementation of system.uname on Windows.

• On Windows 7 Home Premium SP1 Zabbix doesn't provide the service pack information. For some reason it cannot be read from the registry although the value is present (checked with regedit). No such issue on other Windows versions with SPs installed.
• On Windows 10 Enterprise Evaluation running Zabbix agent in compatibility mode (say Windows 8) has no effect on the reported version. This is different than in all other Windows versions that I've tried.

Issues with current implementation of wmi.get.

• The returned strings are not UTF-8 encoded.

Tested the WMI based implementation on:

• Windows 2000;
• Windows XP Pro (Russian and English);
• Windows Vista Ultimate x64 (English);
• Windows 7 Home Premium x64 (French);
• Windows Server 2008 x64 (English);
• Windows 8.1 Pro x64 (English);
• Windows 10 Enterprise x64 (French);
• Windows Server 2016 Technical Preview 4 (English).

Fixed in development branch svn://svn.zabbix.com/branches/dev/ZBX-9877 .

(1) wmi.get didn't return UTF-8 encoded strings.

sandis.neilands RESOLVED in r57889.

wiper fixed memory leak in r57939, still RESOLVED

sandis.neilands CLOSED.

(2) Documentation updates are needed.

• https://www.zabbix.com/documentation/3.0/manual/introduction/whatsnew300#item_changesimprovements
• https://www.zabbix.com/documentation/3.0/manual/config/items/itemtypes/zabbix_agent?s[]=system&s[]=uname
• https://www.zabbix.com/documentation/3.0/manual/installation/upgrade_notes_300

sandis.neilands RESOLVED. wiper, please review the content and then pass this ZBX to martins-v for language and typography review.

martins-v Reviewed, CLOSED.

(3) After discussion was decided to print OS architecture rather than CPU architecture. Printing CPU architecture would match *nix uname, but for Windows systems the OS architecture is more important.

sandis.neilands RESOLVED in r57956.

wiper CLOSED

(4) In r57939 we made com_initialized a thread local variable meaning that COM will be initialized for each listener thread. This is how it should be according to the documentation (it somehow worked before). However CoInitializeSecurity() must be called only once per process. If it has been already called it returns RPC_E_TOO_LATE causing per-thread COM initialization to fail.

RESOLVED in 57955.

wiper CLOSED

Successfully tested

Released in:

• 3.0.0beta2 r57997.