The Windows 10 emoji picker has been broken for a month
August 8, 2025
On July 8th, Microsoft released update KB5062554 to the world. It contains no documented changes or features. This update broke the emoji panel’s search functionality for all Windows 10 users.
The broken grammar isn't the bug, that's just... how it is
The emoji panel (accessed with Win + .) is the official way of typing emojis on Windows. I’m sure many users don’t know it exists. It’s hardly discoverable, and most desktop apps offer their own little picker. Nonetheless, I use it a few times a week (for my sins), and each time it doesn’t work I’m wrongfooted.
It’s a really embarrassing regression, right? Without the search, you have to scroll through several thousand emoji in a postage stamp sized window to find the one you want (some designers do seem to think this is acceptable UX. I disagree).
What I find bizarre about this situation isn’t just the fact that this bug escaped, it’s that Microsoft… don’t seem to care. They didn’t acknowledge the problem till 6 days later, and only after media outlets like BleepingComputer reported on it.
A fix finally appeared in the preview update KB5062649 on the 22nd, a full 2 weeks later. We can expect it to be in the next Patch Tuesday release on August 12th - over a month after it was introduced. What the hell?
I’ve done lots of dramatic moaning to people in my life about this minor issue, and what it means for the very future of software engineering and civilization in general, etc. So I decided to look into it and understand why a fix takes so long.
Why does it take so long?
Windows has been on the same update schedule for decades: patches are released on the 2nd Tuesday of each month, also known as Patch Tuesday.
If a patch introduces a serious, system-breaking bug, an out-of-band release may be issued to address it before the next Patch Tuesday, but this is only done for critical fixes.
Also, optional preview updates sometimes appear outside this schedule. They can be manually installed, and may also be installed if the ‘Get the latest updates as soon as they’re available’ setting is enabled in Windows Update. I did have this enabled, but the update containing the fix was not installed for me until I did it manually.
Microsoft does not really roll back patches. They do now have a mechanism for rolling back changes within these patches, called Known Issue Rollback. The idea is that the new code is behind a feature flag, and can be reverted if problems arise:
if (BugFix_123456 :: IsEnabled()) { // New Code (default path - enabled by default) } else { // Previous Code (alternate path - disabled by default) }
I pity the devs who have to write code this way, but fortunately they don’t have to do it very often because this policy only applies for non-security bugfixes, and almost all patches these days claim to just be security fixes, including the one which introduced this bug. Patching a security flaw can reveal its existence, so these changes can’t really be rolled back.
All this means that bugs like this one, which have easy workarounds (googling for emojis) are never fixed until next month’s Patch Tuesday. No matter how annoying or embarrassing they are.
What happened to Windows-as-a-service?
Back in 2015 when Windows 10 was introduced, we were assured it was “the last version of Windows” and introduced to the new Windows-as-a-service model. This sounded like a radical departure from the update model of the past - instead of just one update on the 2nd Tuesday of each month, small updates would be continuously pushed out in consecutive ‘rings’.
Business users could get the patches after they’ve been battletested in the wild, and more risk-tolerant consumer users could get new fixes and features immediately. El Reg wrote an obituary for Patch Tuesday.
I’m not sure whether these plans changed, or were just misinterpreted, but in reality the update schedule did not change significantly. There is a mechanism (described above) for brave users to get preview updates. And there is a smaller beta channel to get them even earlier. But despite this, obvious bugs are still escaping. Why?
Exploit Wednesday
I believe the answer is that most security updates are not rolled out gradually. Once a patch for a flaw is released, Microsoft is effectively announcing the existence of the flaw to the world. This leads to the ‘Exploit Wednesday’ phenomenon, where malware authors race to exploit these newly disclosed vulnerabilities before devices are patched. Many famous viruses were able to spread this way.
This also explains why Microsoft could not simply roll back the patch that caused the bug, and instead had to fix whatever unholy thing the emoji panel was doing that caused it to break on an internal Windows change.
Scrolling through the list of recent out-of-band updates, I began to feel a lot more empathy for release managers at Microsoft. The latest one fixed an issue which was bricking Surface Hub v1s, a device I didn’t know existed.
There is so much that could go so wrong, and when you weigh that against timely access to emojis… I begin to feel the delay is justified. Even if a fix only touched high level application code, to immediately roll it out after an internal regression test which is clearly lacking would be a terrible idea.
Unfortunately, these two factors compound in a tricky way: Security fixes cannot be rolled out gradually, but general bug fixes must be.
What about regression testing, anway?
My feeling is that Microsoft, and other companies too, have relied far too heavily on their beta testers to identify bugs. They expected problems to be surfaced by telemetry and user reports, which are less effort than actual testing. No need to write tests for our new emoji panel, the users will tell us if it breaks! There are countless drawbacks to this method, one being that this takes a lot longer than automated tests.
But the biggie is that they can’t use this method for security patches. They are pushed out into the world without sufficent testing because the systems for doing this have been allowed to atrophy.
I don’t know the details, but the bricking problem above seems like an example of this. Aren’t they doing regression tests on their own first-party hardware?
Are they trying to kill Windows 10 intentionally?
Well, yes, kind of, but that’s not news. Windows 10 is EOL on October 14, 2025. Consumers can get another year of updates either with cold hard cash or the insane bing battle pass, but I don’t have much confidence in the quality of those updates.
At the end of the day, I understand the struggles of working on near-EOL software. You want to do right by your users, but when resources are constrained, tradeoffs must be made. And in this case, focusing on stability is the correct choice.
Some folks online have suggested that Microsoft introduced this and other issues kind-of-intentionally, in order to push people to Windows 11. I don’t believe that for a second. Microsoft do actually have a reputation to uphold. It’s always possible they were aware of this minor bug and released the update anyway, but if that’s the case, I’m sure they did it in the interests of users. Resource constraints are hard.
Trying not to be angry about things
I think software engineers often get annoyed by percieved imperfections and inefficiencies in the world. There’s nothing wrong with questioning things, but choosing to believe others are incompetent or malicious is unhealthy.
I find that when I’m annoyed by things like this and actually dig down into it, the feeling evaporates as I come to appreciate all the complexities and challenges. It’s humbling, and next time I get unreasonably annoyed at something I can remember that feeling, and accept that a lot of things are harder than they seem on the surface.