不，真的，你需要将所有未处理的消息传递给DefWindowProc，第二部分

<p>一位客户报告了Windows中的一个内存泄漏问题，该问题发生在他们调用<code>RegisterDragDrop</code>后接着调用<code>RevokeDragDrop</code>时。他们提供了一个示例程序的时间旅行跟踪，展示了这个问题。（尽管出于某种原因，他们没有提供程序本身；只提供了时间旅行跟踪。）</p> <p>现在，如果调用<code>RegisterDragDrop</code>后接着调用<code>RevokeDragDrop</code>会导致内存泄漏，那就很奇怪了，因为这种模式被数千个应用程序大量使用，包括Windows本身的许多部分，所以如果这种模式本身有内存泄漏，你可能会认为它早就被报告了。</p> <p>我怀疑他们的示例程序有些特殊之处。</p> <p>不久前，我注意到<a title="No, really, you need to pass all unhandled messages to DefWindowProc" href="https://devblogs.microsoft.com/oldnewthing/20060425-16/?p=31413">不，真的，你需要将所有未处理的消息传递给DefWindowProc</a>。那就是问题的根源。</p> <p>通过调试时间旅行跟踪，发现确实，他们调用了<code>RegisterDragDrop</code>，然后调用了<code>RevokeDragDrop</code>。但还有更多情况发生。当窗口收到<code>WM_DESTROY</code>消息时，它会清理所有状态。对于<code>WM_DESTROY</code>之后到达的任何消息，窗口过程会寻找其特殊状态但看不到，因此它放弃并返回0，而不将消息传递给<code>DefWindowProc</code>。</p> <p>哎呀。</p> <p>如果窗口过程不知道该做什么，它应该将所有消息传递给<code>DefWindowProc</code>。在这种情况下，这很重要，因为其中一些消息是清理消息，这些清理消息的作用之一是释放仍在周围的最后几个内存片段。</p> <p><b>额外讨论</b>：但如果我注册一个拖放目标，然后撤销它，撤销操作不应该释放注册调用所分配的所有内存吗？</p> <p>没有要求说注册某物然后注销它会立即释放与注册相关的所有内存。系统可以缓存它认为会再次需要的内容。</p> <p>在这种情况下，发生的是<code>RegisterDragDrop</code>函数使用了一个由许多组件共享的基础设施。该基础设施在第一次有人需要时被创建并附加到窗口，并在窗口被销毁时清理。内存没有被泄漏。它只是缓存在窗口上，等待被另一个操作使用。缓存在窗口被销毁时被销毁。</p> <p>但它假设你给了<code>DefWindowProc</code>一个机会来执行该清理。</p> <p>文章<a href="https://devblogs.microsoft.com/oldnewthing/20260924-00/?p=112728/">不，真的，你需要将所有未处理的消息传递给DefWindowProc，第二部分</a>首次发表于<a href="https://devblogs.microsoft.com/oldnewthing">The Old New Thing</a>。</p>