none
Issue with Windows 10 Search Indexing and Display Languages Resulting in "These results may be incomplete".

    General discussion

  • Hello,

    I have recently come across an issue in our Windows 10 1607 environment where the Windows Search/Cortana would not display search results from the Control Panel or Windows Settings.

    Searching from the Start Menu would show: "These results may be incomplete..."

    Searching from Windows Settings would show: "Search results aren't quite ready yet, but we're working on getting them together. Try again in a few minutes."

    After researching online I discovered a number of people experiencing the same issue, and attributed the problem to missing indexes in this location:

    %LOCALAPPDATA%\Packages\windows.immersivecontrolpanel_cw5n1h2txyewy\LocalState

    There are many suggestions to repair the issue, including running the System File Checker and Windows Image Repair but in many cases these have not resolved the issue.

    In our environment the LocalState folder contained \Indexed\Settings\ but no language subfolders. On a working Windows 10 installation you would see at least one folder matching your installed display language, i.e. en-US or en-GB.

    In our environment, we have both en-US and en-GB language packs installed, with en-GB (for en-AU) set to default.

    The missing language folders suggested that the issue may be caused by something language related, perhaps a multiple languages causes an indexing conflict. To verify this hypothesis I removed the en-US language pack, restarted, and within a few minutes the search indexing issue was resolved. 

    To remove the language packs, I ran the following command from an elevated Command Prompt (CMD) window:

    lpksetup /u

    This opened a window showing duplicate English languages installed (example below). With en-GB being the system default, this left the other entry to be en-US. Checking the box next to the second English entry and following the wizard through to completion (with restart) resolved the issue.

    If anyone else is still experiencing this issue I would recommend you try removing any non-default system languages as a troubleshooting step.

    Important Note: Removing some language packs may result in certain applications to stop working or be removed. The Windows 10 RSAT for example requires the en-US language pack to be installed to work, removing the en-US language pack will also remove the Windows 10 RSAT.

    This issue is a perfect candidate to receive a hotfix from Microsoft given the number of cases posted online. In the consumer space many people have experienced this since updating to the 1511 and/or 1607 releases.


    MrGoodBytes





    • Changed type MrGoodBytes Wednesday, September 21, 2016 2:11 AM Post is not a question.
    • Edited by MrGoodBytes Wednesday, September 21, 2016 2:19 AM
    Wednesday, September 21, 2016 2:09 AM

All replies

  • Hi,

    Have you received any follow up advice or a solution from Microsoft regarding this problem? We are also seeing the same behaviour.


    Cheers Damon Blog: www.damonjohns.com Twitter: https://twitter.com/DamonAJohns


    Monday, February 20, 2017 7:40 PM
  • Hi Damon,

    No feedback from Microsoft however in December (2016) we found the issue was present in our captured base OS image which explained why the issue was affecting all our new builds. The image had been in use for a few months and included updates installed via task sequence (during creation) and offline servicing.  This discovery prompted us to recapture the base image from original install media, including both en-GB and en-US language packs, and we've not had the issue since. 

    It's possible the issue was caused by a patch or combination of patches. We don't know for sure. No further investigation was conducted. 


    MrGoodBytes



    • Edited by MrGoodBytes Tuesday, February 21, 2017 6:25 AM
    Tuesday, February 21, 2017 4:18 AM
  • Thanks for the reply - we shall try that then. Interestingly we also created our reference image in November - then offline serviced that wim with the December CU.

    Cheers

    Damon


    Cheers Damon Blog: www.damonjohns.com Twitter: https://twitter.com/DamonAJohns

    Tuesday, February 21, 2017 5:22 AM
  • Hi,

    I've re-created our reference image with the latest January 2017 CU and I'm still seeing the problem.

    Can you describe the process you went through when you re-created your reference image? I'm using MDT and adding the latest CU as a package so that it is integrated into the OS when it is installed. I'm then patching the reference image against a WSUS instance and capturing it.

    At deployment time I'm adding the additional language pack using a DISM command in a Configuration Manager Task Sequence. This step is prior to the Software Updates step so that the CU is installed again (as a language pack is installed).

    You said your including the language pack in your reference image - how are you adding it and at what stage? Any further assistance would be greatly appreciated.

    Cheers

    Damon


    Cheers Damon Blog: www.damonjohns.com Twitter: https://twitter.com/DamonAJohns

    Thursday, February 23, 2017 1:05 AM
  • We're using a non-MDT Configuration Manager Task Sequence to create our reference image. I wouldn't think the MDT integration is contributory since we also had the issue without it.

    I think the most relevant parts of our configuration which could assist you are:

    • The Apply Operating Step is applying a Offline Serviced Windows 10 Enterprise 1607 English International (en-GB) WIM. An unattended file is specified:
    <?xml version="1.0" encoding="utf-8"?>
    <unattend xmlns="urn:schemas-microsoft-com:unattend">
        <settings pass="specialize">
            <component name="Microsoft-Windows-International-Core" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
                <InputLocale>0c09:00000409</InputLocale>
                <UILanguage>en-GB</UILanguage>
                <SystemLocale>en-AU</SystemLocale>
                <UILanguageFallback>en-US</UILanguageFallback>
                <UserLocale>en-AU</UserLocale>
            </component>
        </settings>
        <settings pass="oobeSystem">
            <component name="Microsoft-Windows-International-Core" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
                <InputLocale>0c09:00000409</InputLocale>
                <UILanguage>en-GB</UILanguage>
                <SystemLocale>en-AU</SystemLocale>
                <UILanguageFallback>en-US</UILanguageFallback>
                <UserLocale>en-AU</UserLocale>
            </component>
        </settings>
        <settings pass="windowsPE">
            <component name="Microsoft-Windows-International-Core-WinPE" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
                <InputLocale>0c09:00000409</InputLocale>
                <SystemLocale>en-AU</SystemLocale>
                <UILanguage>en-GB</UILanguage>
                <UILanguageFallback>en-US</UILanguageFallback>
                <UserLocale>en-AU</UserLocale>
            </component>
        </settings>
        <cpi:offlineImage cpi:source="wim:c:/iso/install.wim#Windows 10 Enterprise" xmlns:cpi="urn:schemas-microsoft-com:cpi" />
    </unattend>
    • We are including the en-US Language Pack in our reference image along with the relevant en-GB/en-AU Features-on-Demand. We are using DISM to apply these packages. The order sequence can be seen below. Note the redacted steps are specific to our organisation.
    • We are applying updates via SCCM Software Updates. All update steps are configured to apply all software updates and do not evaluate from cached scanned results and may include updates for Features-on-Demand, Language Packs and Language Interface Packs in addition to Windows 10.

    Hope this helps.


    MrGoodBytes

    Thursday, February 23, 2017 2:34 AM
  • Thanks that's great information.

    We are using an offline serviced Windows 10 Enterprise 1607 English International (en-US) WIM, then adding in the en-GB language pack and other relevant feature on demand components. So in reverse to what you are doing, however that shouldn't matter I would think.

    You have given me some things to look at - I will look at including the language pack in our capture process. Hopefully that combined with the modified unattend.xml will resolve the issue.

    Thanks again.

    Cheers

    Damon


    Cheers Damon Blog: www.damonjohns.com Twitter: https://twitter.com/DamonAJohns

    Thursday, February 23, 2017 3:39 AM
  • Hi,

    Thanks heaps for the information you provided. I've now resolved issue by injecting the language pack and feature on demand components into the Microsoft Windows 10 1607 US Enterprise install.wim. The problem seems to occur when you either offline service the wim file or patch it using WSUS as part of a build and capture prior to applying the language pack. I also had to make some changes to my unattend.xml so the OOBE was processed without any prompts.

    Thanks once again,

    Cheers Damon 


    Cheers Damon Blog: www.damonjohns.com Twitter: https://twitter.com/DamonAJohns

    Friday, February 24, 2017 4:30 AM