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

[Update 2017-02-07] Note that both of the two issues noted below have been fixed in more recent Insider builds

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

[Update 2017-02-07] Note that the two issues listed below have been fixed in more recent Insider builds. Be sure to update to the latest builds to get the best Bash/WSL experience.

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 (23)

  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 🙂

      1. Jaap says:

        And we are of course equally interested in the detailed changes of 15007 🙂

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

    My worked around for no CTRL+C problem: Using ConEmu

    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:

      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.

  4. access to serial port please

  5. Rob Landers says:

    We’re like the passengers as you build a plane in the air …

    1. Don’t get on-board if you don’t want an exciting ride 😉

  6. balor says:

    Hi there,
    It’s a pleasure to read such a professional changelog <3
    I'm really excited about recent changes in the windows environment, especially from the dev point of view.
    Looking forward to see mature version of linux subsystem this year (although even now there's a lot of things that works).
    Btw. Please handle mouse events :*

    1. Many thanks Balor 🙂

      FWIW, Bash mouse support was added to Insiders builds several months ago – works well in MidnightCommander, Vim, etc. (although note that you do have to manually configure tools like Vim (“set mouse=a”), Tmux, etc. to enable mouse support.

  7. Andrew_O says:

    I realize it is probably way early for this question and this is probably the not right venue for it, but do you know when WSL will make it into an actual Windows update, rather than just insider builds?

    Seems like there is probably still a bit to go before this is no longer a beta project but I can’t use it at work till it becomes not combined with the insider builds.

    Alternatively is there a way to install WSL on its own rather than through a insider build?

    1. Because WSL is highly dependent upon kernel features that are simultaneously rapidly evolving, we cannot ship WSL as an update to previous versions of Windows. This is especially true since its also a beta feature.

      WSL has been evolving VERY rapidly for the last 8+ months, and will continue to do so after we deliver Win10 Creators Update. We’re releasing Insider builds pretty much every week, delivering new kernel and WSL features: This is WAY too quick a release schedule for Windows Updates, which primarily delivers patches for existing, supported, features.

      We will (and have) ship fixes via Windows Update for crucial security/reliability bugs to users on Win10 AU / CU, all the new features will be delivered via Insider builds which are early snapshots of the next major OS release as it’s being built. 

  8. Please make app like Bazel runs/compatible on BashOnWindows, right now it hangs

      1. Evan says:

        Bazel is an open source version of Google’s internal build tool. I cant confirm whether or not it’s crashing in WSL, but it is a really cool build tool.

    1. Michael says:

      Looks like this has been fixed in Bazel:

      1. Thanks for the note – good to know 🙂

Skip to main content