I'm seeing a case where a long running service based on UCMA4 (which uses media foundation) spikes CPU usage. Loading this up in process explorer, I can see the thread sitting at 25% CPU (on a 4 core system), with a cycles delta of over 2 billion. The stack looks like this:
ntoskrnl.exe!KiCpuId+0xb6
ntoskrnl.exe!KeWaitForMutexObject+0x137b
ntoskrnl.exe!KeWaitForMutexObject+0x1cf
ntoskrnl.exe!KeTestAlertThread+0x13d
ntoskrnl.exe!KeInitializeApc+0xba0
ntoskrnl.exe!IoPageRead+0x27c1
ntdll.dll!RtlEnterCriticalSection
MFReadWrite.dll!DllCanUnloadNow+0x303c8
MFReadWrite.dll!DllCanUnloadNow+0x30489
MFPlat.DLL!MFPutWaitingWorkItem+0x7af
ntdll.dll!RtlWakeAllConditionVariable+0x259
ntdll.dll!RtlTryEnterCriticalSection+0xbc2
KERNEL32.dll!BaseThreadInitThunk+0x1a
ntdll.dll!RtlUserThreadStart+0x21
I tried enabling the media foundation logs in event viewer, but nothing new got logged. I haven't tried restarting the process yet, since it won't get into this state normally, and it could run for weeks without this problem manifesting again. This is tricky to trace back to application code because of the UCMA abstraction. Has anyone else seen something similar, or do you have suggestions on how else to trace this back to something that we're calling? I suspect that it's a bug in the Microsoft.RTC.Collaboration.AudioVideo.dll, or Microsoft.RTC.Collaboration, but I can't say for sure.
Thanks!