Like all Microsoft Office applications, the new Teams app has a spellcheck feature. One issue I have ended up investigating was for problems with spellcheck behaving unexpectedly in MS teams.

What was noticed, was that users who had Teams enabled for them noticed that all text they typed in the chat window was being underlined in red. This happened regardless of whether the spelling was incorrect or not.

The next odd quirk was that if a user right clicked on one of the underlined words, the Teams application would crash.

First thing was to check a few of the basics:

  1. Was the issue is present in both desktop & web version of MS Teams? Yes
  2. Were any other Office applications behaving in a similar fashion? No
  3. What were the language settings for Office package? English UK
  4. What were the language/regional settings for Windows? English UK
  5. What were the language settings in Teams? English UK

Because the web version of Teams was also affected, doing an uninstall and reinstall of the Teams desktop app was unlikely to fix things, but we tested this just to eliminate it, and it didn’t work.

As this was a spellcheck issue, I did a bit of digging around on a system with Teams installed and found out the location of the dictionary files. Testing in a different environment showed that if the files are missing, then Teams downloads a new version when it is next launched.

So we tried this out on an affected system:

  1. Close Teams (make sure you select the task bar icon and quit)
  2. Go to C:\Users\<USERPROFILE>\appdata\roaming\Microsoft\teams\dictionaries
  3. Delete any file that is there. (usually en-GB.bdic and sometimes en-US.bdic)
  4. Restart Teams, (it’ll re-download the proper Dictionary file)

The end user did this and reported back that the dictionary had downloaded successfully but that the issue persisted.

Next thing on my mind is all of the IP addresses and URLs that have to be whitelisted for Office 365, so I got the firewalls/networks/proxy teams involved to check that all of the settings in the O365 URLs and IP address ranges article were set correctly, and they were.

I considered getting a process dump, but this is a Microsoft Office application, so I am not going to get a symbols match as Microsoft do not release the symbols for Office applications externally. So get this raised with Microsoft.

What I wanted was to get two things from Microsoft.

  1. Fix the spellcheck issue.
  2. Explain the crash.

Microsoft got involved and the first thing they wanted was a process dump. They sent me one of their MSDT packages that would run in the background while the issue was reproduced and collect a process dump. This did not work. I expect this was due to policy restrictions on the user device, so I used the steps I had worked out to use ADPlus without having to install the debugging tools. For details on this see here.

Great, we now had a process dump, as expected I couldn’t get much out of it, but fingers crossed Microsoft would. In addition to this we sent Microsoft the Teams client logs for analysis.

For Teams client logs see the following two Microsoft articles:

Use log files in troubleshooting Microsoft Teams and Microsoft Teams: Desktop and Web Client Log Location.

After sending the evidence to Microsoft, the case was escalated to the Product group for analysis.

Testing on other systems outside of this particular environment showed that it was not a global problem. So it was specific to this environment. So I started running through Windows 10 build, Group policy settings etc.

Lots of hours of testing with clean builds of Windows 10 and various GPO settings that were used in the environment and I could not reproduce the issue. The only settings I had not tested were those related to Internet/Network access.

Right then, my next course of action was a clean build connected to the environment that had the issue. The reports that came back from this showed that the dictionary file was not downloading when going through the proxy servers. If you bypassed the proxy or connected via other means to the Internet then the dictionary file downloaded successfully.

So we had a look at the dictionary file from a system that had the issue.

A correctly-downloaded version of the en-UK.bdic file is 438kb in size the en-US.bdic is 436kb.

The file I received was 8kb in size.

If you try to open one of the correctly-downloaded bdic files in Notepad++ it is gibberish, the problematic file was readable. It was basically an access denied message from the Bluecoat proxy servers due to acceptable use policy. The URL it had blocked was the following:

tcp://redirector.gvt1.com:443

Did some checking and *.gvt1.com domains belong to Google and are used for Chromium updates.

To proceed, we deleted the dictionary file on an affected system and then got a Fiddler trace with HTTPS decryption enabled and we can see this for ourselves. In the trace, you have connections to redirector.gvt1.com and also to a specific bdic file:

https://redirector.gvt1.com/edgedl/chrome/dict/en-gb-7-1.bdic

Now, in this particular environment, the domain *.gvt1.com is blocked as it was affecting Internet traffic due to the frequency and size of Chrome browser updates. Chrome updates were being managed in a different manner (SCCM), rather than letting Chrome do its own thing as and when it wants.

Checked the behaviour with the full desktop client on Windows 10, then on a completely separate environment with a Windows 7 client and on a system that was not domain joined and just had a direct connection to the Internet. All three showed the same behaviour and the request for the same file.

Right, we now know why the dictionary is not downloading, it is on a server owned by Google that we were blocking in this environment. As Teams is an Office 365 application, I revisited the O365 URLs and IP address ranges article and went through it with a fine tooth comb looking for any reference to this specific domain, there was nothing.

We shared our findings, conclusions, and supporting evidence, with Microsoft.

Microsoft reviewed the data and confirmed that they were using dictionary files hosted on Google servers.

We queried why this was not documented and asked for the documentation to be updated or for the Product group to change the behaviour of Teams/use different dictionary sources.

We received the following recommendations:

The bug: all words are being underlined in Teams as if they are spelled incorrectly. When users right-click the word, Teams crashes.

The reason: the platform that MS Teams is written on uses a dictionary from Google. You block all Google servers therefore the dictionary becomes corrupted.

The proposed solution(s):

  • A bug fix is currently in code-review which will disable the spell checking feature if the dictionary is corrupt. This will stop the underlines and crashing but the spell check feature will be unavailable.
  • The product group are working on a long-term solution to the spell checking feature which may involve using different dictionary sources.
  • These options should unblock you now:
    • Unblock only the following URLs: https://redirector.gvt1.com/edgedl/chrome/dict/en-gb-7-1.bdic (e.g. for UK English) so that the dictionary files can download but all other Chromium updates will be blocked
    • Package the required dictionaries into the MSI that you created to deploy Teams to desktop machines and put them in: AppData\Roaming\Microsoft\Teams\dictionaries\. Teams will not try to download the dictionary file if one already exists.

Now at present we are still reviewing the suggestions provided under item 3 to see which we can use in the short term. For the other items, 1 will happen (eventually), as for option 2, I believe this is a long term plan if it ever does get done. My request to have the documentation updated has still not received a response so watch this space for further updates.

NOTE: The issues mentioned above have not been recorded by Microsoft in the Known Issues for Microsoft Teams article.

Update 12/06/2018:

Microsoft released a fix for the Teams App crashing problem at the beginning of May. The client version where the fix should be available is 1.1.00.10955.

Microsoft also confirmed that the O365 URLs and IP address ranges article would be updated to include the google *.gvt1.com URLs. No timeframe mentioned, and so far I have not seen them listed, but it will eventually happen.