Windows 7 installation error

[greenozon]

• I was not able to find an open or closed issue matching what I'm seeing

Setup

• Which version of Git for Windows are you using? Is it 32-bit or 64-bit?

$ git --version --build-options

 git --version --build-options
git version 2.33.0.windows.1
cpu: x86_64
built from commit: fb59c1de9fd599a3eeb8459eb7cab731c6672ea3
sizeof-long: 4
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

$ cmd.exe /c ver

$ cmd.exe /c ver

Microsoft Windows [Version 6.1.7601]

[dscho]

Was this an upgrade? Do any previous versions install without problems? If so, could you pinpoint which snapshot is the first one where it broke?

[acohenOT]

I'm having the same exact problem using Windows Server 2016 trying to upgrade from 2.32 to 2.33.
Uninstalled the incomplete 2.33 and installed it again fresh. Same error.
Installed 2.32.0.2 and it worked without issue.

[rimrul]

We've had an earlier report about the exact same error message on windows 10 during a different part of ssPostInstall with 2.33.0-rc1.

And it seems I can reproduce the issue by installing 32bit Git for Windows 2.33.0 on 64bit Windows 10.

I think we're accidentally trying to load an external Function for ExecWithCapture from a 64bit DLL.

[greenozon]

@dscho I did have git some time ago, then removed
It might leave some stuff in user dir, I don't know
but today it was fresh install

PS Issue is not critical, it might be a warning? git itself is fully functional

[dscho]

No, it is not a warning, it is a real error. Your Git might work most of the time, though. Without digging deeper, I cannot say what operations might be affected.

[acohenOT]

Not sure if it matters, but when I recreated the error, the only options I chose were to use Visual Studio Code as the default editor and to override the branch name to main. All other options were left at the defaults.

[dscho]

I think we're accidentally trying to load an external Function for ExecWithCapture from a 64bit DLL.

That sounds quite plausible...

However, the installer is 32-bit. So I would expect the same problems no matter whether installing a 32-bit or a 64-bit Git for Windows.

[rimrul]

It doesn't happen for me with the 64bit installer, but it happens reliably with the 32bit installer. No matter what options I choose I always get the error message. If I choose to install the terminal fragment it happens on that step, otherwise on the explorer integration step.

[acohenOT]

I'm using the 64-bit installer and I get the error in the Explorer Integration step.

[rimrul]

If I select neither LFS nor the terminal fragment it happens on "Removing bundled Git LFS".

[dscho]

Could you rebuild the installer, with LogError(...) debug statements thrown in liberally, to pinpoint which call fails?

[rimrul]

Yes.

[ChloeESG]

I am having the same error message too. May I know if this is still usable or should I just reinstall?

[rimrul]

this is still usable

We don't currently know how usable this is.

or should I just reinstall?

That'll likely produce the same error again.

[worstpractice]

Can confirm this issue when upgrading from previous version on Windows 10 Pro (v. 10.0.19042 Build 19042).

My git version is:

git version 2.33.0.windows.1
cpu: x86_64
built from commit: fb59c1de9fd599a3eeb8459eb7cab731c6672ea3
sizeof-long: 4
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon

It seems to report the install as a success (but who knows), however the error reoccurs each time I try installing again.

[Purpzie]

Also experiencing this on Windows 10.

Runtime error (at 325:19181)

Could not call proc.

Microsoft Windows [Version 10.0.18363.1500]

git version 2.33.0.windows.1
cpu: x86_64
built from commit: fb59c1de9fd599a3eeb8459eb7cab731c6672ea3
sizeof-long: 4
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon

Editor Option: VisualStudioCode
Custom Editor Path:
Default Branch Option: main
Path Option: Cmd
SSH Option: OpenSSH
Tortoise Option: false
CURL Option: OpenSSL
CRLF Option: LFOnly
Bash Terminal Option: ConHost
Git Pull Behavior Option: Rebase
Use Credential Manager: Core
Performance Tweaks FSCache: Enabled
Enable Symlinks: Disabled
Enable Pseudo Console Support: Disabled
Enable FSMonitor: Disabled

[TectonicTMI]

Same issue as OP, but OS is Windows 8 Pro.

Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.

C:\Windows\system32>git --version --build-options
git version 2.33.0.windows.1
cpu: x86_64
built from commit: fb59c1de9fd599a3eeb8459eb7cab731c6672ea3
sizeof-long: 4
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon

C:\Windows\system32>cmd.exe /c ver

Microsoft Windows [Version 6.3.9600]

C:\Windows\system32>

Had an update notification, clicked on it, and this was the error at the end.

Went to the website and downloaded the latest installer (64-bit) and received the exact same error.

[DustinWin]

I have the same problem.
System version: Windows 11 22000.160
Git version: 2.33.0
Operation steps: Installing 2.33.0 from 2.32.0 overlay.

[PetSerAl]

I have the same error on Microsoft Windows [Version 10.0.19043.1165].

I tested it in clean installation of Widows in VM:
Clean install: git setup working.
Removing OpenSSH client Windows capability: git setup fails.
Reinstalling OpenSSH client Windows capability: git setup working again.

So I reinstall OpenSSH client Windows capability on my main PC, and git successfully installed now. Hope this help others.

[PetSerAl]

It seems mere existence of ssh.exe in directories of the PATH environment variable is enough to solve this issue.

[PetSerAl]

Looks like this is root of the issue:
https://github.com/git-for-windows/build-extra/blob/f1854b8bb8e5e572658f5a626eb2525bf29cf5aa/installer/install.iss#L3368

if condition should additionally check for SSHChoicePage<>NIL.

[aicarambazigalo]

but please notice the context of the error is different for example in the above two comments:
#3368 (comment) Initializing Explorer integration
#3368 (comment) Writing Windows Terminal Profile

I'm guessing it's another context than the above two for this comment also: #3368 (comment) probably Removing bundled Git OpenSSH binaries

[PetSerAl]

@aicarambazigalo What exact difference you are pointing to?

[rimrul]

but please notice the context of the error is different for example in the above two comments:

The progress text depends on the features you want to install, but it does seem to always be the last step before the openssh step.

[aicarambazigalo]

but please notice the context of the error is different for example in the above two comments:

The progress text depends on the features you want to install, but it does seem to always be the last step before the openssh step.

perhaps it's still the openssh step the culprit, but the context text doesn't get updated as fast, and maybe that's why it seems like it's previous steps??

[rimrul]

And the potential fix by @PetSerAl supports that, as it would happen right before the Text switches to the openssh text.

[greenozon]

Had an interesting debug session like building git installer from scratch under Win7

Looks like the above idea is right, it's failing over here:

[greenozon]

My understanding of the issue is as follows:
SSHChoicePage is a Wizard Page
it is conditional object, I bet in majority of cases (those, who reported this bug) it is equal to NIL. In my case 100% it is NIL.
Thus, we hit a so-called AV (AccessViolation) error because RdbSSH array is also NIL

here is proposed fix: (ref to underlined added code)

With this addage setup finishes smoothly

[aicarambazigalo]

git-for-windows/build-extra#374

[dscho]

NIL

Excellent analysis!

@Okeanos thank you so much for implemeting and testing git-for-windows/build-extra#374!

[mohamadsheam]

I have turned back to git version 2.32.0.windows.2

[dscho]

I have turned back to git version 2.32.0.windows.2

Please note that this comment does not really add anything to value to the discussion.

What would add value is if you had built an installer and verified the fix yourself.

As it happens, I intend to merge an existing PR (or to find a nice and easy change I can open a PR for) so that a new snapshot can be built that y'all are respectfully asked to test.

It will probably be a good idea to release a new Git for Windows version, after I get a couple more reactions that verify the fix.

[greenozon]

@dscho where is the latest build with the fix?
I just tried the one from your snapshot link x64 installer (Tue, 17 Aug 2021 00:17:32 +0200
(commit fb59c1d)

but it has the same error as reported in this issue thread...

I've seen that v2.33.0 milestone is closed, so should we xpected a 2.33.1 or event 2.34?
any ideas about next milestones... where I could find that info
Thank you

[dscho]

where is the latest build with the fix?

I do not have any as of yet. I started a git-artifacts workflow run here, which should produce the installers, but they are not code-signed by me (unlike the snapshots would be).

I've seen that v2.33.0 milestone is closed, so should we xpected a 2.33.1 or event 2.34?

The v2.33.0 milestone is closed because that version has been released ;-)

I am thinking about releasing a v2.33.0(2) soon-ish, including this fix.

[dscho]

Okay, there is now a current snapshot with this fix.

[PetSerAl]

Okay, there is now a current snapshot with this fix.

This one fix issue for me.

[mohamadsheam]

I have turned back to git version 2.32.0.windows.2

Please note that this comment does not really add anything to value to the discussion.

What would add value is if you had built an installer and verified the fix yourself.

As it happens, I intend to merge an existing PR (or to find a nice and easy change I can open a PR for) so that a new snapshot can be built that y'all are respectfully asked to test.

It will probably be a good idea to release a new Git for Windows version, after I get a couple more reactions that verify the fix.

Agreed.

[greenozon]

Confirming - fixed installer (x64) worked like a charm!

[aicarambazigalo]

Confirmed working now: installed over the existing one without errors(i've noticed this did the auto removed prev. version), then I manually uninstalled it and installed it again w/o errors(Windows Explorer Integration was selected, if it matters, and use OpenSSH library).

used the aforementioned snapshot "Mon, 23 Aug 2021 16:47:37 +0200
(commit 626897c)

Git for Windows installer: 64-bit"

61e6a032a6339d4915eaf96c75544528e49fe5ea05835629b8aade527b703375 *Git-prerelease-2.33.0.windows.1-2-g626897c0ea-20210823145343-64-bit.exe

I thank everyone involved for your work and time!

[dscho]

All of you who worked on thorough bug reports, on the analysis and finally on the fix of this bug, and on verifying the fix: you are amazing. Thank you so much!

It is a bit too late in the day for me to start the release process, and besides, I want to make sure first that there might not be an upstream v2.33.1 lurking around the corner. My current plan, therefore, is to first make sure I get a feel about the upstream situation, and then go ahead and release v2.33.0(2). Hopefully tomorrow, definitely this week, I promise 😄...

[Okeanos]

Thank you as well from my side to the reporters, in particular @PetSerAl, for pointing out what broke during my pull request and enabling me to offer a fix so quickly. Also a mea culpa for not testing the changes on an expected configuration (Windows pre Win32 OpenSSH) that could've prevented this ordeal.

[dscho]

@Okeanos for the record: I do not see anything "tua culpa" about this. It was a really good contribution, a bug snuck in that nobody noticed, not even during -rc0, -rc1 and -rc2, then it was identified and fixed efficiently. I could not wish for any better. Experiences like this one let me keep going, with gratitude.

My sincere thanks go to you, to @greenozon, @rimrul, @PetSerAl, and everybody who jumped on verifying the analysis and the fix!

Here is the outcome of your lovely effort: https://github.com/git-for-windows/git/releases/tag/v2.33.0.windows.2

[jeremyd2019]

This was apparently also what I was seeing on Windows 10 ARM64, as the "Could not call proc" error is gone there too with 2.33.0(2)

[Muncikas]

I wish to unsubscribe please

[MartinLeuthold]

I had the same issue. We install it with SCCM. We choose plink. The solution was to create the "HKEY_CURRENT_USER" "SOFTWARE\SimonTatham\PuTTY\Sessions\Default%20Settings..." Keys for the system Account.