$ git --version --build-options
git version 2.23.0.windows.1
cpu: x86_64
built from commit: 4db2e5cc9e1522131a039cbad3970f147a39f0ce
sizeof-long: 4
sizeof-size_t: 8
$ cmd.exe /c ver
Microsoft Windows [Version 10.0.18362.388]
# One of the following:
> type "C:\Program Files\Git\etc\install-options.txt"
> type "C:\Program Files (x86)\Git\etc\install-options.txt"
> type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt
Editor Option: VisualStudioCode
Custom Editor Path:
Path Option: CmdTools
SSH Option: OpenSSH
Tortoise Option: false
CURL Option: OpenSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Enabled
Enable Builtin Interactive Add: Enabled
This first happened when I tried to install the downloaded installer on top of my previous version. Then i uninstalled it, and rebooted. Then tried to reinstall. It always gives me the same errors during installation.
MINGW64 Bash
During installation of downloaded installer, it gave a bunch of "Unable to set system config" errors. For example like this but a bunch more:


Many similar errors.
I expected it to install cleanly without issue, as it has before on other systems and on this system with a previous version.
Constant "Unable to set system config" errors. I even tried running the installer as Admin (even though I'm admin on my account (this is a personal computer)). I tried installing it to other locations. Still the same problems.
Not repository related. Just the Git for Windows installation media.
Basically the same issue as this person had: SuperUser - Reinstalling Git on Windows
Do you see the same issue with the installer from https://github.com/git-for-windows/git/releases/tag/v2.24.0-rc2.windows.1 i.e. with the latest pre-release (I don't)?
Do you see the same issue with the installer from https://github.com/git-for-windows/git/releases/tag/v2.24.0-rc2.windows.1 i.e. with the latest pre-release (I don't)?
Yea I just tried it and it's exactly the same. It seems to be installing everything fine, except the files that go in /Git/mingw64/etc like .gitattributes and .gitconfig
I can make them manually. But... that doesn't really solve the problem. I updated my son's computer with the official release without issue. Updating mine presents this issue. It's like it doesn't have permission to write those files.
@dscho Is there a log for installation that i can get and share that will show more of what is happening and whether there is a permissions error and why?
Might not be related but Cannot read/write system config seems a bit applicable. Because when I go to C:ProgramDataGit there is a config file there... literally named config only. So i don't know. Just trying to track something down.
Do you see the same issue with the installer from https://github.com/git-for-windows/git/releases/tag/v2.24.0-rc2.windows.1 i.e. with the latest pre-release (I don't)?
Yea I just tried it and it's exactly the same. It seems to be installing everything fine, except the files that go in /Git/mingw64/etc like .gitattributes and .gitconfig
Hmpf.
In that StackOverflow post (which I don't monitor for bug reports, as we have a fine bug tracker right here), it suggests that maybe there is an inaccessible C:\.config folder or some such? Do you have something like that?
No, i don't know what the C:.config is about. That comment seems completely out of no where.
I only reference the SO post to show that someone else had the issue and some more screen shots of it.
after installing, and clicking through all the errors, if i open git-bash and type git config --system --list it says:
fatal: unable to read config file 'C:/Program Files/Git/etc/gitconfig': No such file or directory
and it's right, there isn't one there, and it's always previously been installed at C:/Program Files/Git/mingw64/etc/gitconfig .
So then I did git config --system user.name "me" and there was no error, and I liked in the /Git/etc and there was a new gitconfig file with that key.
It's all very confusing. A brand new installation of 2.23 on a freshly installed computer installed the system config in the /mingw64/etc folder, not the /Git/etc/ folder. So why is my installation looking there for it?
I think the C:\config issue is from people having an environmental variable HOME with that path set. Not the case here.
I think it'd be helpful in those error messages if it also said the path of the file it was trying to access to narrow down where it's looking for the file... and then maybe why that file wasn't or couldn't be created.
I tried installing Git.2.22.0-64 and it gave me the same error. However, when I ran git-bash.exe and entered git config --system --list it said:
fatal: unable to read config file 'C:/Program Files/Git/mingw64/etc/gitconfig': No such file or directory
But when I did the same thing with 2.23 or 2.24, it said as I previously stated. /Git/etc/gitconfig .. so not sure why it's looking in a different place in either version. But 2.22 is looking where I would expect... but it still has the error on install.
it's always previously been installed at C:/Program Files/Git/mingw64/etc/gitconfig .
Yes, that changed in v2.24.0, and is probably a red herring in this context.
Understood. So what can I do to help track down the issue?
So what can I do to help track down the issue?
@gaetawoo I hope we can get to the bottom of this. The first two things we need to figure out:
C:\Program Files\Git\etc exist at the time this error is shown,To answer the first question, please run the installer again, and when that first error message appears, open an Explorer and look for that folder.
To answer the second question, I _think_ it would be enough to run Process Monitor while the installation is running, ideally only accumulating events while the installer is running, right until the error message is shown. There should be something informative in the logs (you can use the Ctrl+F keyboard shortcut to search the logs, I think, and I would look for --system if I were you).
- does
C:\Program Files\Git\etcexist at the time this error is shown,
Yes, it does exist before the error is shown and during and after.
- what is the _exact_ command-line that is executed, and under which account.
I ran Process Monitor and filtered it so only the Git install related events were saved. I've uploaded them to a Drive folder and you can access it here:
https://drive.google.com/open?id=1oB62_IT0NtFuDEwUW7h3yt1MnaW8Qg-b
In that folder you can find a native Process Monitor formatted log (so you'd need Process Monitor to view it) and the csv version of the same log. I did search by '--system' and the results are interesting. You can see where it's trying to write certain keys to the config file, you can see where it writes out to the .err file "specified path not found" and a few other NAME NOT FOUND errors... Most are towards the end, fyi.
I can't see a specific reason why there is an issue but maybe you can.
In that log, I cannot really see where there was the break in the time line that would reflect a message box being shown...
Could you try to see whether there is anything interesting in the files that _should_ have been written by the invocation (e.g. PID: 4628, Command line: "C:\WINDOWS\system32\cmd.exe" /C .\mingw64\bin\git.exe config --system "core.editor" "\"C:\\Program Files\\Microsoft VS Code\\Code.exe\" --wait" >"C:\Users\Jeremiah\AppData\Local\Temp\is-0MPS7.tmp\config-set.out" 2>"C:\Users\Jeremiah\AppData\Local\Temp\is-0MPS7.tmp\config-set.err")? That temporary directory will be deleted as soon as the installer finishes, therefore you will want to look at it while the message box is shown.
Here is a link to a fresh set of event logs:
https://drive.google.com/open?id=1BR055ckCIeD_5-yrWXRB7oMOCnImYOC3
I also included the files that were in the temp directory during the error messages. This is a symbolic link too but of course that doesn't upload.
During the install, I was watching the event log in Process Monitor live, and I saw it accessing the Temp directory and writing to files. I went to that directory, inspected the files (permissions, content) and nothing seemed strange except that nothing was getting written into config-set.out, but it was writing to config-set.err The system cannot find the path specified..
I also waited longer between error message modals so you should be able to see that now. In this case the directory was C:\Users\Jeremiah\AppData\Local\Temp\is-5U3LO.tmp\.
I hope this helps some how. I really wish I could understand why it's not writing to the .out file.
Puzzling, very, very puzzling.
First of all, as much as I tried, I could not find any trace of the spawned cmd.exe PID (e.g. 12064).
That those config-set.out and config-set.err files exist suggests that cmd was run all right, though.
The error message "The system cannot find the path specified." is another puzzle. It typically means that cmd.exe _itself_ was not found, which is strange. Granted, it should be shimmed to C:\Windows\SysWOW64\cmd.exe because Git for Windows' installer is a 32-bit program (so that the same installer can be run both on 32-bit and 64-bit Windows), but that file _should_ exist, and how else would the output be redirected?
Besides, there is a CreateFileMapping event targeting that cmd.exe and it reports SUCCESS. And the symlink test works, and that executed "C:\WINDOWS\system32\cmd.exe" /c mklink /d "C:\Users\Jeremiah\AppData\Local\Temp\is-5U3LO.tmp\symbolic link" "C:\Users\Jeremiah\AppData\Local\Temp\is-5U3LO.tmp" >"C:\Users\Jeremiah\AppData\Local\Temp\is-5U3LO.tmp\symlink test.txt"
At first I thought that maybe .\mingw64\bin\git.exe cannot be launched for some reason, but that should result in a different error message:
'.\mingw64\bin\git.exe' is not recognized as an internal or external command,
operable program or batch file.
But then, the sslCAInfo problem was the first one you saw, right? The log, however, shows that "C:\WINDOWS\system32\cmd.exe" /C .\mingw64\bin\git.exe config -l -z -f "C:\ProgramData\Git\config" >"C:\Users\Jeremiah\AppData\Local\Temp\is-5U3LO.tmp\git-config-get.txt" was launched first, and the file was read successfully (even if its length is 0, apparently).
Yet _more_ puzzling is that the second ProcessCreate reports success on launching "C:\WINDOWS\system32\cmd.exe" /C .\mingw64\bin\git.exe config -l -z --system >"C:\Users\Jeremiah\AppData\Local\Temp\is-5U3LO.tmp\git-config-get.txt".
But maybe both calls actually failed, with "The system cannot find the path specified"?
For the moment, I am out of ideas, except maybe that some overzealous anti-malware might interfere (because that mingw64\bin\git.exe was _just_ written by the installer) ...
I just saw this upgrading to Git 2.24.0.2. The only thing strange about my system compared to previous installs is that I still had a modified "C:Program FilesGitmingw64bingitk" and a copy of the old version at "C:Program FilesGitmingw64bingitk-bak" from testing the fix for https://github.com/git-for-windows/git/issues/2390
I noticed that at the end I was prompted to restart my computer -- I don't recall git prompting me to do that after an upgrade before.
Possibly related, I still had gitk open in notepad++.
I might have still had one of the directories open in explorer as well.
After the reboot git --version showed the .2 update.
I downloaded the installer from https://gitforwindows.org/, ran it, and it completed without errors. git --version also showed the .2 update.
First of all, as much as I tried, I could not find any trace of the spawned cmd.exe PID (e.g. 12064).
In the csv, line 187177 has the following entry:
"21:54:46.7416448","Git-prerelease-2.24.0.rc2.windows.1-64-bit.tmp","21208","Process Create","C:\WINDOWS\system32\cmd.exe","SUCCESS","PID: 12064, Command line: ""C:\WINDOWS\system32\cmd.exe"" /C .\mingw64\bin\git.exe config --system ""http.sslcainfo"" ""/ssl/certs/ca-bundle.crt"" >""C:\Users\Jeremiah\AppData\Local\Temp\is-5U3LO.tmp\config-set.out"" 2>""C:\Users\Jeremiah\AppData\Local\Temp\is-5U3LO.tmp\config-set.err"""
Is that what you mean or do you mean something else?
On line 187267 i see:
"CreateFileMapping","C:\Windows\System32\cmd.exe","FILE LOCKED WITH ONLY READERS",
On line 187265 i see:
"RegOpenKey","HKLM\Software\Microsoft\Wow64\x86\xtajit","NAME NOT FOUND","Desired Access: Query Value"
Line 187278 has:
"21:57:59.7927031","Git-prerelease-2.24.0.rc2.windows.1-64-bit.tmp","21208","Process Create","C:\WINDOWS\system32\cmd.exe","SUCCESS","PID: 15864, Command line: ""C:\WINDOWS\system32\cmd.exe"" /C .\mingw64\bin\git.exe config --system ""http.sslBackend"" ""openssl"" >""C:\Users\Jeremiah\AppData\Local\Temp\is-5U3LO.tmp\config-set.out"" 2>""C:\Users\Jeremiah\AppData\Local\Temp\is-5U3LO.tmp\config-set.err"""
I have no anti-malware other than Windows Defender with is part of the OS. I could try installing with that disabled. But... that'd be crazy if that was the issue.
First of all, as much as I tried, I could not find any trace of the spawned cmd.exe PID (e.g. 12064).
In the csv, line 187177 has the following entry:
"21:54:46.7416448","Git-prerelease-2.24.0.rc2.windows.1-64-bit.tmp","21208","Process Create","C:\WINDOWS\system32\cmd.exe","SUCCESS","PID: 12064, Command line: ""C:\WINDOWS\system32\cmd.exe"" /C .\mingw64\bin\git.exe config --system ""http.sslcainfo"" ""/ssl/certs/ca-bundle.crt"" >""C:\Users\Jeremiah\AppData\Local\Temp\is-5U3LO.tmp\config-set.out"" 2>""C:\Users\Jeremiah\AppData\Local\Temp\is-5U3LO.tmp\config-set.err"""Is that what you mean or do you mean something else?
I meant something else: this shows only an event from the process that spawned the cmd.exe process, but I am completely missing any events from that spawned cmd.exe process...
At this point, I think the only way forward is for you to build a custom installer that tries to call the command "manually", and then play with variations of it to figure out what is going on.
Clone https://github.com/git-for-windows/build-extra and then compile with build-extra\installer\InnoSetup.exe ISCC.exe cmd-test.iss where cmd-test.iss looks like this:
[Setup]
AppName=CmdTest
AppVersion=0.0
WizardStyle=modern
DefaultDirName=C:\My Program
PrivilegesRequired=lowest
#define MINGW_BITNESS 64
[Code]
procedure LogError(Msg:string);
begin
MsgBox(Msg,mbError,MB_OK);
Log(Msg);
end;
var
AppDir:String;
function ShellQuote(Value:String):String;
begin
// Sadly, we cannot use the '\'' trick used throughout Git's
// source code, as InnoSetup quotes those in a way that
// git.exe does not understand them.
//
// So we try to imitate quote_arg_msvc() in Git's
// compat/mingw.c instead: \ => \\, followed by " => \",
// then surround with double quotes.
StringChangeEx(Value,#92,#92+#92,True);
StringChangeEx(Value,#34,#92+#34,True);
Result:=#34+Value+#34;
end;
function ReadFileAsString(Path:String):String;
var
Contents:AnsiString;
begin
if not LoadStringFromFile(Path,Contents) then
Result:='(no output)'
else
Result:=Contents;
if (Length(Result)>0) and (Result[Length(Result)]=#10) then
SetLength(Result,Length(Result)-1);
if (Length(Result)>0) and (Result[Length(Result)]=#13) then
SetLength(Result,Length(Result)-1);
end;
function GitSystemConfigSet(Key,Value:String):Boolean;
var
i:Integer;
OutPath,ErrPath:String;
begin
OutPath:=ExpandConstant('{tmp}\config-set.out');
ErrPath:=ExpandConstant('{tmp}\config-set.err');
if (Value=#0) then begin
if Exec(ExpandConstant('{cmd}'),'/C .\{#MINGW_BITNESS}\bin\git.exe config --system --unset '+Key+' >'+#34+OutPath+#34+' 2>'+#34+ErrPath+#34,
AppDir,SW_HIDE,ewWaitUntilTerminated,i) And ((i=0) Or (i=5)) then
// exit code 5 means it was already unset, so that's okay
Result:=True
else begin
LogError('Unable to unset system config "'+Key+'": exit code '+IntToStr(i)+#10+#13+ReadFileAsString(OutPath)+#10+#13+'stderr:'+#10+#13+ReadFileAsString(ErrPath));
Result:=False
end
end else if Exec(ExpandConstant('{cmd}'),'/C .\{#MINGW_BITNESS}\bin\git.exe config --system '+ShellQuote(Key)+' '+ShellQuote(Value)+' >'+#34+OutPath+#34+' 2>'+#34+ErrPath+#34,
AppDir,SW_HIDE,ewWaitUntilTerminated,i) And (i=0) then
Result:=True
else begin
LogError('Unable to set system config "'+Key+'":="'+Value+'": exit code '+IntToStr(i)+#10+#13+ReadFileAsString(OutPath)+#10+#13+'stderr:'+#10+#13+ReadFileAsString(ErrPath));
Result:=False;
end;
end;
function InitializeSetup(): Boolean;
begin
AppDir:='C:\Program Files\Git';
if GitSystemConfigSet('cmdtest','success') then
MsgBox('Could set the system config correctly.',mbInformation,MB_OK)
else
MsgBox('Failed to set `cmdtest` in the system config.',mbError,MB_OK);
Result:=False;
end;
Oh wait, I get the same error message now! Let me try a few things and I'll come back to you.
Okay, so the reason I got this error message:

was that I had defined MINGW_BITNESS incorrectly: instead of the correct 'mingw64', I defined it to 64.
So this is somewhat good news! I now have an idea what might be going wrong in your setup: maybe you have a Virtual Store where all the things you "write" into C:\Program Files\Git go? In that case, I think cmd.exe would indeed be unable to find the specified path.
FWIW this is the cmd-test.iss with which I verified that it actually works on my machine, and which I suspect will still fail in your setup (I adjusted a bit more, for example it runs elevated now, and it uses a valid config key):
[Setup]
AppName=CmdTest
AppVersion=0.0
WizardStyle=modern
DefaultDirName=C:\My Program
PrivilegesRequired=none
#define MINGW_BITNESS 'mingw64'
[Code]
procedure LogError(Msg:string);
begin
MsgBox(Msg,mbError,MB_OK);
Log(Msg);
end;
var
AppDir:String;
function ShellQuote(Value:String):String;
begin
// Sadly, we cannot use the '\'' trick used throughout Git's
// source code, as InnoSetup quotes those in a way that
// git.exe does not understand them.
//
// So we try to imitate quote_arg_msvc() in Git's
// compat/mingw.c instead: \ => \\, followed by " => \",
// then surround with double quotes.
StringChangeEx(Value,#92,#92+#92,True);
StringChangeEx(Value,#34,#92+#34,True);
Result:=#34+Value+#34;
end;
function ReadFileAsString(Path:String):String;
var
Contents:AnsiString;
begin
if not LoadStringFromFile(Path,Contents) then
Result:='(no output)'
else
Result:=Contents;
if (Length(Result)>0) and (Result[Length(Result)]=#10) then
SetLength(Result,Length(Result)-1);
if (Length(Result)>0) and (Result[Length(Result)]=#13) then
SetLength(Result,Length(Result)-1);
end;
function GitSystemConfigSet(Key,Value:String):Boolean;
var
i:Integer;
OutPath,ErrPath:String;
begin
OutPath:=ExpandConstant('{tmp}\config-set.out');
ErrPath:=ExpandConstant('{tmp}\config-set.err');
LogError('/C .\{#MINGW_BITNESS}\bin\git.exe config --system '+ShellQuote(Key)+' '+ShellQuote(Value)+' >'+#34+OutPath+#34+' 2>'+#34+ErrPath+#34);
if (Value=#0) then begin
if Exec(ExpandConstant('{cmd}'),'/C .\{#MINGW_BITNESS}\bin\git.exe config --system --unset '+Key+' >'+#34+OutPath+#34+' 2>'+#34+ErrPath+#34,
AppDir,SW_HIDE,ewWaitUntilTerminated,i) And ((i=0) Or (i=5)) then
// exit code 5 means it was already unset, so that's okay
Result:=True
else begin
LogError('Unable to unset system config "'+Key+'": exit code '+IntToStr(i)+#10+#13+ReadFileAsString(OutPath)+#10+#13+'stderr:'+#10+#13+ReadFileAsString(ErrPath));
Result:=False
end
end else if Exec(ExpandConstant('{cmd}'),'/C .\{#MINGW_BITNESS}\bin\git.exe config --system '+ShellQuote(Key)+' '+ShellQuote(Value)+' >'+#34+OutPath+#34+' 2>'+#34+ErrPath+#34,
AppDir,SW_HIDE,ewWaitUntilTerminated,i) And (i=0) then
Result:=True
else begin
LogError('Unable to set system config "'+Key+'":="'+Value+'": exit code '+IntToStr(i)+#10+#13+ReadFileAsString(OutPath)+#10+#13+'stderr:'+#10+#13+ReadFileAsString(ErrPath));
Result:=False;
end;
end;
function InitializeSetup(): Boolean;
begin
AppDir:='C:\Program Files\Git';
if GitSystemConfigSet('cmd.test','success') then
MsgBox('Could set the system config correctly.',mbInformation,MB_OK)
else
MsgBox('Failed to set `cmdtest` in the system config.',mbError,MB_OK);
Result:=False;
end;
Ooooo... I sent you events filtered for only the git-for Windows. But I should include the cmd events too. I'll do that.
That's strange about the virtual store. I'm running the latest version of Windows 10. There hasn't been another operating system on this machine (except earlier versions of 10). I even ran the installer as admin. Same thing happened. Anyway, I'll try your custom installer as soon as I get a chance.
That's strange about the virtual store.
It's only a hunch... I am not all that certain that this is the culprit, but it _does_ look as if cmd.exe (the 32-bit version, that is) does not find the git.exe that the installer thinks it _just_ wrote.
Hi, there.
I've experienced this. And, found this symptom comes from uninstalling 'miniconda' or 'anaconda'. Which leaves an undelete registry entry.
[HKEY_CURRENT_USERSoftwareMicrosoftCommand Processor]
"AutoRun"=hex(2):...
Delete this entry will solve the problem.
And, I found that Git v2.21.0 is the last version that can be installed without any trouble when this symptom happened.
Hope that will help you.
@MagicJack Yep, that worked for me! Amazing. How did you figure that out?
I guess the best way to fix this would be to see what the git-for-windows installer behavior is different from 2.21 to later with respect to that registry entry... or what happens when the installer is presumably running those commands in a background process and that command process wants to call the autorun value.
I guess the best way to fix this would be to see what the git-for-windows installer behavior is different from 2.21 to later with respect to that registry entry...
It is not that it does anything with the registry entry; Instead, it runs git config through cmd so that the output can be redirected. And according to https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/cmd, cmd runs those AutoRun commands by default. Unless /d is used. Which is what I think we should do.
@MagicJack before I forget completely: thank you _so_ much for investigating.
Yea that's a good solution. Thank you both! Never would have thought. Really curious how you came about discovering that.
I kicked off a build with the fix. Could I ask y'all to download and test the installer-x86_64 artifact (which contains the .exe) from https://dev.azure.com/git-for-windows/git/_build/results?buildId=63871&view=artifacts&type=publishedArtifacts ?
I tested it. It didn't have any issues. I then installed the 2.28 version and it had the previous issues. I installed the 2.29 over it again and no issues.
@gaetawoo excellent! This is now fixed, via https://github.com/git-for-windows/build-extra/pull/312. The latest snapshot has the bug fix.