Sourcetree Crashing When Adding Account Credentials

[Simon_Roth]

Hello! 

We are experiencing a crash issue with one of our users when they attempt to add a GitLab CE/EE account to Sourcetree. 

In this case they are able to install and launch Sourcetree and login with their bitbucket account, and Sourcetree loads as expected. From here they are going to Tools > Options > Authentication and selecting the Add option. The get presented with the appropriate account setup screen and are able to enter all relevant data on this screen, from here they select the "Refresh Personal Access Token" button and are presented with a credential prompt from Windows (GCM). 

Here is where things get interesting. 

1. The Credential prompt has data filled in in the password field (but not the username), which it shouldn't as there are no related accounts on the machine. 
2. After entering correct authentication data and pressing okay, Sourcetree crashes. 
3. Additionally if they cancel from this credential prompt, or close with the X, Sourcetree crashes. 

I have verified they have correct permissions on the GitLab system, and verified all data and the process they are using is correct. This is not an issue with their process, as the same exact process on a different machine works without issue.

We have done a full removal of Sourcetree and Git (with reboots), as well as an independant install of GCM, and verified that Git is configured to use manager for credentials. 

OS: Windows 7 
Sourcetree Version: 3.0.15
Git Version: 2.21.0

Any insight or ideas would be quite appreciated. 

Thank you, 
Simon

[Simon_Roth · Accepted solution]

Hi all, 

Here is our workaround, ultimately we went with SSH as a workaround to this issue. GCM was packaged with Git 2.21 that we had installed and additional reinstall of GCM had no effect. I'm left with no other conclusion than it being an issue specific to the profile, and as this is their personal machine I'm not walking them through a rebuild on that. 

SSH Worked around the issue, I wouldn't call it a solution as the root issue still exists, but at least they are able to operate Git without too much trouble at this point. 

Thanks again, 
Simon

[Mike Corsaro]

Hello! Could you try updating to 3.1 and see if that fixes the issue? If not, could you report back with the Bugsplat crash ID so we can investigate?

If you're not able to obtain that, could you email me (mcorsaro at atlassian dot com) the following file or upload it somewhere:

C:\Users\USERNAME\AppData\Local\Atlassian\SourceTree\sourcetree.log

Thanks!

[Simon_Roth]

Hi Mike, 

Thanks for the reply, we have tried 3.1 and were met with the same issue. That being said we're starting to think this is an issue somewhere in the WIndows Profile for the user, as we are running into similar, albeit vastly more irritating, issues with Git Credential Manager for Windows with other Git Clients. It seems there is something happening when Git is calling GCM and it's failing, in once instance on another client it started spawning login prompts at a rate of about 2-3 per second on the users machine. We are attempting some additional troubleshooting focusing on this area of things, rather than on it being a Sourcetree application issue. 

I'm leaving this question open for now as  it may still be relevant down the line, but will mark it closed once we determine the root cause and a solution. 

Thanks, 
Simon

[Mike Corsaro]

As a work-around, you can choose to use SSH as the authentication method as well -- it typically doesn't have these problems.

This article may be of help. Make sure the GCM is up-to-date.

[Simon_Roth]

Ultimately we went with SSH as a workaround to this issue. GCM was packaged with Git 2.21 that we had installed and additional reinstall of GCM had no effect. I'm left with no other conclusion than it being an issue specific to the profile, and as this is their personal machine I'm not walking them through a rebuild on that. 

SSH Worked around the issue, I wouldn't call it a solution as the root issue still exists, but at least they are able to operate Git without too much trouble at this point. 

Thanks again, 
Simon