An Azure communication platform for deploying applications across devices and platforms.
Hi @Charupak ,
Thank you for the detailed report. The symptoms you described — a non-deterministic access violation in native ACS components during repeated call teardown (especially with video and Teams interop) on .NET 8 + SDK 1.14 — point to a resource cleanup issue in the calling media layer.
This type of access violation (0xc0000005) in MSVCP140.dll triggered from ACS native components is typically related to resource cleanup timing or accumulated state in the media pipeline during repeated call teardown.
Recommendations:
- Upgrade to the latest WindowsClient SDK
The strongest first step is to move to the newest version of Azure.Communication.Calling.WindowsClient (currently 1.15.x). Newer releases include various stability, performance, and media handling improvements. It also has explicit support for net8.0-windows. - Strengthen call teardown and disposal Make sure you're fully cleaning up resources after each call. Incomplete disposal of calls, renderers, or the CallAgent can leave native objects in a bad state, especially with video streams.
if (call != null)
{
try
{
await call.HangUpAsync(new HangUpOptions { ForEveryone = false });
}
catch { /* log if needed */ }
call.Dispose();
call = null;
}
// Also dispose renderers, local video streams, and CallAgent when appropriate
- Visual C++ Runtime
Repair or reinstall the latest Microsoft Visual C++ Redistributable (2015-2022) for x64 (and x86 if needed). Many native SDK crashes in MSVCP140.dll are resolved this way.
Reference:
https://learn.microsoft.com/en-us/azure/communication-services/concepts/known-issues?pivots=platform-web
https://learn.microsoft.com/en-us/azure/communication-services/concepts/best-practices?tabs=windows&pivots=platform-web
Kindly let us know if the above helps or you need further assistance on this issue.
Please "accept" if the information helped you. This will help us and others in the community as well.