These changes will appear in the 3.4.6 release

Guys,

I stopped using SourceTree back in 2018, when you started requiring Bitbucket accounts (God only knows why; I had an Atlassian account, and I can't figure out why that wasn't good enough).

But I do use other Atlassian products (Jira Cloud and Jira Service Management).

This bug, marked as severity 2 and high priority, has now remained open and unresolved  for FIVE YEARS.

And as an Atlassian customer, I find that alarming.

What's the problem here? Did you guys just decide you didn't want to fix the problem?

Deleting my Microsoft Office custom dictionary worked, but I was only willing to do it because the dictionary had a handful of entries. And I did something today, I think, that caused the custom dictionary to be created again, so I'm getting the message again.

Why? – WHY IS THIS HAPPENING when I have the "spell-check commit messages" feature DISABLED?

Running 1.9.10.0 on Win 10 and disabling spell check does not help..

@PaulWad Quite right. I was only opening and immediately closing SourceTree, so it didn't have a chance to recreate the faulty registry entry.

Nice catch!

@Constantine, no, removing the empty line is NOT a permanent fix in v1.9.10.0. However, there seems to be 2 - unacceptable - ways to permanently avoid the problem (once the empty line has been removed):

1. Open tools->options and disable "spell check commit messages".
   ...or...
2. Make sure the commit message input field is never visible (i.e. select the branch graph view, and never make commits).

Can't find any mention of this... It appears that editing the registry entry to remove the empty line is a permanent fix with SourceTree v1.9.10.0 (i.e. no more messages, ever). Now, if only SourceTree made the fix itself, it would make everyone happier

Also seeing this in Windows 8.1 with 1.9.10.0. Cant get rid of it, except by disabling the spell checker 

The startup check appears to complain about the "empty" dictionary entry in the MULTI_SZ.

On my Win10 1.9.10.0 machine, this is actually placed there by the RuntimeBroker.exe process which appears to "carry out" dictionary changes. It looks to erroneously include an extra (double null-byte). It appears that it is the adding/removing of SourceTree's own "Temporary" dictionary that causes these RuntimeBroker.exe updates. This means that a start/stop cycle of SourceTree will "corrupt" this entry - guaranteeing the problem EVERY SINGLE run.

Technically, empty strings should not be possible with MULTI_SZ encoding (null-terminated strings, terminated by an empty string). DotNet decoding of MULTI_SZ uses the retrieved buffer length (and not an empty string) to terminate decoding. This results in the extra "empty" string at the end.

You can't rely upon the RuntimeBroker.exe process getting fixed. You also can't rely upon the RuntimeBroker.exe process NOT getting fixed. 

I believe the best answer would be that SourceTree simply not class the extra empty string at the end of the MULTI_SZ as an error.
In SourceTree.Configuration.WpfSpellCheckerPreFlightCheck.Run skip verification if it's the last entry && empty.

Same here.  Windows 10, started in SourceTree v1.9.9.20 and continues in v1.9.10.0