RTM: Spellcheck is broken in IE10 if AppData is redirected to a UNC path - by The Angry Technician

Status : 

  Fixed<br /><br />
		This item has been fixed in the current or upcoming version of this product.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

ID 780555 Comments
Status Closed Workarounds
Type Bug Repros 2
Opened 3/4/2013 1:04:24 AM
Access Restriction Public


Version:  IE10 for Windows 7 (10.0.9200.15521)

As per the subject, the spellcheck component is completely inoperable for any user that has their AppData directory redirected to a UNC path. The spellcheck does not mark misspellings or suggest corrections, and has broken UI elements in the Manage Add-ons dialog.

I can reproduce this on any account for which folder redirection is enabled on my domain, including administrator accounts. A screenshot of the UI problem, along with further explanatory details on the issue, is posted at:

Sign in to post a comment.
Posted by ThiloL on 10/8/2013 at 8:36 AM
Gelöst ist hier nichts. Oder?
Posted by Microsoft on 7/30/2013 at 11:37 AM
Thank you for your feedback.

We have released a new preview version of Internet Explorer which is included with Windows 8.1 available from the following location: http://windows.microsoft.com/en-us/windows-8/preview or IE11 Developer Preview for Windows 7: http://windows.microsoft.com/en-us/internet-explorer/ie-11-worldwide-languages

During our testing we are no longer able to reproduce the issue using Internet Explorer 11 please verify you are still experiencing the reported problem in this new release. If the issue continues please reopen this connect feedback item and provide additional details that will help us continue our investigation. We welcome your feedback, please send us additional comments so that we can investigate further.

Best regards,

The Internet Explorer Team
Posted by Lone Kawboy on 4/15/2013 at 10:27 AM
The proposed workaround does not work for me. Created the folder numerous ways (manually and GPP) and it changes nothing. This is a huge issue and something that will turn our entire organization away from IE and to Chrome or Firefox.
Posted by The Angry Technician on 3/7/2013 at 12:59 AM
I have also just found that simply creating the AppData\Roaming\Microsoft\Spelling\en-GB folder manually for an affected user is enough for spelling to start working. When IE10 spellcheck is used for the first time, the dictionary files are correctly created automatically.
Posted by The Angry Technician on 3/7/2013 at 12:54 AM
In my environment, the AppData\Roaming\Microsoft\Spelling directory is not present at all for any of the domain users I have tested. This is the case for:

1. A user that had AppData redirected before IE10, and installed IE10 under that user account.
2. A user that had AppData redirected before IE10, and logged on after IE10 was installed with a different account.

However, for a local user without AppData redirected, a folder for the language in use by that user (en-GB) was created automatically the first time that spellchecking was used in IE10 (it was not present before that), and spellchecking then worked normally.

If I manually copy the entire en-GB folder to the AppData directory of a user who has redirected AppData, spellchecking for en-GB works for that user. The UI bug is also immediately fixed for that language - but NOT any other language.

I have now run ProcMon against an affected user and an unaffected user, and have found significant differences in the activity of the MsSpellCheckingFacility.exe process when IE10 spellcheck is used for the first time.

On an unaffected user, when MsSpellCheckingFacility.exe is used for the first time, it tries to open the C:\Users\localuser\AppData\Roaming\Microsoft\Spelling\en-GB folder, and correctly recieves a PATH NOT FOUND. It then attempts to open C:\, which returns SUCCESS, then opens C:\Users, with SUCCESS, then C:\Users\localuser, and so on until it again reaches C:\Users\localuser\AppData\Roaming\Microsoft\Spelling\en-GB and again gets a PATH NOT FOUND. It then creates the C:\Users\localuser\AppData\Roaming\Microsoft\Spelling\en-GB folder, and proceeds normally.

For an affected user, MsSpellCheckingFacility.exe will try to open \\localhost\c$\TestAppData\Microsoft\Spelling\en-GB and correctly receive PATH NOT FOUND. However, it then attempts to open the path \\\ and receives NAME INVALID, because this is not a valid UNC or local path. It then does not proceed to try any other path. This appears to be the root of the problem: MsSpellCheckingFacility.exe does not have the correct logic to determine that it should be attempting to open \\localhost\c$\ as the root of the UNC path (or more correctly, simply attempting to open the path referred to by the %AppData% environment variable or via the Shell Namespace API).
Posted by Microsoft on 3/6/2013 at 12:55 PM
Thank you for your feedback.
In attempting to repro the behavior you are reporting I found I can reproduce the behavior only if the dictionary files are not present.
In my testing I have redirected AppData to \\localhost\c$\TestAppData\Roaming

The default location for the dictionary files is:
3 files are located there.

Questions for you “The Angry Technician”
1- Are the dictionary files in the path?
2- If the files are added to the path - does the spellchecker start working ?
3- Was the path redirected - before IE10 was installed or after?

Please provide us with the additional details for us to have a better idea of what is happening.

2- I would like to address your second bug report in a separate bug report. I have a feeling it is related to the language/ dictionary not being installed at all on the system.

Best Regards
Internet Explorer Team

Posted by Microsoft on 3/5/2013 at 4:21 PM
Thank you for your feedback. We will be investigating this issue further.

Best regards,

The Internet Explorer Team