Git bash startup is slow

[kjeremy]

Starting git bash from the start menu (for example) takes about 5 seconds enter a useable state. Doing the same in the git-1.9.5-preview release is virtually instantaneous.

This is a regression from the git-1.9.5-preview release.

[dscho]

Please follow the steps described in https://github.com/msysgit/msysgit/wiki/Diagnosing-why-Git-is-so-slow to diagnose the problem. It does not take 5 seconds here.

[calle2010]

For me starting git-bash.exe takes around 3 seconds (SSD, more than enough RAM). I tried the "set -x" at the mentioned Wiki page and everything is fast after the mintty window is shown.

Even if I start mintty.exe directly it takes 2-3 seconds before the window is shown.

Then I pulled my network cable. For some minutes mintty.exe started only after more than 10 seconds. Later, while network cable still pulled, it started instantaneously. So I guessed when mintty.exe starts some network lookup is tried.

What I found is that mintty opens an LDAP(?) connection (port 389) to one of my company's servers. This is closed after startup. It keeps open a listening UDP port on 127.0.0.1.

Note: The delay before mintty.exe window comes up happens only when starting it from Windows Explorer or cmd.exe command line. When I start mintty.exe from Git Bash it starts instantaneously.

A similar issue is described here: http://stackoverflow.com/questions/28410852/startup-is-really-slow-for-all-cygwin-applications

From first answer, solution 1, I took the two commands

$ mkpasswd -c > /etc/passwd
$ mkgroup -c > /etc/group

and entered those while running git-bash.exe. Even without the change to nsswitch.conf the issue is solved. I don't see LDAP connections anymore. git-bash.exe starts as fast as any other small Windows program. cmd.exe still starts faster, though.

Tip for the user that comes here to read how to speed up git-bash.exe: The fastest way to create another Git Bash window is to press Alt+F2 from the first Git Bash window.

[kjeremy]

Interesting... I'll try that out. They talk about it in the cygwin release notes: https://cygwin.com/ml/cygwin-announce/2015-02/msg00009.html

[kjeremy]

@calle2010 I tried the fix from your comment + the nsswitch configuration and results are not consistent. Sometimes it starts instantaneously and other times it takes 5-20 seconds.

I bet it's related to ldap somehow because if I'm on the work domain it tends to start up faster. Still this is a change from the latest stable.

[mscrivo]

@kjeremy I've got the exact same issue as you. Startup speed is very inconsistent, anywhere from 1s to 5s. The above tip did nothing for me. set -x and git trace do not help either as the delay occurs before either of those start spitting out info.

I am using Conemu and the startup delay only seems to happen there, but the delay never happened with 1.9.5.

I'm using: "set MSYSTEM=MINGW64 & "%ProgramFiles%\Git\usr\bin\sh.exe" --login -i" as my Conemu task command.

[dscho]

@mscrivo maybe setting HOME in addition to MSYSTEM would help?

[mscrivo]

@dscho Didn't help. Although, I just noticed in process explorer that when the delay happens, it's trying to connect to our ldap server and that connection hangs for a while occasionally. Which seems in line with what @calle2010 is saying above. Curious why that didn't work.

[mscrivo]

I just noticed @calle2010's command has a typo, he references "cpasswd", I changed the filename to "passwd" and that does indeed fix the problem!

[kjeremy]

It only fixed it until I disconnected from the domain and then the problem
came back. It seems intermittent.

On Tue, Jun 16, 2015 at 11:20 AM, mscrivo notifications@github.com wrote:

I just noticed @calle2010 https://github.com/calle2010's command has a
type, he references "cpasswd", I changed the filename to "passwd" and that
does indeed fix the problem!

—
Reply to this email directly or view it on GitHub
#193 (comment)
.

[calle2010]

I changed my comment to fix the typo.

[dscho]

Thank you all for the analysis. Based on it, I think the best way to fix this would be to introduce a new dbfast option for passwd and group in the nsswitch.conf file. The idea is to copy-edit the db handling and then limit it to the local machine and the current account (because we do not really need complete user/group data, in contrast to Cygwin).

[dscho]

This would be the way to tackle this issue:

• Build msys2-runtime from scratch: https://github.com/git-for-windows/git/wiki/Building-msys2-runtime
• Add "dbfast" handling here, here and in winsup/cygwin/passwd.cc
• Start implementing the "dbfast" handling by adding pwdgrp fields here and here, then adding handling in all the add_*_from_windows() and eventually patch fetch_account_from_windows()

Of course, all of this assumes that the problem actually is in that passwd/group handling.

Maybe a sensible first step would be to call Bash from a cmd.exe window via

cd <top-level>
usr\bin\strace -o strace.out usr\bin\bash.exe --login -i

(maybe running it without -o strace.out first to see where exactly it spends a lot of time)

[dscho]

Hrm. Apparently there is nobody willing to work on this except for me. But I have no way to reproduce because I have no machine that is connected to LDAP.

I fear that it will take more enthusiasm from a developer with access to a setup displaying the behavior in question.

Alternatively, if anybody would at least provide clear and simple instructions how to reproduce it on my side, that would be helpful.

[mscrivo]

My apologies, I've been meaning to dig into a bit more, at least to provide
more info but got busy. I can only repro this at work, so I'll try to get
back into it on Monday.

On Sat, Jun 20, 2015, 9:57 AM dscho notifications@github.com wrote:

Hrm. Apparently there is nobody willing to work on this except for me. But
I have no way to reproduce because I have no machine that is connected to
LDAP.

I fear that it will take more enthusiasm from a developer with access to a
setup displaying the behavior in question.

Alternatively, if anybody would at least provide clear and simple
instructions how to reproduce it on my side, that would be helpful.

—
Reply to this email directly or view it on GitHub
#193 (comment)
.

[dscho]

@mscrivo Thanks!

[mscrivo]

@dscho I have the strace.out. How can I get the file to you? I'd like to avoid dropping it here as it could have some sensitive info. Don't have time to come through it all.

[kostix]

I'm experiencing the same problem with RC4 just in exhibits itself in a more weird way: for me, running git diff with pager (stock less.exe shipped with GfW) resulted in some 20 seconds delay, consistent; running with paging disabled, via git --no-pager diff works instantaneously.

I've tried exporting PAGER=cat.exe with cat.exe being that one from Git ({gitdir}usr/bin/cat.exe) with the same result (which was really weird).

Also weird was the behaviour of setting PAGER to a path containing spaces or double quotes (to protect spaces): in both cases this hanged in the same way with sh.exe sitting there and waiting, just the outcome was different: on the pathname with spaces sh.exe finally failed, while on the double-quoted pathname it finally managed to run the pager. (Both cases seem like issues to discuss separately, but I digress).

So I was about to file a bug and read through existing bug reports. This one looked fishy, so I've discovered comment from @calle2010 and re-run my tests. The end result is that not only sh.exe tries to connect to both of the LDAP servers of my domain but less.exe and cat.exe (!) as well.

It appers that all these programs link to some library which unconditionally performs those passdb (or whatever) lookups for unknown reason. Hence I think the fix should probably at some deeper level, not just speeding up passwb lookups -- I fail to see what cat.exe might need from that source, and it also means supposedly all the stuff in usr/bin is affected.

I have finally tried putting cat.exe from the "coreutils" package of http://gnuwin32.sf.net under a directory whose pathname does not inlude spaces and speficied it as PAGER using set PAGER=c:/bin/cat.exe -- and git diff worked instantly.

[dscho]

@dscho I have the strace.out. How can I get the file to you? I'd like to avoid dropping it here as it could have some sensitive info. Don't have time to come through it all.

@mscrivo I am afraid you will have to do a little bit more than just throwing the problem my way.

[mscrivo]

Can you give me some pointers on what to look for in the strace output?
It's rather unwieldy and I'm not familiar with it at all. I was thinking
you would be familiar with it and would be able to spot the problem
immediately.

On Thu, Jul 9, 2015, 7:48 AM dscho notifications@github.com wrote:

@dscho https://github.com/dscho I have the strace.out. How can I get
the file to you? I'd like to avoid dropping it here as it could have some
sensitive info. Don't have time to come through it all.

@mscrivo https://github.com/mscrivo I am afraid you will have to do a
little bit more than just throwing the problem my way.

—
Reply to this email directly or view it on GitHub
#193 (comment)
.

[dscho]

Does the strace output not contain time stamps? The problem is that some call(s) take(s) long. That should be visible from the time stamps.

[mscrivo]

yeah the problem is the file is 27k lines and the output is not in a format that is conducive to formatting and sorting. Anyhow, I think I found the main culprit:

1839741 1855632 [main] bash 9832 pwdgrp::fetch_account_from_windows: line: <username:*:1126222:1049089:FirstName LastName,U-DOMAIN\username,S-1-5-21-3138815620-4253048750-3916773603-77646:/c/Users/home:/usr/bin/bash>
16860 1872492 [main] bash 9832 pwdgrp::fetch_account_from_windows: line: <Administrators:S-1-5-32-544:544:>
  372 1872864 [main] bash 9832 pwdgrp::fetch_account_from_windows: line: <Performance Log Users:S-1-5-32-559:559:>
  310 1873174 [main] bash 9832 pwdgrp::fetch_account_from_windows: line: <Remote Desktop Users:S-1-5-32-555:555:>
  316 1873490 [main] bash 9832 pwdgrp::fetch_account_from_windows: line: <Users:S-1-5-32-545:545:>
   53 1873543 [main] bash 9832 pwdgrp::fetch_account_from_windows: line: <INTERACTIVE:S-1-5-4:4:>
   55 1873598 [main] bash 9832 pwdgrp::fetch_account_from_windows: line: <CONSOLE LOGON:S-1-2-1:66049:>
   64 1873662 [main] bash 9832 pwdgrp::fetch_account_from_windows: line: <Authenticated Users:S-1-5-11:11:>
   76 1873738 [main] bash 9832 pwdgrp::fetch_account_from_windows: line: <This Organization:S-1-5-15:15:>
   76 1873814 [main] bash 9832 pwdgrp::fetch_account_from_windows: line: <CurrentSession:S-1-5-5-0-269626:4095:>
   80 1873894 [main] bash 9832 pwdgrp::fetch_account_from_windows: line: <LOCAL:S-1-2-0:66048:>
   82 1873976 [main] bash 9832 pwdgrp::fetch_account_from_windows: line: <CA:S-1-5-21-3138815620-4253048750-3916773603-1179:1049755:>
   83 1874059 [main] bash 9832 pwdgrp::fetch_account_from_windows: line: <High Mandatory Level:S-1-16-12288:405504:>

The first call is the most expensive and that is the one fetching my domain account.

another big one I found further down in the trace:

2697578 2697910 [main] bash 1268 child_copy: dll bss - hp 0x2F8 low 0x1802AE000, high 0x1802E6350, res 1

[dscho]

Okay, it seems that the default /etc/nsswitch.conf might be responsible, in particular this line:

db_enum: cache builtin

According to https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nsswitch builtin means that some accounts are read for backwards-compatibility. Could you try to replace the builtin in your /etc/nsswitch.conf by local and test whether it still takes such a long time?

another big one I found further down in the trace:

2697578 2697910 [main] bash 1268 child_copy: dll bss - hp 0x2F8 low 0x1802AE000, high 0x1802E6350, res 1

Yeah, unfortunately this is nothing we can do anything about: it is the POSIX emulation layer trying to reinstate the fork() semantics. All we can do is to avoid sub shells as much as possible.

[mscrivo]

Changing it to local didn't seem to make much of a difference. It still takes ~2s to startup, whereas with the passwd and group files in place it takes ~1s. With builtin or local startup times almost always look like this:

PS C:\Program Files\Git> Measure-Command {Start-Process .\usr\bin\bash.exe -ArgumentList "--login -i exit.sh" -wait}


Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 2
Milliseconds      : 17
Ticks             : 20172897
TotalDays         : 2.33482604166667E-05
TotalHours        : 0.00056035825
TotalMinutes      : 0.033621495
TotalSeconds      : 2.0172897
TotalMilliseconds : 2017.2897

with the passwd and group files in place, it's consistently looks like this:

PS C:\Program Files\Git> Measure-Command {Start-Process .\usr\bin\bash.exe -ArgumentList "--login -i exit.sh" -wait}


Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 1
Milliseconds      : 11
Ticks             : 10113675
TotalDays         : 1.17056423611111E-05
TotalHours        : 0.000280935416666667
TotalMinutes      : 0.016856125
TotalSeconds      : 1.0113675
TotalMilliseconds : 1011.3675

[dscho]

Changing it to local didn't seem to make much of a difference

Does it still spend such a lot of time at this step:

1839741 1855632 [main] bash 9832 pwdgrp::fetch_account_from_windows: line: <username:*:1126222:1049089:FirstName LastName,U-DOMAIN\username,S-1-5-21-3138815620-4253048750-3916773603-77646:/c/Users/home:/usr/bin/bash>

? If yes, I encourage you to look at the https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nsswitch page yourself and try other db_enum lines to try to fix it, rather than waiting for me to stab around with a stick in the dark.

[mscrivo]

Something strange happened. I tried none just for the heck of it, and it took about 8 seconds to startup. Then I tried all the other values and no matter which one I try now, including none it starts up in ~1s. So now I can't reproduce ... I'll keep trying and report back.

Edit: Problem came back (LDAP server was probably just really fast this morning), and none of the values work. The only thing that is consistently fast is making sure group and passwd exist.

[dscho]

The only thing that is consistently fast is making sure group and passwd exist.

What is the difference between the strace output with and without group/passwd?

[mscrivo]

The difference is that with the passwd/group files, this line:

1839741 1855632 [main] bash 9832 pwdgrp::fetch_account_from_windows: line: <username:*:1126222:1049089:FirstName LastName,U-DOMAIN\username,S-1-5-21-3138815620-4253048750-3916773603-77646:/c/Users/home:/usr/bin/bash>

does not appear in the trace. That line is the LDAP user I'm currently logged in with.

However, it still does enumerate the other builtin accounts (which takes quite a bit of time but nowhere near as much as the LDAP account), even when I set db_enum to none

[dscho]

Some findings for interested parties: /etc/group and /etc/passwd appear to be accessed in check_file() in winsup/cygwin/uinfo.cc. It appears that whenever check_file() is called and the user/group is not in the caches afterwards, a method is called that calls add_account_from_windows().

Oh, and @eckes your problem is pretty much unrelated to this ticket. Your problem is the extensive use of shell scripts, incurring a huge accumulated startup cost of Bash.

Trying to move this ticket forward: is there anybody able to give me access to an affected machine?

[kostix]

@dscho, I think I'll be able to put up a Win XP SP3 32-bit virtual instance for you. The problem is that it will have Cyrillic locale. Will you be OK with RDP connection to such a box? Please drop me a mail to kostix at 007spb.ru (in case you have xmpp connectivity, that's also a JID).

[dscho]

I took up @kostix' offer and will debug this issue myself starting the middle of next week. One particularly curious thing will be to find out whether the whole problem is caused by the db_gecos line (judging from reading this mail).

[trianglee]

My 2 cents -
I experienced the same slow-startup problem with various Cygwin binaries, and after some "strace"ing and Googling discovered that the only remedy that works for me is starting "cygserver" service on Windows (as noted on the 2nd option here http://stackoverflow.com/questions/28410852/startup-is-really-slow-for-all-cygwin-applications). Once started, the Cygwin problem is completely gone.
Unfortunately, this doesn't help with the Git bash case - Git binaries are still slow to start when not connected to to the corporate network.
Strace on Git bash's 'ls', for example, shows -
[main] ls 9684 client_request::make_request: cygserver un-available
Which appears to indicate this is actually the same problem.
I don't know enough about the internals to tell why the Cygwin service doesn't help in this case.
@dscho, I hope this can assist somewhat.

[dscho]

Okay, thanks to @kostix' excellent help, I could investigate a bit further. It appears as if the db_shell and the db_gecos settings are set overzealously by us.

Everybody with this problem: could you please replace these two lines in your /etc/nsswitch.conf:

db_shell: env windows cygwin desc
db_gecos: env windows cygwin desc

with these two lines:

db_shell: env windows
db_gecos: env

and test whether that lets the Git Bash start up quicker? Thanks.

[kostix]

@dcho, fixes the issue for me on my affected machine.

At least, when in Git Bash, its stock cat and the one from the GnuWin32 project work with exactly the same speed when I ask them to cat /c/boot.ini:

$ time /c/Program\ Files/GnuWin32/bin/cat.exe /c/boot.ini
[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional RU" /noexecute=optin /fastdetect

real    0m0.126s
user    0m0.015s
sys     0m0.031s

$ time cat /c/boot.ini
[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional RU" /noexecute=optin /fastdetect

real    0m0.079s
user    0m0.030s
sys     0m0.030s

(I'm still on RC4 here as it's a production box, but given the changelog of RC5, I think my testing still applies to RC5 as well.)

[mscrivo]

seems to do the trick. I'll report back if I see any issues as I use it today.

[Dirk1966]

I was not affected that much by the bug, but
Win7-64 with git-sdk32 and git-sdk64 (big Windows network environment)
and
Win10-64 with git-sdk64 (small Windows network environment)
and
Win10-32 with git-sdk32 (small Windows network environment)
seem to work at least as well, perhaps a slight speed up.

Unfortunately, I do not have any idea how to track the time well.

[kostix]

@Dirk1966, the time builtin of bash might help.

That's not an excellent measurement, of course, (because to have one, you'd have several hundreds/thousands iterations with averaging over them) but is OK for a rough estimation. See my comment above -- the basic idea is that instead of

git show $commit >/dev/null

you run

time git show $commit >/dev/null

to get bash print the execution timings after the process quits.

[dscho]

Thanks for the reports! I will make that change permanent in a few minutes/hours.

[trianglee]

@dscho, unfortunately, for me, the problem still persists with this fix.

Doing an strace, I still see -
[main] ls 17132 client_request::make_request: cygserver un-available
Or, sometimes -
[main] ls 14832 dtable::extend: size 32, fds 0x18030DA50

These two only happen when I'm not connected to the corporate VPN, When connected, everything is fine.

(note that with Cygwin I solved a similar problem by installing cygserver as a Windows service).

[dscho]

@trianglee is it still taking a long time due to querying ActiveDirectory?

[dscho]

@trianglee or is it just dancing with a non-existing cygserver instance just because, and just continuing the quick route after not finding any?

[kjeremy]

@trianglee That's what I was seeing after disconnecting from our corporate network. See: #193 (comment)

I have yet to test this particular fix.

[trianglee]

@dscho, I honestly don't know. Looking at an strace output with and without the delay, things appear very similar - aside of the 18 seconds delay. It isn't clear where it is coming from.
It appears as if there is some timeout that expires, and something is caching this result for some time after - so additional activations of the binary don't exhibit the delay.

Here is an execution, with a delay -

00:00:00 [main] echo 340 transport_layer_pipes::connect: Try to connect to named pipe: \\.\pipe\msys-1888ae32e00d56aa-lpc
00:00:00 [main] echo 340 transport_layer_pipes::connect: Error opening the pipe (2)
00:00:00 [main] echo 340 client_request::make_request: cygserver un-available
--- Process 340 loaded C:\Windows\System32\advapi32.dll at 000007FEFEAB0000
--- Process 340 loaded C:\Windows\System32\msvcrt.dll at 000007FEFE5D0000
--- Process 340 loaded C:\Windows\System32\sechost.dll at 000007FEFEE80000
--- Process 340 loaded C:\Windows\System32\rpcrt4.dll at 000007FEFE1F0000
--- Process 340 thread 14820 created
--- Process 340 loaded C:\Windows\System32\netapi32.dll at 000007FEFA300000
--- Process 340 loaded C:\Windows\System32\netutils.dll at 000007FEFC030000
--- Process 340 loaded C:\Windows\System32\srvcli.dll at 000007FEFC7B0000
--- Process 340 loaded C:\Windows\System32\wkscli.dll at 000007FEFA270000
--- Process 340 loaded C:\Windows\System32\logoncli.dll at 000007FEFC240000
--- Process 340 thread 8836 created
00:00:18 [main] echo 340 mount_info::conv_to_posix_path: conv_to_posix_path (C:\Users\XXX, no-keep-rel, no-add-slash)
00:00:18 [main] echo 340 normalize_win32_path: C:\Users\XXX = normalize_win32_path (C:\Users\XXX)

And here is another one, attempted right after, without a delay -

00:00:00 [main] echo 16484 transport_layer_pipes::connect: Try to connect to named pipe: \\.\pipe\msys-1888ae32e00d56aa-lpc
00:00:00 [main] echo 16484 transport_layer_pipes::connect: Error opening the pipe (2)
00:00:00 [main] echo 16484 client_request::make_request: cygserver un-available
--- Process 16484 loaded C:\Windows\System32\advapi32.dll at 000007FEFEAB0000
--- Process 16484 loaded C:\Windows\System32\msvcrt.dll at 000007FEFE5D0000
--- Process 16484 loaded C:\Windows\System32\sechost.dll at 000007FEFEE80000
--- Process 16484 loaded C:\Windows\System32\rpcrt4.dll at 000007FEFE1F0000
--- Process 16484 thread 14780 created
--- Process 16484 loaded C:\Windows\System32\netapi32.dll at 000007FEFA300000
--- Process 16484 loaded C:\Windows\System32\netutils.dll at 000007FEFC030000
--- Process 16484 loaded C:\Windows\System32\srvcli.dll at 000007FEFC7B0000
--- Process 16484 loaded C:\Windows\System32\wkscli.dll at 000007FEFA270000
--- Process 16484 loaded C:\Windows\System32\logoncli.dll at 000007FEFC240000
--- Process 16484 thread 14364 created
00:00:00 [main] echo 16484 mount_info::conv_to_posix_path: conv_to_posix_path (C:\Users\XXX, no-keep-rel, no-add-slash)
00:00:00 [main] echo 16484 normalize_win32_path: C:\Users\XXX = normalize_win32_path (C:\Users\XXX)

And if I try yet another one a minute later, it would again exhibit the delay.

All of that only happens when not connected to the corporate network. When connected, there is never a delay.

I'm painfully aware of the inaccuracy of these observations...

[trianglee]

One extra note - the nsswitch.conf suggested change does improve things - without it, the observed delay is of 36 seconds, and with it - only 18 seconds.
Having to guess, I'd say it eliminates one access to the DC, but leaves another...

[dscho]

@trianglee do you use 32-bit or 64-bit Windows? In case you use 32-bit, would you mind backing up your usr\bin\msys-2.0.dll and replacing it with https://dscho.cloudapp.net/userContent/dscho/msys-2.0.dll, then run usr\bin\bash.exe --login -i from a cmd window? (In case the ActiveDirectory/LDAP connection is attempted, you would see more than just af output before the shell prompt.)

[johnsolver]

Personally on x64 connected to AD experiencing the same issue.

Changed nsswitch.conf to
passwd: files # db
group: files # db

and
db_shell: env windows
db_gecos: env

No noticeable change, first activation takes a long time, subsequent ones are pretty fast (caching as someone noted).

Non cached:

14996206 15003698 [main] bash 4820 cygheap_user::ontherange: what 2, pw 0x18030CF28
...
15071829 15072257 [main] bash 3672 child_copy: dll bss - hp 0x214 low 0x1802AF000, high 0x1802E7350, res 1

Cached:

 1708    9024 [main] bash 1072 cygheap_user::ontherange: what 2, pw 0x18030CF28
...
78662   79087 [main] bash 5208 child_copy: dll bss - hp 0x214 low 0x1802AF000, high 0x1802E7350, res 1

Actually there are quite a few lines that look like
15149282 15149703 [main] bash 2936 child_copy: dll bss - hp 0x228 low 0x1802AF000, high 0x1802E7350, res 1

[trianglee]

@dscho, Unfortunately, I'm on 64-bit Windows 7.

[dscho]

Changed nsswitch.conf to
passwd: files # db
group: files # db

and
db_shell: env windows
db_gecos: env

@johnsolver I think you also want to set db_home: env windows...

Unfortunately, I'm on 64-bit Windows 7.

@trianglee please note that you could have just downloaded the 32-bit portable Git and tried with that one. Having said that, I just built and uploaded a 64-bit version (but you will have to change the filename appropriately): https://dscho.cloudapp.net/userContent/dscho/msys-2.0-64.dll

[johnsolver]

In case the ActiveDirectory/LDAP connection is attempted, you would see more than just af output before the shell prompt.

I tried it and received 3 af one after the other, with a delay before the first appeared.

I think you also want to set db_home: env windows

Doesn't help, as in behaves the same way

[dscho]

@johnsolver I guess we are at an impasse now... unless you can build and patch msys-2.0.dll yourself to investigate further.