UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.71 Safari/537.36

Steps to reproduce the problem:
The Microsoft Edge team has received a lot of requests from web developers asking for the ability to detect the exact Windows 10 version via browsers. This information is already available in Microsoft Edge, and we’re asking all Windows browsers to expose the exact version information as well.

Windows 10 gets ~2 major updates a year; so far, there haves been three major releases of Windows 10:
Windows 10 (Version 10.0.10240)
Windows 10 November Update	(Version 10.0.10586)
Windows 10 Anniversary Update (Version 10.0.14393)
…with Windows 10 “Creators Update” due in Spring 2017.

Every update has major UX and feature changes, and developers would like the version information to:

-	Target their web & app content, where the OS version is a factor. As an example, Paint 3D is one such example of such an app http://www.theverge.com/2016/10/26/13430466/microsoft-paint-3d-app-download-preview
-	Log the OS version more accurately for RUM scenarios, where this data can be key to understanding performance regressions in the wild
-	Log the OS version in bug reporting / troubleshooting scenarios
-	Prompt the user to upgrade their device – especially in BYOD enterprises
-	Give website visitors accurate step-by-step instructions in scenarios where they have to change Windows settings / use Windows UI
-	Match native UI look-and-feel 

Microsoft Edge exposes the full Windows build number in the UA string (In the case of Windows 10.0.14393):
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.79 Safari/537.36 Edge/14.14393

We’re changing our UA string to make the Windows version more obvious:
Mozilla/5.0 (Windows NT 10.0.14393; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.79 Safari/537.36 Edge/14

…as it maps better to Windows version APIs (https://msdn.microsoft.com/en-us/library/windows/desktop/ms724833(v=vs.85).aspx)

DWORD dwMajorVersion;
DWORD dwMinorVersion;
DWORD dwBuildNumber

We’re asking all Windows browsers to expose the full version along with us:

Before: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36
After:  Mozilla/5.0 (Windows NT 10.0.14393; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36

…as it gives us all a clean way to help developers detect the correct version of Windows 10. This isn't really a change in principle - previously this level of OS update would have changed the minor OS version (and that was reported in IE/Chrome/Mozilla UA strings previously), but now major.minor is fixed at 10.0 for app compat reasons and it's only the build number that changes.  ‘Build number’ is somewhat of a misnomer here – in practice, the number indicates the OS minor version number now.

No security information (patch level) information is exposed in the Windows OS build number (security patches don’t change the OS build number; the (same, if applicable) security updates go to all versions of Windows 10 that are in use).

The Windows 10 consumer population is upgraded quickly via Windows Update; this change should have limited fingerprinting impact.

We’ve tested this change for compatibility issues with browser-sniffing libraries, and we’ve found no regressions.

This change also bring the user agent string for Windows browsers more in line with Android, iOS, macOS, where the full version is used.

What is the expected behavior?

What went wrong?
See repro steps

Did this work before? N/A 

Does this work in other browsers? N/A

Chrome version: 54.0.2840.71  Channel: n/a
OS Version: 10.0
Flash Version: Shockwave Flash 23.0 r0