Share via

ACS SDK WinUI3 App crashes randomly in MSVCP140.dll after video call teardown

Charupak 1 Reputation point
2026-05-15T12:02:53.4633333+00:00

Our app makes repeated outgoing video calls (1-to-1, Teams interop). After several calls in a session, the app crashes randomly during hangup process at some nth call with a fatal access violation inside MSVCP140.dll Exception: 0xc0000005

It seems like crash occuring inside ACS native layer (RtmMvrMf.dll, skypert.dll, MSVCP140.dll) during call teardown, but the crash is not deterministic, could happen on 3rd to 6th call in the same session

This happen when I use .net 8 + ACS SDK 1.14 version,

but if I use .net 6 + ACS SDK 1.11.1 version, it works fine.

Azure Communication Services

2 answers

Sort by: Most helpful
  1. Golla Venkata Pavani 5,745 Reputation points Microsoft External Staff Moderator
    2026-05-15T14:25:33.2166667+00:00

    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:

    1. 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.
    2. 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
    
    1. 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.

    Was this answer helpful?


  2. AI answer

    2026-05-15T12:03:13.0633333+00:00

    The behavior described (random crash in MSVCP140.dll during ACS video call teardown, only with .NET 8 + ACS 1.14, but not with .NET 6 + ACS 1.11.1) isn’t directly covered in the provided context, so only general ACS troubleshooting guidance can be given.

    For unstable behavior in ACS Calling/Call Automation scenarios, the recommended path is:

    1. Collect detailed call information for a reproducible case:
      • ACS resource ID
      • Call ID
      • Participant ID These can be obtained as follows:
         // call ID
         call.id
         // local participant ID
         call.info.participantId
      
    2. Correlate the crash with ACS-side events:
      • Check whether the crash aligns with specific ACS callbacks (for example, CallDisconnected or AnswerFailed events) and their status codes/subcodes.
      • If any 4xx/5xx codes appear in logs around the time of teardown, capture them, including subcodes, as they indicate client/server errors that may help support identify a problematic flow.
    3. Open a support ticket with Microsoft:
      • Provide the collected ACS resource ID, call ID, participant ID, and crash details (exception code 0xc0000005, stack trace showing RtmMvrMf.dll / skypert.dll / MSVCP140.dll, and the specific SDK/runtime versions: .NET 8 + ACS 1.14 vs .NET 6 + ACS 1.11.1).
      • Include any patterns observed (e.g., only after multiple sequential calls in the same process, only with Teams interop, etc.).
    4. As an interim mitigation while investigating with support:
      • Prefer the known-stable combination (.NET 6 + ACS 1.11.1) in production if that is acceptable.
      • Add monitoring and logging around call teardown and media actions so that any ACS error codes (4xx/5xx) and subcodes are captured before the crash.

    Because the crash is in the native layer (skypert.dll/MSVCP140.dll) and only appears with newer runtime/SDK, a product fix or targeted guidance from Microsoft support will likely be required.


    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.