根据https://docs.microsoft.com/en-us/windows/desktop/api/mfidl/nf-mfidl-imfmediasession-close，一旦调用IMFMediaSession.Close，我应该会收到一个名为MESessionClosed的事件，这种情况并非总是如此，但在大多数情况下都是如此。
我有一些客户的本机内存泄漏在增加，我认为原因之一就是我上面提到的原因，或者是MediaFoundation与GPU驱动程序的交互，因为我分析了转储，发现有数千个线程在其中打开。 atiumd64.dll，方法OpenAdapter：
00 000000b0`cecff8f8 00007ff8`c1cf9252 ntdll!NtWaitForSingleObject+0x14
01 000000b0`cecff900 00007ff8`752d2ccd KERNELBASE!WaitForSingleObjectEx+0xa2
02 000000b0`cecff9a0 00007ff8`757bf247 atiumd64!OpenAdapter+0x63ced
03 000000b0`cecff9d0 00007ff8`757bf3ee
atiumd64!XdxInitXopAdapterServices+0x3d0a57
04 000000b0`cecffa00 00007ff8`c4293034
atiumd64!XdxInitXopAdapterServices+0x3d0bfe
05 000000b0`cecffa30 00007ff8`c4d91461 kernel32!BaseThreadInitThunk+0x14
06 000000b0`cecffa60 00000000`00000000 ntdll!RtlUserThreadStart+0x21
在4天的时间里，我总共创建了160000个拓扑，其中大约100个根本没有引发MESessionClosed，我担心这些会导致泄漏。
在未发送MESessionClosed的情况下，我注意到它们都有一个共同的错误：-1072870850，即MF_E_SAMPLEALLOCATOR_EMPTY。
我想知道是否有人有MediaFoundation的经验，没有根据文档提出MESessionClosed。
答案 0 :(得分：1)
MESessionClosed事件是由于异步执行的IMFMediaSession::Close调用完成而创建的。您没有得到指示关闭问题，也许是其中一个原语参与拓扑的问题，例如，由于某个对象上的引用过高或泄漏导致无法终止流。
给出问题的描述，也许解决该问题的最佳方法是将调试器附加到该进程（实时或创建转储并以交互方式对其进行审阅），期望找到一个线程等待关闭或完成。
您先前看到的MF_E_SAMPLEALLOCATOR_EMPTY可能表明，指向样本之一的泄漏指针会阻止终止其中一个原语中的样本分配器，从而造成死锁。
除此之外，您可能需要对该进程执行mftrace，并将封闭会话产生的输出与另一个失败的输出进行比较。
您也感兴趣的一件事，包括将其作为问题的一部分，是了解拓扑，尤其是它是否具有您可以暂时排除的第三方或可选段。由于您无法直接对MF内部进行大量调试，因此更改拓扑的选项可以帮助您将问题的范围缩小到特定的原语，这给您带来麻烦。如果拓扑具有自己的原语，则有兴趣查看其终止行为。