未发布的 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?

提前谢谢你，

吉列尔莫

推荐答案

我终于弄清楚是怎么回事了.我的源过滤器中的静态方法 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.

不久前，我从 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.

无论如何，谢谢你的努力，Roman，我知道这个话题从一开始就听起来很模糊:)

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

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