The "Windows bug" that mysteriously crashed File Explorer

Raymond Chen is a veteran Microsoft engineer who has been involved in the development of Windows for several decades. Here at Neowin, we usually cover his intriguing stories related to the world of Microsoft and Windows, such as explainers about how a bug in the OS is not always Redmond's fault, ways in which Windows 95 prevented chaos from external installers, the "online" nature of WinHelp, and more.

Now, Chen has recounted a rather intriguing story where a colleague was investigating a mysterious rise in File Explorer crashes. Naturally, with an OS installed across billions of heterogeneous endpoints, the usual suspect was some buggy code in Windows itself.

However, upon examining the crash dumps, it was discovered that it was the 32-bit File Explorer crashing on a 64-bit Windows installation. Now, some of you may not be aware, but Microsoft actually ships a 32-bit version of File Explorer in 64-bit Windows for compatibility reasons. It usually can't be triggered through normal user interaction and is typically utilized by legacy 32-bit apps. You can locate the 32-bit executable of File Explorer in the C:/Windows/SysWOW64 directory, usually.

When Chen noticed that it was the 32-bit Explorer that was crashing, he determined that it was highly likely that it was not due to user interaction. Instead, it was much more probable that a third-party 32-bit app was interacting with Windows in a non-standard way.

Upon further investigation, it was revealed that the code for a third-party uninstaller was iterating a loop where it was unsuccessfully trying to perform some file operations. This isn't unusual because uninstallers typically tend to clean up application files during their execution process. However, the code author was using the wrong function calling convention used to pop parameters from the stack.

Since it was constantly failing and retrying, it kept popping parameters from the stack until the stack pointer had actually moved into the calling code which was being executed. This meant that the stack had been eaten away until it had caused a corruption, causing File Explorer to crash.

If you want to understand the technical details a bit better, do check out stack data structures in computer science on Wikipedia here, or any academic website that you prefer.

While Chen hasn't gone into details regarding which application's uninstaller was actually causing the issue or if Microsoft worked with the developer to fix it, this incident does highlight how just because a Windows component is crashing doesn't always mean that it's Microsoft or the operating system's fault. But then again, sometimes it actually is.