Bash in Windows Insider build 15002 – many fixes but a couple of bugs!


Windows Insider build #15002 started shipping to Windows Insider Fast Ring users today, January 9th 2017.

As is often the case in software development, after many teams have been beavering-away on their features for several months, things really start to come together toward the end of the development cycle. This is especially true when said feature cycle ends just after Xmas 😉 Build 15002 is a good example of this phenomenon: This is a MASSIVE release, with many, MANY exciting new features, capabilities, improvements lighting-up for the first time, and many fixes arriving, driving up the product’s quality. For a comprehensive breakdown of these great new features, be sure to read the release notes in the Windows 10 Feedback Hub.

What’s new for Bash in build 15002?

As per the WSL build 15002 release notes, a LONG list of improvements and fixes for Bash/WSL also arrived in this build, resulting in even more compatibility, performance and stability of your favorite Linux tools and technologies:

  • All bash sessions must now be created at the same permission level. Attempting to start a session at a different level will be blocked. This means admin and non-admin consoles cannot run at the same time. (GH #626)
  • Implemented the following NETLINK_ROUTE messages (requires Windows admin)
    • RTM_NEWADDR (supports ip addr add)
    • RTM_NEWROUTE (supports ip route add)
    • RTM_DELADDR (supports ip addr del)
    • RTM_DELROUTE (supports ip route del)
  • Scheduled task checking for packages to update will no longer run on a metered connection (GH #1371)
  • Fixed error where piping gets stuck i.e. bash -c “ls -alR /” | bash -c “cat” (GH #1214)
  • Implemented TCP_KEEPCNT socket option (GH #843)
  • Implemented IP_MTU_DISCOVER INET socket option (GH #720, 717, 170, 69)
  • Removed legacy functionality to run NT binaries from init with NT path lookup. (GH #1325)
  • Fix mode of /dev/kmsg to allow group / other read access (0644) (GH #1321)
  • Implemented /proc/sys/kernel/random/uuid (GH #1092)
  • Corrected error where process start time was showing as year 2432 (GH #974)
  • Switched default TERM environment variable to xterm-256color (GH #1446)
  • Modified the way that process commit is calculated during process fork. (GH #1286)
  • Implemented /proc/sys/vm/overcommit_memory. (GH #1286)
  • Implemented /proc/net/route file (GH #69)
  • Fixed error where shortcut name was incorrectly localized (GH #696)
  • Fixed elf parsing logic that is incorrectly validating the program headers must be less than (or equal to) PATH_MAX. (GH #1048)
  • Implemented statfs callback for procfs, sysfs, cgroupfs, and binfmtfs (GH #1378)
  • Fixed AptPackageIndexUpdate windows that won’t close (GH #1184, also discussed in GH #1193)
  • Added ASLR personality ADDR_NO_RANDOMIZE support. (GH #1148, 1128)
  • Improved PTRACE_GETSIGINFO, SIGSEGV, for proper gdb stack traces during AV (GH #875)
  • Elf parsing no longer fails for patchelf binaries. (GH #471)
  • VPN DNS propagated to /etc/resolv.conf (GH #416, 1350)
  • Improvements to TCP close for more reliable data transfer. (GH #610, 616, 1025, 1335)
  • Now return correct error code when too many files are opened (EMFILE). (GH #1126, 2090)
  • Windows Audit log now reports the image name in process create audit.
  • Now gracefully fail when launching bash.exe from within a bash window
  • Added error message when interop is unable to access a working directory under LxFs (i.e. notepad.exe .bashrc)
  • Fixed issue where Windows path was truncated in WSL
  • Additional fixes and improvements

Along with support for the following shared-memory syscalls which are widely used by a number of Linux tools including PostgreSQL.

  • shmctl
  • shmget
  • shmdt
  • shmat

As always, we’d appreciate your help to test your code, tools, platforms, and technologies against this new build and let us know if you find issues.

Known Issues

Alas, Windows 10 Insider Build 15002 also introduces a couple of issues for Bash/WSL users:

  1. While WSL is running a system thread will consume 100% of a CPU core
  2. CTRL+C doesn’t work in Bash (see GH bug #1569)

What no CTRL+C?

[Update1: The following was added by request from the community]

The reason that the CTRL+C bug made it into an insiders build is complex, but essentially came down to a few things:

  • The Console and Bash features are built by two teams in different org’s who regularly collaborate & communicate, but are two trains running on different tracks
  • The Console team are overhauling, re-factoring, and modernizing the rather “old” Console code-base, and checked-in a bunch of changes to their branch. These changes passed all the Console tests, almost all of which are Cmd/PowerShell tests
  • By the time those changes made it up & back down the branches of the build tree to the Bash/WSL team, most members of both teams were on Xmas vacation
    • Interesting aside: I did, in fact, find this issue while on vacation (definitely NOT spending vacation time coding ;)) but worked around the problem assuming I had a borked build
  • The issue was formally found on Tuesday last week. The team then:
    • investigated the issue & figured out the problem
    • communicated the issue internally
    • implemented a fix
    • reviewed the fix
    • checked the fix into the branch
    • built & tested the fix
    • re-validated the fix worked
    • requested the fix is fast-tracked, which should result in this fix making it into the next insider build

Alas, the fix couldn’t make it into this week’s insider build and wasn’t deemed sufficiently important to block the insider build.

Such is the cost of seeing how the sausage is made 😉 Remember: The Insider fast-ring builds are essentially weekly, relatively-stable, partially complete builds of Windows as it’s being built. While we do our best not to break stuff, sometimes, breakage and issues are inevitable.

We apologize for these issues, but both have been fixed internally and the fixes are being fast-tracked so that they can be released ASAP into an up-coming Insiders build.


Comments (8)

  1. Jonathan says:

    Wow, love the detailed changelog and explanation! Helps us insiders know what to test. Thanks Rich! The other teams building Windows could learn something from this post…

    1. Many thanks; glad you found it informative 🙂

  2. Đoàn Tuấn Lộc says:

    My worked around for no CTRL+C problem: Using ConEmu https://conemu.github.io

    1. Yep, some of the 3rd party consoles do not exhibit this issue. This won’t be an issue for very long though: the fix is in, tested, and is bubbling up through the build system as I type.

  3. Magnus Andersson says:

    > Interesting aside: I did, in fact, find this issue while on vacation (definitely NOT spending vacation time coding ;)) but worked around the problem assuming I had a borked build

    Anything we mere mortals can do to work around it in the mean time? (This really, really messes up like 90% of my work, since i spend much of my time in the wonderful bash environment)

    1. Magnus Andersson says:

      Never mind.. Found the (annoying) workaround here:
      https://github.com/Microsoft/BashOnWindows/issues/1569

      It works good on my local machine, but the same command has to be entered on each remote machine as well.. :-/

      1. Yep, it’s a pain, I agree. However, the fix is bubbling its way up the build system – will be released in the first Insider build after it hits our main branch; likely next week.

Skip to main content