4 月 24 日消息，微软资深工程师 Raymond Chen 昨日（4 月 23 日）发布博文，披露了一起典型的 Windows 资源管理器崩溃案例，指出崩溃并非 Windows 自身缺陷导致，而是由某第三方卸载程序错误的函数调用约定导致内存损坏所致。
在一次常规调试会议中，Chen 的同事发现 Windows（原文并未明确具体版本）文件管理器崩溃率出现异常峰值。通过检查崩溃转储文件，Chen 迅速锁定了问题源头：在 64 位系统上运行的 32 位资源管理器进程。
援引博文介绍，在 64 位 Windows 系统中，微软出于兼容性考虑保留了 32 位版本的文件资源管理器，通常位于 C:/Windows/SysWOW64 目录。
该版本一般不通过用户直接操作触发，主要由传统的 32 位应用程序调用。Chen 据此推断，崩溃极大概率源于某款 32 位第三方应用的非标准交互，而非用户常规操作或系统内核问题。
Chen 深入分析特定版本的故障卸载程序后，发现了导致崩溃的具体技术缺陷。该卸载程序的注入代码包含一个执行文件操作的循环，若操作失败会暂停后重试。
然而，开发者在编写代码时犯下了致命错误：未正确指定函数调用约定。代码错误地使用__cdecl 约定调用 Windows 函数，而 Windows 函数实际遵循__stdcall 约定。
这两种约定在堆栈清理机制上存在根本差异：__stdcall 由被调用者清理堆栈参数，而__cdecl 则要求调用者清理。
这种调用约定不匹配引发了严重的堆栈破坏问题。每次调用 Windows 函数后，参数被压入堆栈，Windows 函数执行后弹出参数，随后调用代码再次尝试弹出参数。这导致堆栈指针每次循环都错误地移动，逐步蚕食程序自身的堆栈空间。由于重试循环执行次数极多，堆栈最终被消耗殆尽，堆栈指针甚至递增到了注入代码所在的内存区域。
这种内存损坏导致了栈空间被“吃光”，进而直接拖垮了文件资源管理器进程。科技媒体 NeoWin 指出，在系统组件出现崩溃后，公众往往习惯性归咎于操作系统，但第三方软件开发者的技术失误同样可能成为系统不稳定的根源。
相关阅读：
《微软工程师：别总把锅甩给 Windows 更新，Win11 系统崩溃不一定是更新的错》
