Sherief, FYI

Rampant Software

In a 1987 email, Leslie Lamport described a distributed system as “one in which the failure of a computer you didn’t even know existed can render your own computer unusable”. On the morning of February 5th, 2020 many people discovered their Windows 10 Start Menu’s search feature is not showing them any results - I was one of them, and to me this was yet another debilitating issue in SearchUI.exe that is both significantly detrimental to my productivity on my personal computer and entirely avoidable.

A few months before that I noticed that sometimes when I try to launch the Start Menu nothing happens - it’d refuse to show anything for a second or two despite the button itself giving visual feedback that it has been clicked (or tapped via touch screen, or invoked via the keyboard Start key - I tried everything). A few seconds later it would get back to normal but only for a few minutes. It felt like being in a random Operant Conditioning chamber, AKA Skinner Box, and instead of a pellet I was rewarded with the Start Menu. And when the Start Menu would show up, more often than not the search UI that appears once I start typing wouldn’t respond to the mouse cursor, always showing a busy cursor when hovered over and never seeming to improve.

It seemed I wasn’t alone in this plight. I found this post from over two years ago with the same symptoms, and this long discussion on Microsoft’s Answers website. The solutions seemed to range between “nuke your system” and “digital snake-oil”, and none of them worked for me. It was pretty frustrating to have such a basic feature not work, and while I do use voidtools’ Everything for most of my searches, the convenience and ease-of-access of search bound to the Start key on my keyboard was worth it pretty often.

I decided to dig deeper, and I noticed the window belongs to SearchUI.exe and an ETW trace showed that it is indeed reponsible for the UI delay:

Cortana's SearchUI.exe responsible for UI Delay

Killing that process made all my woes go away - No delayed Start Menu, no unresponsive Search UI, but only for minutes at a time. I didn’t dig too deep, but it seems that SearchUI.exe is asked to do something every time you attempt to launch the Start Menu, and that something involves talking to another machine over the network and even when that machine has no issues the local process can somehow get wedged in a dark place and the Start Menu won’t show up until it times out completely.

Someone, dubiously rationally and certainly not competently, put a network operation with a failure mode that causes delay in the order of seconds (in the case of trying to launch the Start Menu) and up to potentially infinite time (when the UI is stuck in the hourglass state), and then proceeded to insert that operation on the critical path that is the Start Menu of Windows. With no option to turn it off as far as I know - and probably to prop-up Bing, another Microsoft process, if I were to guess. And regardless of whether you like or dislike Bing, the lack of choice is almost never something that is done in order to improve the end-user’s experience.

The only solution I found to get a statistically more reliable Start Menu experience was to write a background process that kills SearchUI.exe every few minutes if it’s not the foreground window. The software that I paid for to run on my own hardware has gone rampant, and said rampancy is being watched over by the system making sure that like a phoenix it keeps coming back to life over and over again - and in this Greek tragery I’m not sure whether my recurring suffering is Sisyphean or Promethean.

But I probably made some Bing metric look good.

The code for SearchUI Killer can be found here. I have reported this bug, providing the ETW traces, using the Windows 10 software reporting tool and attempted to contact a Microsoft community manager working on Windows UI over 90 days ago. I have not received a response in either case.