[Bug] cmder loads very slowly under Windows

[minstyle]

Version Information

Cmder version: v1.3.21 (1.3.20.151)
Clink: v1.4.11
git: version 2.39.1.windows.1
ConEmu: 221218 [64] Stable

Operating system: Windows 10 Pro 22H2 (Build 19045.2486)

Cmder Edition

Cmder Full (with Git)

Description of the issue

Since the latest Windows 10 update 22H2, it takes 30 seconds or more for cmder to load. It also takes this long when creating new tab windows in cmder. The problem exists with different Windows 10 computers at different work spaces and locations (private, work and Home Office).

How to reproduce

No response

Additional context

No response

Checklist

• I have read the documentation.
• I have searched for similar issues and found none that describe my issue.
• I have reproduced the issue on the latest version of Cmder.
• I am certain my issues are not related to ConEmu, Clink, or other third-party tools that Cmder uses.

[mpitz]

Same here!

Cmder version: v1.3.21 (1.3.20.151)
Clink: v1.4.10.45c041
git: version 2.39.0.windows.1
ConEmu: 221218 [64] Stable

Operating system: Windows 11 Pro 22H2 (Build 22621.1105)

[Lari0]

Hi,
Same here , it takes 20 or more seconds with /f and close to 60 without /f .
Also tried adding variable of git location , this improves startup for few seconds.

Elapsed Time: 0:0:22.87 (22.87s total)

Microsoft Windows [Version 10.0.19045.2251] - Windows 10 Pro 22H2
cmder 1.3.20.151

[chrisant996]

I am using Cmder 1.3.21 Mini version, with Windows 10 Pro 22H2 19045.2486, and it takes about 2 seconds to start.

I have git for Windows installed, and Cmder finds it successfully.

[daxgames]

I can not duplicate this.

[WickedSilver]

I can not duplicate this.

Is there any thing we can do to help you to reproduce this?

[mpitz]

Don't know if it helps but starting Cmder I can see rotating cmd.exe and findstr.exe in the lower tab:

Happens on my Windows 10 Pro private PC and my Windows 11 Pro office PC. On the office PC the startup takes significant more time than on the Win 10 machine.

• Win 10: 10 sec
• Win 11: 30 sec

[daxgames]

@mpitz 10 seconds is too long. The difference between home and work pc does not surprise me at all. Work PCs are commonly reported as slower with Cmder.

[mpitz]

@daxgames maybe, but my work PCs has no extra firewall restrictions, I'am admin user. It's like a private PC.

[daxgames]

When I said I can not reproduce this I was in a hurry. The only Windows 10 I have tested on is version 10.0.19044 21H2.2486 and according to Windows Ulpdate is up to date.

I am running Windows 10 on a 8GB Virtualbox VM on an older I5 laptop with slow spindle HDD and even on this older system Cmder starts in 3.68 seconds.

I will try and find another system in my stack of old hardware and see what I have to try and reproduce but if I can't get the version you guys say the issue started at I'm not sure what to do.

[daxgames]

@mpitz I'm just telling you historical experience. It comes up a lot.

[js-compilatrum]

Version mini and full at Microsoft Windows [Version 10.0.22621.1105] is very slow. It was checked on 128 GB RAM, 13700 CPU so hardware should will not be issue here. Older version on laptop is extremaly fast in comparision.

[chrisant996]

Here are some ideas to try, to learn more about where the delay is coming from:

• Try using Task Manager or Process Explorer to observe what processes are using CPU during the 10-30 second delay. For example, it might show that some antivirus system is spending a lot of CPU.
• Try set PATH to check what the system path looks like. For example, if it has UNC paths in the system PATH then that will make network calls when searching to find executables, and that could introduce delays. Or there might be extra unexpected paths in the PATH that might slow things down.

[Dzoukr]

Don't know if it helps but starting Cmder I can see rotating cmd.exe and findstr.exe in the lower tab:

Happens on my Windows 10 Pro private PC and my Windows 11 Pro office PC. On the office PC the startup takes significant more time than on the Win 10 machine.

• Win 10: 10 sec
• Win 11: 30 sec

Absolutely the same here for me on Win 10 with cmder mini. I also tried to observe Task manager, but nothing significant there... Any idea what could cause it?

[chrisant996]

What does set PATH report? For this, please copy/paste the actual text, not a screenshot (screenshots are images, so the text is not accessible, and trying to transcribe it into actual text is a time-consuming and error-prone process).

I ask because I see multiple findstr calls in the .bat and .cmd scripts that are part of Cmder, and many of them involve trying to analyze the %PATH% variable. It could potentially be possible for certain content in the %PATH% to lead to various problems, so examining the %PATH% can be a constructive diagnostic step.

[andrej-dyck]

Same. I extracted cmder.zip on a fresh install of Win10 22H2, and it takes up to 50sec to start.

[daxgames]

1. Found a system and got Windows 10 22H2 installed.
2. Downloaded Cmder Full 1.3.21 from the cmder.app web site.
   • The version file in the archive says it is 1.3.20.151 and not 1.3.21. See [Bug] Download Links on https://cmder.app point to the wrong versions. #2818.
3. I unziped and ran cmder.exe.
   • Launch speed seemed normal to me for a first launch.
   • Git for windows did its initial install thing.
4. I added /t to the cmd::Cmder task, saved and relaunched. Had to do this twice for some reason???
5. Cmder started in less than 2 seconds.
   
6. Hardware is an older Intel i7 with 512Gb SSD and 16 GB RAM.

I cannot reproduce this issue.

I would love to see the output of path commands as requested above.

[andrej-dyck]

Here's some debug-output:

DEBUG(init.bat): Env Var - CMDER_ROOT=C:\<redacted-path>\Cmder

DEBUG(init.bat): Env Var - debug_output=1

DEBUG(init.bat): Looking for Git install root...

DEBUG(:read_version): Env Var - git_executable=C:\<redacted-path>\Cmder\vendor\git-for-windows\cmd\git.exe

DEBUG(:read_version): Env Var - GIT_VERSION_VENDORED=2.39.0.windows.1

DEBUG(:validate_version): ARGV[1]=VENDORED, ARGV[2]=2.39.0.windows.1

DEBUG(:parse_version): ARGV[1]=VENDORED, ARGV[2]=2.39.0.windows.1

DEBUG(:validate_version): Found Git Version for VENDORED: 2.39.0.windows.1

DEBUG(:read_version): Env Var - git_executable=C:\<redacted-path>\git-2.39.0\cmd\git.exe

DEBUG(:read_version): Env Var - GIT_VERSION_USER=2.39.0.windows.2

DEBUG(:get_user_git_version): get_user_git_version GIT_VERSION_USER: 2.39.0.windows.2

DEBUG(:validate_version): ARGV[1]=USER, ARGV[2]=2.39.0.windows.2

DEBUG(:parse_version): ARGV[1]=USER, ARGV[2]=2.39.0.windows.2

DEBUG(:validate_version): Found Git Version for USER: 2.39.0.windows.2

DEBUG(:compare_versions): Comparing:

DEBUG(:compare_versions): USER: 2.39.0.windows.2

DEBUG(:compare_versions): VENDORED: 2.39.0.windows.1

DEBUG(:compare_git_versions): campare versions_result: 1

DEBUG(init.bat): Using found Git '2.39.0.windows.2' from 'C:\<redacted-path>\git-2.39.0...

DEBUG(init.bat): Using Git from 'C:\<redacted-path>\git-2.39.0...

DEBUG(:enhance_path): Env Var INSIDE PATH C:\\<redacted-path>\\git-2.39.0\\cmd - found=1

DEBUG(:enhance_path): Env Var BEGIN PATH C:\\<redacted-path>\\git-2.39.0\\cmd - found=1

DEBUG(:enhance_path): Env Var INSIDE PATH C:\\<redacted-path>\\git-2.39.0\\mingw64\\bin - found=1

DEBUG(:enhance_path): Env Var END PATH C:\\<redacted-path>\\git-2.39.0\\mingw64\\bin - found=1

DEBUG(:enhance_path): Env Var INSIDE PATH C:\\<redacted-path>\\git-2.39.0\\usr\\bin - found=1

DEBUG(:enhance_path): Env Var END PATH C:\\<redacted-path>\\git-2.39.0\\usr\\bin - found=1

DEBUG(init.bat): Env Var - GIT_INSTALL_ROOT=C:\<redacted-path>\git-2.39.0

DEBUG(init.bat): Found Git in: 'C:\<redacted-path>\git-2.39.0'

DEBUG(:enhance_path): Env Var INSIDE PATH C:\\<redacted-path>\\Cmder\\vendor\\bin - found=0

DEBUG(:enhance_path): Env Var END PATH C:\\<redacted-path>\\Cmder\\vendor\\bin - found=0

DEBUG(:enhance_path): Appending 'C:\<redacted-path>\Cmder\vendor\bin'

DEBUG(:enhance_path): END Env Var - PATH=C:\<redacted-path>\Cmder\vendor\conemu-maximus5\ConEmu\Scripts;C:\<redacted-path>\Cmder\vendor\conemu-maximus5;C:\<redacted-path>\Cmder\vendor\conemu-maximus5\ConEmu;C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\wbin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Program Files\Intel\WiFi\bin\;C:\Program Files\Common Files\Intel\WirelessCommon\;C:\Program Files\dotnet\;C:\Program Files\Docker\Docker\resources\bin;;C:\<redacted-path>\git-2.39.0\bin;C:\<redacted-path>\git-2.39.0\cmd;C:\<redacted-path>\git-2.39.0\mingw64\bin;C:\<redacted-path>\git-2.39.0\usr\bin;C:\<redacted-path>\Gradle\gradle-7.6\bin;C:\<redacted-path>\Haskell\ghc-8.10.4\bin;C:\<redacted-path>\Java\jdk-17.0.2\bin;C:\<redacted-path>\JetBrains\scripts;C:\<redacted-path>\Kubernetes\bin;C:\<redacted-path>\Make\bin;C:\<redacted-path>\Maven\apache-maven-3.6.3\bin;C:\<redacted-path>\Node\node-18.13.0;C:\<redacted-path>\PHP\php-8.1.3;C:\<redacted-path>\PHP\composer;C:\<redacted-path>\Python\python-3.8.1;C:\<redacted-path>\Terraform;;C:\Users\<redacted>\AppData\Local\Microsoft\WindowsApps;C:\Users\<redacted>\.dotnet\tools;C:\<redacted-path>\Cmder\vendor\bin

DEBUG(:enhance_path): Env Var C:\\<redacted-path>\\Cmder\\vendor\\bin - found=1

DEBUG(:enhance_path_recursive): Env Var - add_path=

DEBUG(:enhance_path_recursive): Env Var - position=append

DEBUG(:enhance_path_recursive): Env Var - depth=0

DEBUG(:enhance_path_recursive): Env Var - max_depth=1

DEBUG(:enhance_path): Env Var INSIDE PATH C:\\<redacted-path>\\Cmder - found=0

DEBUG(:enhance_path): Env Var END PATH C:\\<redacted-path>\\Cmder - found=0

DEBUG(:enhance_path): Appending 'C:\<redacted-path>\Cmder'

DEBUG(:enhance_path): END Env Var - PATH=C:\<redacted-path>\Cmder\vendor\conemu-maximus5\ConEmu\Scripts;C:\<redacted-path>\Cmder\vendor\conemu-maximus5;C:\<redacted-path>\Cmder\vendor\conemu-maximus5\ConEmu;C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\wbin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Program Files\Intel\WiFi\bin\;C:\Program Files\Common Files\Intel\WirelessCommon\;C:\Program Files\dotnet\;C:\Program Files\Docker\Docker\resources\bin;;C:\<redacted-path>\git-2.39.0\bin;C:\<redacted-path>\git-2.39.0\cmd;C:\<redacted-path>\git-2.39.0\mingw64\bin;C:\<redacted-path>\git-2.39.0\usr\bin;C:\<redacted-path>\Gradle\gradle-7.6\bin;C:\<redacted-path>\Haskell\ghc-8.10.4\bin;C:\<redacted-path>\Java\jdk-17.0.2\bin;C:\<redacted-path>\JetBrains\scripts;C:\<redacted-path>\Kubernetes\bin;C:\<redacted-path>\Make\bin;C:\<redacted-path>\Maven\apache-maven-3.6.3\bin;C:\<redacted-path>\Node\node-18.13.0;C:\<redacted-path>\PHP\php-8.1.3;C:\<redacted-path>\PHP\composer;C:\<redacted-path>\Python\python-3.8.1;C:\<redacted-path>\Terraform;;C:\Users\<redacted>\AppData\Local\Microsoft\WindowsApps;C:\Users\<redacted>\.dotnet\tools;C:\<redacted-path>\Cmder\vendor\bin;C:\<redacted-path>\Cmder

DEBUG(:enhance_path): Env Var C:\\<redacted-path>\\Cmder - found=1

DEBUG(init.bat): Env Var - HOME=C:\Users\<redacted>

DEBUG(init.bat): Calling - C:\<redacted-path>\Cmder\config\user_profile.cmd

Elapsed Time: 0:0:45.32 (45.32s total)

[andrej-dyck]

Note that this behavior I had first experiened on Windows 10 22H1 when I updated Cmder from an older version. I don't know which version I had before, but with that, the startup-time was 1-2sec.

[d4k0]

Same problem here when I started Cmder today after I haven't used it for 2-3 weeks:

Output of set PATH:

Path=E:\Tools\Cmder\vendor\git-for-windows\cmd;E:\Tools\Cmder\vendor\conemu-maximus5\ConEmu\Scripts;E:\Tools\Cmder\vendor\conemu-maximus5;E:\Tools\Cmder\vendor\conemu-maximus5\ConEmu;C:\Program Files\Java\jdk1.8.0_361\bin;C:\Program Files\Common Files\Oracle\Java\javapath;C:\Program Files (x86)\Common Files\Oracle\Java\javapath;E:\Tools\Alacritty;E:\Tools\apache-ant-1.10.5\bin;C:\Users\*MyUsername*\AppData\Local\bin\NASM;D:\Program Files\CMake\bin;E:\Programme\Video\Konvertieren\FFmpeg;E:\Programme\Dokumente\AtomPortable\Tools\Node.js;E:\Tools\Cmder\vendor\git-for-windows\usr\bin;E:\Tools\Cmder\vendor\git-for-windows\bin;E:\Tools\Cmder;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\Program Files\Microsoft SQL Server\130\Tools\Binn\;C:\WINDOWS\System32\OpenSSH\;C:\Program Files\Crucial\Crucial Storage Executive;C:\Program Files\dotnet\;C:\Program Files\gs\gs9.56.1\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\WINDOWS\System32\OpenSSH\;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Users\*MyUsername*\.cargo\bin;E:\Program Files\Python\Python37\Scripts\;E:\Program Files\Python\Python37\;C:\Users\*MyUsername*\AppData\Local\Microsoft\WindowsApps;E:\Tools\Cmder\vendor\git-for-windows\mingw64\bin;E:\Tools\Cmder\vendor\bin
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
path_position=append

[chrisant996]

@d4k0 While this probably isn't responsible for the delay, that PATH variable has several duplicates:

• 3 copies of c:\windows
• 3 copies of c:\windows\system32
• 2 copies of c:\windows\system32\openssh
• 3 copies of c:\windows\system32\wbem
• 3 copies of c:\windows\system32\windowspowershell\v1.0

Repeated directories can slow down launching programs, by searching the directories multiple times. Cleaning up the variable might be generally useful, but the duplicate directories probably aren't causing 40 seconds of slowdown, so the cause is probably something else yet to be discovered.

In the meantime, if you clean that up, make a backup copy of the contents of the PATH variable first, so that it can be restored if something goes wrong while cleaning it up.

[chrisant996]

Can someone try downgrading to an older version of Cmder or ConEmu, and see if the problem goes away?

If downgrading ConEmu resolves the problem, then the issue is likely something in ConEmu, not Cmder.

If downgrading ConEmu doesn't resolve the problem, but downgrading Cmder resolves the problem, then there would be a possibility that the issue might be due to some recent change in the Cmder scripts.

[andrej-dyck]

I'll try it tomorrow. 👍

[chrisant996]

@DRSDavidSoft @daxgames cmder init debug logging can show elapsed time of the whole init. Is there a way to see times along the way, to help identify where delays occur?

[daxgames]

@andrej-dyck is there really something in your path worth redacting?

[andrej-dyck]

@andrej-dyck is there really something in your path worth redacting?

Yes. But all paths only use the English letters and some use a space in-between words.

[daxgames]

@chrisant996 not currently

[Hlsgs]

@chrisant996 I have an older version of mini that i haven't updated in a while and that used to work fine(1.3.16.1035 with conemu 210912). Problem manifests same as with a freshly downloaded version.

@daxgames I've cleaned my path and that didn't help, so that's not it. I'm also unable to replicate this in a fresh VM with an up to date W10. Tricky. I was going to ask the same as @chrisant996 about a timestamped log file...

[296951]

Looking at what it would take to add timestamps to the log.can't guarantee anything. My Bengals are playing and I am watching that. GO BENGALS - WOD-DEY!

[daxgames]

@chrisant996 so I should jut remove the error checking?

[pmsobrado]

@daxgames That would be nice, even if it's only a cosmetic thing, at least for this independent build :P

[daxgames]

@chrisant996 @pmsobrado Let me look at the linked issue more closely and figure out what to do. Not going to be able to immediately look at it though.

[pmsobrado]

No rush! Thanks!

[daxgames]

Fixed here when its finished building.

[pmsobrado]

Damn, what took you so long? 😄

Thanks!

[chrisant996]

@daxgames I added a comment in #2800.

• The simplest fix is to change the if errorlevel 1 ... to if errorlevel 2 ..., assuming that the %printerror% is wanted for Cmder logging purposes.
• Or removing these lines is fine, if the %printerror% wasn't needed for Cmder logging.

[daxgames]

@pmsobrado we aim to please!

[DRSDavidSoft]

@pmsobrado Sorry for the message, you can blame me for the false error message. I fixed it in the master, hopefully, @chrisant996 approves

[pmsobrado]

@DRSDavidSoft Don't you worry! I've left you some feedback on #2800 :)

[d4k0]

ESET has released a few new versions since January that significantly improved the problem. Here are a few results from me:

cmder 1.3.24:
With exception: 1.6s
Without exception: 3,0s

cmder 1.3.21:
With exception: 1,86s
Without exception: 3.4s

It's still a bit slower, but significantly better than before. I have therefore removed the exception for cmd.exe again.

At work we use Trellix (they were previously called McAfee Enterprise). A few months ago, there were the same long loading times with cmd.exe (though not until well after January), but recently the problem has also been eliminated. I remember clink giving an error message because of the long load time.

Can anyone confirm this?

[Marco-Sulla]

I have the same problem. ~20 seconds without /f, ~12 seconds with /f. I noticed no difference with cmder mini edition.

How can I trace in details the time each step of the init.bat takes?

I have:
Cmder version: 230724 x64 stable
Operating system: Windows 11 22H2
Cmder Edition: Full

[chrisant996]

@Marco-Sulla Slowness is typically something on the host computer that is inspecting every API call, such as Antivirus or Data Loss Prevention or security tools. This is more common on corporate managed systems, but also some Antivirus programs malfunction sometimes.

What Antivirus suites are on your machine? Do you have ESET? ESET's "Deep Behavioral Inspection" feature has had problems in the past where it introduced significant delays while starting programs.

[Marco-Sulla]

I added some time logs to the init.bat:
init.zip

The problem is here (10s wasted), but it makes no sense because there's no command between the logs:

enhance_path git end 2 10:26:41.66
enhance_path git end 3 10:26:46.04

git_locale end 2 10:26:46.11
endlocal start 10:26:50.10

[chrisant996]

Yes, that's interference from antivirus/etc.

There aren't any CMD commands between those two echo commands, but there is the end ) after finishing the if defined git_locale ( ... ) block that was just evaluated with enabledelayedexpansion. That ) triggers a bunch of system API calls and file IO for opening the .bat file again and parsing a next command, and getting/setting the console title, and a bunch of other minutia that involve system APIs.

The antivirus/etc software is intercepting one or more of the APIs and decides that it wants to do some extra processing, and the extra processing takes a bunch of time.

I agree that it doesn't make sense why that would be needed or take so long. But it's a bug or malfunction in the antivirus/etc software -- for whatever reason, it got confused into thinking it needed to be extra work.

You'd need to identify all the antivirus and DLP and corporate monitoring tools that are installed, and try to narrow down specifically which of them are going awry, and report the issue to the respective support team for whichever software(s) are involved. There's unfortunately nothing Cmder or ConEmu can do about this, because it's happening externally from them.

[Marco-Sulla]

I added init.bat to the Windows Defender exclusion list, but the start time continues to be 20s. Should I put other files or directories in exclusion list?

[DRSDavidSoft]

@Marco-Sulla either add the entire cmder_root directory as an exception, or temporary turn Defender's real time protection off to verify that the 20 second delay is gone.

[daxgames]

With eset nod people were adding cmd.exe to solve the slowness. I doubt adding the cmder root folder will do much to speed things up.

Edit: I do not recommend doing the above. I'm just letting you know what others have done to temporarily work around overly aggressive DLP/Anti-Virus apps until they are fixed.

[Crayder]

Sorta unproductive comment... but I just wanted to mention that this magically fixed itself for me. I never did the fix above. It just started loading like normal last week. Not even updated. Nothing with cmder or clink has changed on my PC in months. My only guess is something with windows updates.

[chrisant996]

Sorta unproductive comment... but I just wanted to mention that this magically fixed itself for me. I never did the fix above. It just started loading like normal last week. Not even updated. Nothing with cmder or clink has changed on my PC in months. My only guess is something with windows updates.

Caused/resolved by anti-virus updates. See earlier analysis and explanations.

[SMUsamaShah]

After every single command even a simple echo or cd it was starting a 2 cmd.exe and 1 git.exe (that i could see in status bar). Meaning this was adding delay of 1-2s after every single command. Not counting the initial console startup time here.

After reading comments, I replaced my cmder-full installation with cmder-mini (which excludes git). Now there isn't no delay after running each command.

[chrisant996]

@SMUsamaShah That's interesting...

What version of Cmder are you using?

In recent versions of Cmder, git.exe gets launched in the background and does not create any delay at all, no matter how long the git.exe command takes to run -- when the background git.exe finishes, then the prompt refreshes to show the new info.

(There are some configuration settings that can forcibly disable that, and force git.exe to run in the foreground and introduce delays. But since you didn't mention configuring those, I'm assuming they aren't the issue.)

You could consider trying recent pre-release builds of Cmder that are not published yet. They have some improvements, and it's been a while since an update to Cmder was published, so you might not have the improvements yet. If you look around in recent issues you can find links e.g. from daxgames.

[SMUsamaShah]

The cmder I replaced (moved to another folder) was Version 1.3.19.1181.
The cmder mini I am now using is Version 1.3.24.236.
Have git installed in Program Files already anyway.

I tried looking for a simple way to find out why its running those processes, debug logs don't tell this info. While writing this comment I ran procmon.exe. Then did a simple cd . (which is an alias to cd /d $*) on Version 1.3.19.1181. cd command completes, then does the other git related stuff.

Process Monitor shows cmd.exe being started with cmd.exe /c git --no-pager config cmder.status 2>nul, then it starts git --no-pager config cmder.status which runs git.exe again with same command but using git.exe from mingw64\bin dir. Same cmd and git processes run once again. And then my cd command finally completes.

[daxgames]

@chrisant996 @SMUsamaShah I am not certain the newest Cmder release includes background prompt refresh. Probably need to get a pre-rel!ase archive and try it.

[SMUsamaShah]

May be it does. Because if I go to a git directory I can see the same cmd.exe and git.exe being run on the status bar but they no longer halt my command. So they are running in background as they should. So may be the packaged git and separate git installation (Program Files) was causing some weird behaviour making it run in foreground for every command, even when i wasn't in a git based dir.

[chrisant996]

The cmder I replaced (moved to another folder) was Version 1.3.19.1181.
The cmder mini I am now using is Version 1.3.24.236.

That was the problem.

.19 had a bug that ran part of the git stuff in the foreground by accident.

Upgrading to .24 would solve the problem, because the fix was made between those versions.

In general, when an issue is encountered in a program, it's handy to check if the latest version fixes it.

[SMUsamaShah]

Right, Thanks. I checked for update within cmder but because it only checks for conemu updates, it fooled me into thinking I have up-to-date version of cmder too. Before writing down this comment I didn't know that right way to check cmder versions is to look into its folder and see the Version file. May be there is another way but I don't know about it.