Windows 10 Version 2004 Build 19041 Download
Theodora Glime
I've recently updated to Windows 10 version 19041 and am not receiving any audio. I have downloaded and installed the most recent audio and graphics drivers in the hope that it would work, but none have.
My laptop is new and was purchased this year, so it is quite disappointing to encounter problems this early. In the device manager it says that all of my audio devices are working correctly. My device has Realtek(R) speakers and uses AMD Radeon graphics.
I was told that the audio drivers and graphics drivers were pretty closely linked (as the HDMI port is used to transfer both audio and video) - so I am confused as to whether the graphic drivers are also a part of the problem.
I've noticed that this update is new, so there are not any specific drivers for this version yet, but I have been waiting for months and HP have not seemed to address this issue by releasing new drivers.
Hi, thank you for your feedback. I have run through all your solutions. I did the audio troubleshoot which I have already done a fair few times and the problems come up as "Audio services not responding". I have been through the services.msc and made sure all the appropriate services are running etc etc.
I agree with "Captain Kirk"'s comments: Windows 10 Build 19041 - also named "Windows 10 Version 2004" or "20H1" - has been released in May 2020. This is the ninth major Windows 10 update. Major new features of this release are summarized in a Wikipedia article.
In the FNMS System Requirements, it is documented that the FNMS Windows agent supports all versions of Windows 7, 8 and 10. The Windows agent is a 32 bit application running both on 32bit and 64bit versions of Windows. It is designed to have as little dependencies on Windows components as possible. Generally, for new Windows builds you should not expect any compatibility issues when using the latest FNMS agent release.
To confirm, after upgrading a clean Windows 10 Version 1909 Workstation Enterprise system to Windows 10 Version 2004, I installed and ran the latest Flexera FNMS 2020 R1 Windows agent on the system without any issues.
For Windows 10: Generally, yes. As Flexera claims to fully support Windows 10 including all future updates and patches, problems related to the Flexera Agent and a Windows 10 release are highly unlikely.
At a Windows 10 command prompt, run ver. Is the next-to-last numeric group version 18917 or higher? If so, it is possible you have WSL 2 but not yet verified. Go on to step A or B.
If you do not see Windows version 18917 or higher, you have version 1.
This illustrates the result when the OS is Build 16299:
A. Open Windows PowerShell or cmd and enter the command wsl -l -v. If version 2 is installed properly, you will see the version number. If you don't see a version number, or if you see an error message (Thank you, Cornea Valentin) you have version 1 (you may also see a version number '1' which could indicate that you're running v1 - see here). Uninstall it then reinstall it as per -talk/trying-the-new-wsl-2-its-fast-windows-subsystem-for-linux
Runs it through iconv to fix its malformed UTF16 output. You don't normally see the problem unless you try to grep it (or pipe it to something like hexdump -C), but you have to clean it up before you can grep it.
This currently works (and has for the last year, at least), but could change in the future if either the WSL1 or WSL2 architecture changes in some way. However, I expect that the /proc/cmdline is likely always going to differ between WSL1 and WSL2 and can be programmatically parsed to determine the current version.
If you happen to be running Docker for Windows and you have WSL 1, then if you enter docker in the terminal for your WSL, you'll see the message The command 'docker' could not be found in this WSL 1 distro., which is a very clear confirmation.
Our goal at Rumble is to help customers identify everything on their networks, quickly, and without authentication. This process is driven by research, which often leads to dead ends, but sometimes we learn interesting things along the way. This post explores recent research into remote fingerprinting of Windows build numbers and some of the surprising results.
Rumble uses a bunch of tricks to determine operating system versions, but one of the most useful is the build number provided through the NTLMSSP authentication sequence. The build number on recent releases looks something like 10.0.19041; this can refer to either the workstation OS (Windows 10) or the server OS (Server 2019), and telling those apart is a challenge on its own. The NTLMSSP response is available through any NTLM-enabled service: SMB, RDP, and MSRPC, and sometimes HTTP servers.
We started off installing one of everything in our test lab and went down the list of default services. Are there any differences in the TCP/IP stacks? How about the TCP window size? Does the EPM list any differences in RPC services? Is anything different with RDP or SMB?
We reviewed the DCERPC EPM services for a little over 200,000 Windows systems and built a table of minimum observed build number versus UUID. This work was useful in that it can flag the oldest possible version associated with a build, but it didn't help with two specific cases: differentiating between versions 1903 and 1909 and fingerprinting specific builds between the versions 2004 and 21H2. There was still no obvious way to tell these apart. A partial extract of this UUID table is shown below.
On a lark, we also looked into the WinRM service (5985/5986). WinRM (over WS-MAN) provides a path to query the build number, but this normally requires authentication. After poking around with the API, we found that sending a magic HTTP header allowed access to this endpoint without authentication, but doing so causes Windows to report back an all-zero version number. This ended up being useful for detecting the OMI WS-MAN services (they report the real version in this case), but left us at square one for Windows build fingerprinting.
A wise person once said: "when in doubt, turn to the documentation". We dove into the Windows release notes to see if there were any advertised changes we might be able to measure from the network. This paragraph stopped us cold (the emphasis is ours):
Well, that answers that. Systems reporting build 10.0.19041 for Windows versions 2004 through 21H2 are the same operating system with identical system files. The only difference is how long a specific build gets updates from the same channel. If you install and then fully update versions 2004 and 21H1, you end up with the same operating system (outside of what WinVer tells you). This was not the expected outcome and we needed to change how Rumble reports these versions and their end-of-life system.
A range of potential versions is better than nothing, but it means that our end-of-life tracking has to assume the newest possible version for the reported build number in order to avoid false positives. Starting with Rumble v2.7.0, Windows OS versions are now reported and tracked for EOL status using these ranges:
The good news is that sometimes we can do better. In a few cases, specific DCERPC services are available that help us ratchet up the minimum version, and any connections to CrowdStrike or Miradore will pull in the exact build number every time. Rumble will use anything you give it to provide the most accurate fingerprint, but this still wasn't a satisfying outcome.
When the normal documentation falls short, it's time to dig into the specifications. One underappreciated outcome from the Microsoft anti-trust settlement is that the company was required to make protocol specifications open to competitors. Once they started down this path, the company seemed to embrace the open approach, and now many parts of Windows have an amazing level of protocol documentation. What makes this even more amazing is these documents have detailed diffs and a beautiful appendix named "Product Behavior". This documentation provides granular details on what various Windows versions do at the protocol level and how it has changed over time. Finally, some hope!
The next few hours were spent skimming through the product behavior appendices and mapping these changes back to unauthenticated functionality of the related protocol. There are a ton of changes, but most of them are not things a network scanner can measure easily. Finally, one of our old friends showed up on the list: MS-SMB2.
We love this document. That may sound weird, but prior to Microsoft publishing these specifications, most work on the SMB protocol was a mix of binary analysis and packet captures. It still mostly is, but now we have something to compare them against, often with names and descriptions. The diffs and product behavior sections looks promising, especially the sections that reference the Negotiation Context processing.
In SMB v3 parlance, the Negotiation Context is a set of Type-Length-Value fields appended to the end of the Negotiate Request. Clients are supposed to send any contexts they want to use and servers are supposed to ignore unknown context types and reply to the ones they support. This process happens before the authentication phase and is perfect for our fingerprinting needs.
This context is used to provide a name to in-line load balancers and acts kind of like TLS's Server Name Indicator (SNI). Unfortunately, SMB servers do not acknowledge or reply to this context, and it isn't useful as a result.
Theoretically, these rules cover the versions we are trying to differentiate between, except for the case of 1903 vs 1909. Time to write up a SMB v3 Negotiate Context implementation for Rumble and see how things look in the real world.
It is still not possible to differentiate between 1903 and 1909 or any of the build 19041 variants (2004-21H2).The Windows 10 release notes were correct, but the MS-SMB2 documentation is wrong. Any reference to a Windows 10 or Server 2019 build newer than 2004 in the MS-SMB2 product behavior notes actually applies to Windows 11 and Server 2022 instead. This would be useful, except the version reported by those systems via the NTLMSSP build number is actually correct, and we don't need to do more precise fingerprinting (yet).
d3342ee215