Add new comment

Git shell on Windows reports “sh.exe has stopped working (APPCRASH)”

Difficulty: 
Let's Rock

About the Error

In this article we will show you how to deal with the following error:

sh.exe has stopped working

Problem signature:
  Problem Event Name:    APPCRASH
  Application Name:    sh.exe
  Application Version:    0.0.0.0
  Application Timestamp:    5491f440
  Fault Module Name:    ntdll.dll
  Fault Module Version:    6.3.9600.17630
  Fault Module Timestamp:    54b0d74f
  Exception Code:    40010006
  Exception Offset:    0009f952
  OS Version:    6.3.9600.2.0.0.272.7
  Locale ID:    1033
  Additional Information 1:    2556
  Additional Information 2:    2556cfcb99465923f433625e0ec841fe
  Additional Information 3:    ca20
  Additional Information 4:    ca20a559fff2ef79c4a426fc0e92022d

 

Investigation on the issue pointed us to two circumstances that make this error show up:

  1. You are using a Virtual Machine with Xen Tools installed in them (these tools come preinstalled in Rackspace virtual servers).
  2. You are using some specific Nvidia Drivers along with the ANSICON plugin.

Situation #2 has a proposed resolution (we didn't try) in this post:

https://github.com/adoxa/ansicon/issues/46

For #2, there are a few online discussions trying to figure out what is going on:

https://jira.atlassian.com/browse/SRCTREEWIN-1215

http://stackoverflow.com/questions/21550807/git-shell-on-windows-reports...

But no real solution has been found.

Solution

The problem is that there is some sort of incompatiblity between network related operations in sh.exe and Xen Tools. But touching Xen Tools is something you do not want to do, neither upgrading nor removing them, especially on production environments or hosted cloud servers.

You must know that msysGit (the development environment to build, test and package to build GIT on windows) uses a lightweight version of Cygwin (a set of Unix like tools for windows) called MinGW. The way to solve the problem was to replace some of the MinGW binaries with their full featured version from Cygwin.

MSys is a heavily stripped-down Cygwin that has been *modified* to be portable. In other words, while Cygwin requires to be installed (and changes settings in the Windows registry), MSys does not need to be installed; merely copying it is enough.

Follow these steps to get you GIT console working with Xen Tools

Download and install Cygwin from here. Remember where you tell the installer to put all the binaries, you will need this later.

Copy the following files from the Cygwin binary folder (c:\cygwin64\bin) to the GIT binary folder (C:\Program Files (x86)\Git\bin):

  • sh.exe
  • sed.exe
  • cygwin1.dll
  • cygiconv-2.dll
  • cygintl-8.dll
  • cygncursesw-10.dll
  • cygreadline7.dll

Modify the git-pull script in C:\Program Files (x86)\Git\libexec\git-core\git-sh-setup and replace this line:

builtin pwd -W

by this one

builtin pwd -LP

Another possible way to tell GIT to use Cygwin binaries is to alter you $PATH$ environment variable, but we did not want to do this because there is a big chance of finding side effects.

Find attached a set of binaries you can simply drop into your GIT binary folder (remember to modify the git-sh-setup file manually).

See our article Building GIT for Windows from Sources to upgrade you GIT console to the latest version.

Disclaimer: while this solution works in practice and will make you GIT console functional in Xen virtualized environments, Johannes pointed these issue out at a Google Groups post (here):

* the problem is not at all Git for Windows but the Bash
* the issue is most likely an overlap of reserved address space, most properly solved by using the `rebase.exe` executable
* by copying a Cygwin `sh.exe`, the user incurs the same problem that lets Git for Windows discourage mixing Cygwin with a real Git for Windows installation (just as a simple example, all of a sudden you get ACL errors that require `chmod`ing files or directories, which Git for Windows has no idea about, being a MinGW program).
* by virtue of copying only the `sh.exe` and `sed.exe` executables, all other MSys programs will *still* display the same problem (because they drag in msys-1.0.dll, which seems to be the culprit), most notably including `ssh.exe` and `perl.exe`.

For the above reasons, I am afraid that it is not a solution because it introduces a whole new set of problems – even if it seems to work the problems for the blog poster.

On a positive note, I could imagine that these problems might be solved with the upcoming 64-bit Git for Windows based on MSys2 [*2*].

Related Articles

Calling .Net Framework and .Net Assemblies from PHP