2

I have weird problem when tracing my Media Foundation application using mftrace: when running in mftrace, the application crashes with an access violation. It is running from the Visual Studio debugger, but I need to get mftrace running to troubleshoot a Media Foundation problem. After investigating the problem for quite some time, I have added my own tracing code and discovered the following:

2952 22320,5CE8 13:05:14.78185 CMFStreamSinkDetours::GetEvent @000001CFB1E85BD0 - enter
2953 22320,5CE8 13:05:14.78455 CKernel32ExportDetours::OutputDebugStringA @ [23784 ENTER]RtspStreamSinkBase<class RtspVideoStreamSink>::IsMediaTypeSupported 
2954            __M_F_T_R_A_C_E___LOG__

The method RtspStreamSinkBase<class RtspVideoStreamSink>::IsMediaTypeSupported is the one actually crashing due to an invalid (but non-null) pointer passed in as media type. I know that from attaching the debugger to the crashed process.

For me, it looks like as if mftrace thinks it is calling GetEvent, but the method actually invoked is IsMediaTypeSupported.

Has anyone encountered such an issue before? What was the solution? What could cause such an issue?

Best regards, Christoph

Update: I did some further Research and found two possible areas where it might go wrong: first, I am using ATL for my implementation (not only ATL::CComPtr, but also the other base classes like ATL::CCoClass for using the registrar etc.). Although I have worked with detours myself, I do not know how mftrace uses it. I assume that they are overwriting the vtable pointers.

Could it be that using ATL prevents the detours from being installed correctly? Is it, in principle, possible to use ATL for implementing MFT classes? Has anyone done this successfully (most samples I see in the internet do all the COM stuff manually)?

The second observation is that only the debug build crashes in mftrace. It therefore might be that some unintended side effect in debug code (eg assert(ptr = nullptr)) is causing the issue. I have not found one in my own code so far, though.

Could it be that the reference tracking in ATL (#define _ATL_DEBUG_INTERFACES) interferes with detours/mftrace?

Christoph
  • 1,964
  • 2
  • 27
  • 44
  • Hi, you wrote `RtspStreamSinkBase` - is it YOUR code or is it from Media Foundation SDK? – Evgeny Pereguda Jun 30 '16 at 22:30
  • Yes, that's my code. This is where I added the debug Output, which indicates that the vtable is messed up in mftrace. – Christoph Jul 02 '16 at 11:41
  • I use ATL for MF development and I have not seen any issues. Sample code is presumably avoiding ATL because ATL was not available in all VS versions. What about non-mftrace runs, do they work fine? – Roman R. Jul 03 '16 at 10:22
  • Non-`mftrace` runs do not crash as well as release builds in `mftrace`. Given that you successfully build MFTs using ATL base classes, I think I will investigate the side effect direction more thoroughly. – Christoph Jul 03 '16 at 14:58
  • @RomanR. May I ask whether you also use `ATL_NO_VTABLE` in your code? – Christoph Jul 03 '16 at 15:36
  • Yes, I use "no vtable" specifier often. I don't use mftrace often though. – Roman R. Jul 03 '16 at 15:54
  • I hope to find the reason for `MF_E_NO_BITPUMP` when I start my topology. The weird thing is that, as I found out now, the topology is running in release mode (but I do not see anything), it is producing `MF_E_NO_BITPUMP` in debug mode and it is crashing in `mftrace` ... I have no idea what it wants to tell me with "Internal. Bitpump not found" ... – Christoph Jul 04 '16 at 13:08

1 Answers1

1

I finally found the problem: as it turns out, enabling #define _ATL_DEBUG_INTERFACES is a very bad idea with ATL-based MF classes. After I removed this define, the internal error disappeared and the trace does not crash any more.

Christoph
  • 1,964
  • 2
  • 27
  • 44