I am experiencing the same issue:

Assertion failed!

Program: C:\Program Files\Git\mingw64\libexec\git-core\git-credential-store.exe
File: exec_cmd.c, Line 23

Expression: argv0_path

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

I am not a fan of bug reports that simply delete the carefully-crafted issue reporting template, and then go on and make it hard for me by not providing anything resembling a Minimal, Complete & Verifiable Example.

It's almost as if you wanted to make my life miserable.

I had git 2.8.2 installed, and updated to git 2.8.3 using your installer. I'm running Windows 10 Pro, 64 bit.

$ git --version
git version 2.8.3.windows.1

1. Open Git Bash
2. Navigate to a Git repository, eg: cd /c/Projects/MySuperCoolRepository
3. Update the git repository, or any command using previously stored credentials, eg: git pull origin

Then the aforementioned error occurs.

@dscho I update my issue.
Is that right?

Is the crucial bit the credential store? If so, why did you not include it in the MCVE? I guess it is rather important. As it is, I spent all the time that I can afford this week on this ticket, to get only this far. Frustrating.

I encountered this same issue following the same steps as @jnsn . Downgrading back to 2.8.2 solves it for me though

@svermeulen Could you please provide an MCVE that I can really verify here?

@dscho, the problem is indeed related to the store credential storage.

jnsn@notebook MINGW64 /d/tmp
$ git config --global credential.helper store

jnsn@notebook MINGW64 /d/tmp
$ git clone <any_repo_which_requires_authentication>
Cloning into '<repo_name>'...
Assertion failed!

Program: C:\Program Files\Git\mingw64\libexec\git-core\git-credential-store.exe
File: exec_cmd.c, Line 23

Expression: argv0_path

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
remote: Counting objects: 4097, done.
remote: Total 4097 (delta 0), reused 0 (delta 0), pack-reused 4097
Receiving objects: 100% (4097/4097), 28.13 MiB | 5.46 MiB/s, done.
Resolving deltas: 100% (2508/2508), d

As you can see, even though it throws an assertion error, the repository is successfully cloned. The error occurs with any other command which requires authenticating to the remote repository.

When using the wincred credential storage the assertion error message is not shown.

git config --global credential.helper store

Note that the default helper is now Git Credential Manager. This example also overwrites any configuration, which is not good.

git clone <any_repo_which_requires_authentication>

It would have been nice to specify one. As it happens, you can abuse GitHub for this, by pretending to clone a private repository. Take e.g. https://github.com/git/its-a-secret.

However, I cannot reproduce the problem. For me, even if I configure things as you said, the Git Credential Manager pops up and it does not show an Assertion.

I guess there is still a missing puzzle piece.

The store helper was already configured from way before the Git Credential Manager was part of the installation package. I can change for future use, that's not a problem.

I can see in my $HOME folder that there's a .git-credentials and a .git-credentials.lock file. I removed them both and I also removed a .git-credentials file from my C:\Users\jnsn\ folder.
I also removed the GitHub credentials from the Windows Credential Manager.

Since I only have access to my company's private repositories, I can't link them. However, I was able to reproduce the issue with a public repository, which requires authentication when pushing.

jnsn@notebook MINGW64 ~
$ cd /d/tmp/

jnsn@notebook MINGW64 /d/tmp
$ git clone https://github.com/jnsn/vimfiles
Cloning into 'vimfiles'...
remote: Counting objects: 213, done.
remote: Total 213 (delta 0), Receiving objects:  57reused 0 (delta 0), pack-reuse% (d 212
Receiving objects: 100% (213/213), 288.65 KiB | 214.00 KiB/s, done.
Resolving deltas: 100% (96/96), done.
Checking connectivity... done.

jnsn@notebook MINGW64 /d/tmp
$ cd vimfiles/

jnsn@notebook MINGW64 /d/tmp/vimfiles (master)
$ touch helloworld.md

jnsn@notebook MINGW64 /d/tmp/vimfiles (master)
$ git add .

jnsn@notebook MINGW64 /d/tmp/vimfiles (master)
$ git commit -m "Added hello world"
[master 45074a4] Added hello world
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 helloworld.md

The next bit is interesting. At this point, if I check my Git config, I can see that the credential helper shows up twice:

$ git config --list | grep credential.helper
credential.helper=manager
credential.helper=store

I did a search on my system and found that there's a .gitconfig file located in C:\Program Files\Git\mingw64\etc\gitconfig which contains the following:

[credential]
    helper = manager

I don't know if that file is a remnant of an old installation, or something that gets shipped with every installation.

I continue with my operation:

jnsn@notebook MINGW64 /d/tmp/vimfiles (master)
$ git push
Logon failed, use ctrl+c to cancel basic credential prompt.
Username for 'https://github.com/': jnsn
Assertion failed!

Program: C:\Program Files\Git\mingw64\libexec\git-core\git-credential-store.exe
File: exec_cmd.c, Line 23

Expression: argv0_path

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
Counting objects: 3, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 275 bytes | 0 bytes/s, done.
Total 3 (delta 1), reused 1 (delta 0)
To https://github.com/jnsn/vimfiles
   480ca72..45074a4  master -> master

jnsn@notebook MINGW64 /d/tmp/vimfiles (master)

Interestingly, since both credential helpers are specified, I first get the default Windows UI prompting for my GitHub credentials, next I have to fill in my username at the command line and I get the old Git password prompt dialog. When entering my credentials, the error message is shown, but the push continues.

@jnsn: the [credential] helper = manager is for the new Git Credentials Manager for Windows integration that @dscho was talking about before and has been shipping as the default credential manager since Git for Windows 2.7.3.

When you executed git config --list, it listed the system, global, and local configuration options. System configuration options are located in %ProgramFiles%\Git\mingw64\etc\gitconfig, global options are in ~/.gitconfig and local are in <your repo directory>/.git/config.

It would appear that your system configuration is set to use the Git Credentials Manager for Windows--which is to be expected because that's what Git for Windows comes with and that what gets installed (again, since 2.7.3). But your global or local settings are set to use the old credential helper, and I suspect it's in your global settings since you just cloned the repository.

From the Git-Scm book:

If there are multiple instances of the credential.helper configuration variable, each helper will be tried in turn, and may provide a username, password, or nothing. Once Git has acquired both a username and a password, no more helpers will be tried.

This appears to have some resemblance to what's happening in your case--you have multiple helpers defined and it appears that they are being tried in turn.

A few outstanding questions in my mind are:

1. Which helper is providing the credentials for the git push operation?
2. Why is the second helper being tried, if presumably, valid credentials are being provided to the first one?

I remove the .git-credentials.lock file and it works