未释放的DirectShow CSource过滤器使程序在过程关闭时崩溃 [英] Unreleased DirectShow CSource filter makes program crash at process shutdown

问题描述

我正在开发一个DirectShow CSource捕获过滤器。它工作正常，但当我关闭使用过滤器的程序（在这种情况下，我使用VLC测试，但同样发生在其他程序），程序崩溃（如果我在Visual Studio中调试它，然后一个断点被触发）。

I'm developing a DirectShow CSource capture filter. It works fine, but when I close the program that is using the filter (in this case I'm testing with VLC, but the same happens with other programs), the program crashes (if I'm debugging it in Visual Studio then a breakpoint is triggered).

我一直在捕捉这个问题一段时间，发现我的源过滤器和我的源码流都没有被释放;这是，他们的引用计数器是1在程序结束时，DllCanUnloadNow（）函数报告有2个对象仍在使用，当CoUninitialize（）被调用时，程序崩溃。

I've been hunting down this problem for some time now and found that both, my source filter and my source stream are not being released; this is, their reference counter is 1 at the end of the program, DllCanUnloadNow() function reports that there are 2 objects still in use, and, when CoUninitialize() is invoked, the program crashes.

我很确定引用计数器正在被正确处理，因为我使用基类实现。在我的软件中唯一不寻常的事情，我可以想到的是，我使用我自己的版本的DllGetClassObject（）：我配置的.DEF文件有MyDllGetClassObject（）导出而不是DllGetClassObject（），所以我可以插入一些代码之前调用默认实现。我不认为这是一个问题，因为我检查了在MyDllGetClassObject（）结束时返回的所有对象的引用计数器是1。

I'm pretty sure that the reference counters are being handled correctly since I'm using the base classes implementation. The only unusual thing in my software that I can think of is that I'm using my own version of DllGetClassObject(): I configured the .DEF file to have MyDllGetClassObject() exported instead of DllGetClassObject() so I could insert some code before invoking the default implementation. I don't think this is a problem since I've checked that the reference counter of all objects I return at the end of MyDllGetClassObject() is 1.

我猜我缺少一些关于过滤器的生命周期，但不能弄清楚什么（这是我开发的第一个捕获过滤器）。任何建议？

I guess I'm missing something about the lifecycle of the filter, but can't figure out what (this is the very first capture filter I'm developing). Any suggestion?

提前感谢，

Guillermo

Guillermo

推荐答案

我终于知道发生了什么。在我的源过滤器中的静态方法 InitializeInstance 使用 bLoading == false 和 rclsid = =<过滤器的GUID> 。这似乎是从过滤器实例释放剩余引用计数器的适当位置。

I finally figured out what was going on. The static method InitializeInstance in my source filter is invoked with bLoading == false and rclsid == <the GUID of my filter> at process shutdown. That seems to be the appropriate place to release that remaining reference counter from the filter instance.

我有一个关键的想法是释放所有COM对象之前 CoUninitialize 前一段时间，来自StackOverflow上的另一篇帖子，名为 DirectShow代码在退出后崩溃（PushSourceDesktop示例）。我需要的只是一点点的DirectShow过滤器生命周期的知识。

I got the key idea of how important is to release all COM objects before CoUninitialize some time ago from another post on StackOverflow entitled DirectShow code crashes after exit (PushSourceDesktop sample). All I needed was just a little bit more knowledge on DirectShow filters lifecycle.

无论如何，谢谢你的努力，罗马，我知道这个线程从头开始：）

Anyway, thank you for your efforts, Roman, I know how vague this thread sounded from the beginning :)

这篇关于未释放的DirectShow CSource过滤器使程序在过程关闭时崩溃的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！