SourceTree crashes immediately upon start up, starting today. We receive the error message below:
Problem Event Name: CLR20r3
Problem Signature 01: SourceTree.exe
Problem Signature 02: 184.108.40.20648
Problem Signature 03: 5e2b7a41
Problem Signature 04: System.Management
Problem Signature 05: 4.8.3761.0
Problem Signature 06: 5c9c7026
Problem Signature 07: 25c
Problem Signature 08: 118
Problem Signature 09: PSZQOADHX1U5ZAHBHOHGHLDGIY4QIXHX
OS Version: 6.1.7601.2.1.0.400.8
Locale ID: 1033
Additional Information 1: a009
Additional Information 2: a009ab7e5257d08d5d1625b49477e8fe
Additional Information 3: 405d
Additional Information 4: 405d2bf1ba833c0ba4cf6e317d63a8c7
Read our privacy statement online:
If the online privacy statement is not available, please read our privacy statement offline:
I have tried the following to troubleshoot the issue:
At this point, I'm out of ideas. Can you help us out please?
I had a similar problem with Version 3.3.9 and tried all the above suggestions and it would still crash every time it ran after about 2 seconds. I must have uninstalled and re-installed it 4 times. I also tried running it from the command line with no command line options. Uninstalling and re-installing GIT didn't help either.
I "solved" the issue by launching sourcetree from our company bitbucket server using the "Clone In Sourcetree" option. Now it launches fine. I have no idea what the root cause was.
I have the same problem and was able to workaround it somehow.
My system is Windows 7 x64 SP1 with .NET 4.8 installed.
What I initially observed was that after a clean install of Sourcetree it doesn't crash, but only on the very first launch. As soon as I restart Sourcetree, it crashes after a couple of seconds and I am completely locked out of the application and have to do a clean re-install.
I then noticed that if I do a clean install, launch Sourcetree, and immediately setup my offline repo ("clone repo") and leave the repos tab open before closing Sourcetree, then it will not crash after that.
So something about having an active repo open in Sourcetree seems to stop it from crashing.
I believe it's because once I have cloned my repo in Sourcetree, the very first thing Sourcetree does on launch is to refresh the repo, which is different to what it does without any repos.
With Sourcetree in a state of not crashing, I was able to reproduce the crash by opening a new tab in Sourcetree and then clicking "Remote" icon at the top, then it crashes. I think this is the function that gets called when starting Sourcetree without any repos open and causes a crash after the first launch.
I was able to enable and disable the crashing behaviour by going to my repo's tab -> settings -> advanced -> user information -> untick "use global user settings". However I can no longer reproduce that for some reason, and of course this won't be of any use if you aren't even able to open a repo in the first place if you are completely locked out of the application already.
When unticking that setting, I notice it adds the login credentials to the repo's config file
name = YourUserName
email = email@example.com
So if you have setup a repo already, maybe try adding or removing that block from your repos config file which is stored somewhere like C:\MyRepos\MyFirstRepo\.git\config
The "global user settings" name and email appear to be stored in Tools -> Options -> General -> Default user information. However I cannot find where this is stored on disk anywhere (config or registry).
But maybe try modifying/deleting
%LocalAppData%\Atlassian\SourceTree\opentabs.xml (since the first open tab seems to affect whether it crashes)
Well it started crashing again and now I'm totally locked out even after a clean install and deleting all local app data, temp files etc. It won't even download the embedded GIT executables when the Sourcetree installer starts, something about a network protocol error. Switched to GitHub Desktop, everything working perfectly.
Hello Sourcetree users!!! With the recent removal of Bitbucket Cloud account passwords for app passwords (please see our Bitbucket Cloud community post for details on why we made this change for se...