Windows 10 Search not working after performing an in-place upgrade

This article discusses a fix for the Windows Search bar / Cortana not working after an in-place Windows 10 upgrade.

The Problem

Upgraded Windows 10 to find Windows Search Not Working? The symptoms may include:

  1. Clicking on the search bar in the task bar does not launch the search user interface pop-up
  2. Opening the Start menu and immediately typing does not launch the search user interface
  3. When you click on the search bar in the task bar, Cortana momentarily appears on the ‘Apps’ tab in Task Manager and then exists
  4. Clicking on the search bar causes SearchUI.exe to launch on the Details tab in Task Manager and then immediately exit
  5. The search bar on the taskbar flickers, flashes on and off or even vanishes completely; leaving a display artefact.
  6. The Events Viewer > Application log records the following event under Event ID 1000:
Faulting application name: SearchUI.exe, version 10.0.18362.1, time stamp: 0x5c90179d
Faulting module name: SearchUI.exe, version 10.0.18362.1, time stamp: 0x5c90179d
Exception code: 0xc000027b
Fault offset: 0x000000000015bf3e
Faulting process ID: 0xb50
Faulting application start time: 0x01d5229682a57780
Faulting application path: C:\Windows\SystemApps\Microsoft.Windows.Cortana_cw5n1h2txyewy\SearchUI.exe

In my case, the upgrade was from Windows 10 1703 to Windows 10 1903 and the user account was a Roaming profile (local profiles were all fine).

Am I the only person who is beyond fed-up with this nonsense? I digress…

Yes, no doubt you are equally frustrated with seeing Microsoft supports unhelpful and generic “run DISM’s Restore Health command followed by running SFC.exe /ScanNow[1]. Microsoft Product Support are just ignoring the problem and trying to encourage people for format the system by means of finding a zero-effort fix. This attitude helps no one.

The Windows shell is a mess. The Windows Modern App paradigm – while improved on 2015 – is still not in a fit state to be able to replace Win32. With these kinds of issues, is it any wonder that even in 2019 no one is writing Modern Apps? Microsoft themselves were forced to acknowledge this. Microsoft’s one success to encourage the use of Modern Apps has been to create a Win32 wrapper. Allowing Win32 programs to be released via the Windows Store. It says it all doesn’t it?

The Fix

As the search bar works fine for local users, the issue had to be profile, not system level (for anyone paying attention this rules out SFC /ScanNow and DISM).

Event Viewer tells us the application version involved as being “Microsoft.Windows.Cortana_cw5n1h2txyewy”. For a test user this happens to map within their profile to:

C:\Users\<username>\AppData\Local\Packages\Microsoft.Windows.Cortana_cw5n1h2txyewy

I then proceeded to delete data from within the directory until search worked. The culprit was the contents of the Settings folder. Clearly between version 1703 and 1903, Microsoft have changed a lot here. There has not been any settings migration through Windows Store auto-update as “Cortana” (Windows Search) is only upgraded during feature updates.

 

Automating the Fix

If you are experiencing the same problem. I have put together the following PowerShell scripts to solve the issue on both a per-user and per-system basis. The script does the following

  1. Searches for all Settings folders present beneath any version of Cortana on the system
  2. Attempts to kill the SearchUI process, if present
  3. Deletes the contents of the Settings folder and the Settings folder itself

The SearchUI process/deleted data will be restored the next time the search bar is clicked.

 

For the currently logged on user

$settings = dir $env:UserProfile\AppData\Local\Packages\Microsoft.Windows.Cortana*\Settings
$settings | % {Stop-Process -Name 'SearchUI' -Force; Remove-Item $_.FullName -Recurse -Force}

 

For a named user profile

$profile = ‘joe.bloggs’

$settings = dir C:\Users\$profile\AppData\Local\Packages\Microsoft.Windows.Cortana*\Settings
$settings | % {Stop-Process -Name 'SearchUI' -Force; Remove-Item $_.FullName -Recurse -Force}

 

For all users on the system

$settings = dir C:\Users\*\AppData\Local\Packages\Microsoft.Windows.Cortana*\Settings
$settings | % {Stop-Process -Name 'SearchUI' -Force; Remove-Item $_.FullName -Recurse -Force}

 

Things to note

Working search bars will have file locks on the Setting folder. If you do not wish to see file lock errors messages use:

Remove-Item $_.FullName -Recurse -Force -ErrorAction SilentlyContinue.

 

Deployment Options

Your options for deployment of the script(s) are:

  1. Inject the script into a HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce entry for the system
  2. Inject the script into a HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce entry for the user
  3. Process the script as part of a logon script
  4. Use SCCM to deploy the script as a SCCM Package to the system/user
  5. Fire the script as a one-off/recurring Task Scheduler script via Group Policy
  6. Execute the script at the end of your MDT upgrade task sequence

Netgear Switch 1Gbps port at 100Mbps, goes up and down several times before settling at 100Mbps

This article discusses a problem in which jacking cables on a switch cause two or more ports to drop in and out of a shutdown / no shutdown sequence. After a few moments of going up/down, one or both of the ports will settle at a low speed (e.g. 1Gbps port at 100Mbps).

After adding new cabling to a LAG group, I experienced an intermittent fault in which one (or occasionally both) of the new cables would drop down to 100Mbps. If I removed the relevant keystone modules from the patch panel, the problem would cease.

 

Troubleshooting 1Gbps port at 100Mbps

Firstly, you should test the cable ensuring that all 8 pairs are up and in the correct sequence. A network tester should be used to do this.

If you used a punch tool during the install. Use a watchmakers screwdriver or the flat headed probe/shim on your punch tool to ensure that each wire in each pair is correctly and firmly seated. Ensure that there are no arched cables across the termination pins.

The most likely cause of a fault like this is a patch panel short. On a keystone patch panel, the keystone modules sit very close together. If the exposed copper ends of one keystone module touch the copper of a neighbour, the electrical circuit will short.

Data intended for one network port will be (poorly) transmitted down another one, causing signal corruption. The switch will attempt to respond by disabling pairs until it can get a clean signal. In the case of a 1Gbps Ethernet connection, it will disable 4 pairs, rendering the port 100Mbps. If there is still a short, it will fail to 10Mbps or shutdown the port.

A simple check for an electrical short is to place something non conductive – for example paper or electrical insulation tape – between the two keystone modules.

Photo of patch panel
Insert something non-conductive between the two patch panel keystones to check for an electrical short

The switch port will not automatically recover from an electrical short. You must jack/un-jack or sh/no sh the port to force speed renegotiation to occur.

If the insulator corrects the problem use some clippers to better trim the excess copper from the keystone, or leave the insulation in place permanently.

Performance impact of 512byte vs 4K sector sizes

When you are designing your storage subsystem. On modern hardware, you will often be asked to choose between formatting using 512 byte or 4K (4096 byte) sectors. This article discusses whether there is any statistically observable performance difference between the two in a 512 vs. 4K performance test.

NB: Do not get confused between the EXT4 INODE size and the LUN sector size. The INODE size places a mathematical cap on the number of files that a file system can store, and by consequence how large the volume can be. The sector size relates to how the file system interacts with the physical underlying hardware.

QNAP Sector Size selection
Sector Size selection on QNAP QTS 4.3.6

Method

  • A QNAP TS-1277XU-RP with 8x WD Red Pro 7200 RPM WD6003FFBX-68MU3N0 drives running firmware 83.00A83 were installed with 8 drives in bays 5 – 12
  • Storage shelf firmware was updated to QTS version 4.3.6.0923, providing the latest platform enhancements
  • A Storage Pool comprising all 8 disks in RAID 6 was configured, ensuring redundancy
  • A 4GB volume was added allowing QNAP app installation so that the systme could finish installing
  • The disk shelf was rebooted after it had completed its own setup tasks
  • RAID sync was allowed to fully complete over the next 12 hours
  • Two identical 4096 GB iSCSI targets were created with identical configurations apart from one having 512 byte and the other 4k sector sizes
  • SSD caching was disabled on the storage shelf
  • 2x10Gbps Ethernet, dedicated iSCSI connections were made available through two Dell PowerConnect SAN switches. Each NIC on its own VLAN. 9k jumbo frames were enabled accross the fabric
  • A Windows Server 2016 hypervisor was connected to the iSCSI target and mounted the storage volume. iSCSI MPIO was enabled in Round Robin mode. Representing a typical hypervisor configuration
  • The two storage LUNs were formatted with 64K NTFS partitions (recommended for dedicated VHDX volumes)
  • A Windows 10 VM was migrated onto each of the targets and the test performed using Anvil’s Storage Utilities 1.1.0.20140101. The VM had no live network connections. The Super Fetch and Windows Update services were disabled, preventing undesirable disk I/O. The VM was not rebooted between tests, had no other running tasks and had been idling for 6 hours prior to the test
  • No other tasks, load or data were present on the storage array

 

512 vs. 4K Performace Results

The results of the two tests are shown below.

Anvil Storage Utilities Screenshot with 512bytes results
Anvil Storage Utilities Screenshot with 512bytes results

"Anvil

IOPS
512 byte 4K 4K Diff 4K Diff % +/-
Read Seq 4MB 417.45 403.3 -14.15 -3.51
4K 3001.56 3164.56 163 5.15
4K QD4 6021.45 6006.7 -14.75 -0.25
4K QD16 24228.16 24062.61 -165.55 -0.69
32K 2742.39 2807.47 65.08 2.32
128K 2628.86 2620.8 -8.06 -0.31
Write Seq 4MB 233.2 230.79 -2.41 -1.04
4K 2090.79 2165.45 74.66 3.45
4K QD4 5976.18 5983.65 7.47 0.12
4K QD16 8254.84 7874.67 -380.17 -4.83

 

Analysis and Recommendations

The results show that there is little difference between the two. Repeating the tests multiple times showed that the figures for both the 512 byte and 4K LUNs are within the margin of error of each other. A bias towards 512 byte was consistently present, but was not statistically significant.

The drives in the test disk array are 512e drives. 512e is an industry transition technology between pure 512 byte and pure 4K drives. 512e drives use physical 4K sectors on the platter, but that the firmware uses 512 byte logic. A firmware emulation layer converts between the two. This creates a performance penalty during write operations due to the computation and delay of the re-mapping operation. Neither sector size will prevent this from occurring.

My recommendations are

  • If all of your drives are legacy 512 byte drives, only use 512
  • Should you intend to mount the LUN with an operating system that does not support 4K sectors. Only use 512
  • In situations where you have 512e drives, you can use either. Unless you intend to clone the LUN onto 4K drives in the future, stick with 512 for maximum compatibility
  • Never create an array that mixes 512 and 4K disks. Ensure that you create storage pools and volumes accordingly
  • Where all of your drives are 4K, only use 4K

 

WorkFolders Folder shows Sync Error even though its contents are fully synchronised

WorkFolders allows you to perform policy based file HTTPS synchronisation between corporate servers and BYOD devices or teleworker devices. This article discusses a workaround to a problem where an anonymous sync error appears on a directory despite all of its contents synchronising successfully.

Outline of the Problem

Assume the following directory structure

C:\Users\CompanyUser\WorkFolders\Documents\WorkFolders Test

The following files/folders are present within WorkFolders Test:

WorkFolders Test\Problem Folder
WorkFolders Test\Problem Folder\File in Problem Folder.docx
WorkFolders Test\This file is OK.txt

Windows Explorer will display a Green circle with a tick for file/folder object that is synchronised and a Red circle with a cross for a faulted file/folder. After synchronising, the sync results will display as follows:

WorkFolders Test\Problem Folder [CROSS]
WorkFolders Test\Problem Folder\File in Problem Folder.docx [TICK]
WorkFolders Test\This file is OK.txt [TICK]

No errors are displayed in the Control Panel WorkFolders applet. There are no related errors in the clients WorkFolders Management/Operational Event Viewer logs. No relevant errors are present in the file servers SyncShare Operational/Reporting logs.

WorkFolders Error Screenshot - outer folder
The parent folder shows that its sub-folder has a sync error
WorkFolders Error Screenshot - inner folder
The contents of the error’d folder are however correctly synchronised.

Analysis

Although WorkFolders is indicating that the issue is being caused by the “Problem Folder” directory. The issue is being caused by the “File in Problem Folder.docx”.

The following symptoms will be true:

  1. Renaming “Problem Folder” will not fix the issue
  2. Altering the filename of “File in Problem Folder” will not fix the issue
  3. Changing the “File in Problem Folder.docx” file extension (e.g. to .txt) will not fix the issue
  4. Opening and saving the “File in Problem Folder.docx” will not solve the issue
  5. Moving “File in Problem Folder.docx” out of “Problem Folder” will clear the sync error, but the error will immediately migrate to the new location
  6. Rebooting the client computer will not help
  7. Restarting the server will not help
  8. The file does not have any connected temp files or lock files associated with it in the client file system

 

There is nothing wrong with the file itself. It is not corrupt, pay-loaded with a virus or violating any policy. It is my (unproven) belief that the record for the file in the WorkFolders synchronisation database is corrupt. Performing any of the above steps will not alter the record in the WorkFolders client database, thus the problem cannot be ameliorated.

 

Fixing the problem

One you have identified the problem file(s). You can use one of the methods below to correct the error.

Save the file as a completely new file

  1. Open the file in its associated editor (e.g. Microsoft Word for docx files)
  2. File > Save as…
  3. Save the file in its original location, but with a different file name (do not overwrite the original)
  4. Delete the original file
  5. Allow WorkFolders to re-sync
  6. Rename the new file as required

This approach is easy for an end-user to perform, but can be very time consuming if you are troubleshooting a large number of such issues. It requires you to know which file is causing the problem in the first place.

 

Compression

  1. Compress the file using Windows Compressed folders (Right click > Send to… > Compressed (zipped) file)
  2. Delete the original file
  3. Wait for the folder to re-sync and clear the error
  4. Extract the original file from the zip back into the desired location

This method will create a new record in the WorkFolders synchronisation database and the error will not reappear. You can use the technique to fix an entire folder structure without having to first identify the problem file. It is also easy for an end-user to perform.

 

Move the file

  1. Move the file outside of the WorkFolders monitored file system. For example, move the file to C:\ or into the Recycle Bin
  2. Allow the original folder to re-sync and clear the error
  3. Return the original file to its original location and allow it to re-sync

Again, this method will create a new synchronisation record. In a managed environment this may be harder for an end-user to perform due to permissions. It is however easier for an administrator to perform as you can cut/paste the entire file structure out and then back into the WorkFolders sync root.

If you use this method, remember to move it to a location within the same drive letter. If you do, the move will preserve permissions, file dates and will not physically copy the underlying data to the new location (just update the MFT).