Crash when joining from waiting room with video enabled

Meeting SDK
1

Description
We’ve been seeing crashes sporadically when joining meetings from a waiting room. We suspect that these crashes are due to heap corruption. In attempting to debug the issue we downloaded a vanilla version of the latest Meeting SDK Demo App (zoom-sdk-windows-5.7.6.1081) and enabled “native corruption detection.” We’re able to consistently reproduce a crash when joining from a waiting room with video enabled or enabling video after joining a meeting from a waiting room.

Which Desktop Meeting SDK version?
zoom-sdk-windows-5.7.6.1081

To Reproduce(If applicable)

  1. [Meeting host] Setup a zoom meeting WITHOUT a waiting room
  2. In Visual Studio enable “native corruption detection” in the “Diagnostic Tools Property Pages” window (Debug > Windows > Show Diagnostic Tools > Select Tools > Settings > Memory Profiler Tool > Configuration).
  3. Run the demo app
  4. Click “SetDomain” with https://zoom.us
  5. Enter JWT and click “Auth”
  6. Click “Only Join”
  7. Enter meeting room, name, and meeting password and click “Join”
  8. Enable video
  9. [Meeting host] Send participant to waiting room
  10. Join meeting from waiting room with video enabled.

This also works if you join from a meeting room with video off and then enable it.

Screenshots

Screen Shot 2021-12-10 at 10.57.41 AM
Screen Shot 2021-12-10 at 10.57.41 AM822×526 21.5 KB

2

Hi @nickn, thanks for the post.

I’ve tried reproducing this a few times following the exact steps you’ve included, but was able to successfully join the meeting 100% of the time with my video being successfully received by the host of the meeting. I’ve tested in both custom and default UI modes, but there is no difference in the behavior. Are there any other meeting settings you may have enabled which could be causing this?

Thanks!

3

Hey @jon.zoom,

Thanks for looking into this.

Just to confirm, did you enable “native corruption detection” in Visual Studio? While attempting to reproduce this we see success most of the time when that setting is not enabled. However, we’ve been able to reproduce this issue on three different computers consistently when the setting is enabled.

We’re happy to jump on a call to show you what we’re seeing if that would be helpful.

Cheers!

4

Hi @nickn,

Yes, the native corruption detection setting was enabled through the diagnostic tools settings window. If the issue doesn’t happen 100% of the time, perhaps I’ve just been unlucky in trying to reproduce it? Would you be able to send a screen recording of you reproducing the issue so that I can confirm I’m understanding the reproduction steps correctly?

Thanks!

5

Hey @jon.lieblich,

I’ll work on putting together a screen recording for you. It might end up being a large file and since I have to copy/paste meeting links, passwords and a JWT it might be good to upload this somewhere private. Is there an email I can reach you at to send you a link?

Also, I thought of one other possible difference between our scenarios. I’ve been running the x86 version of the sample app. Are you also running the x86 version or are you running the x64 version?

Thanks!

6

Hi @nickn,

Thanks, a recording will be very helpful in moving things along! You should be able to send it privately through a ticket on our developer support site, but let me know if you’re running into any issues with that. Be sure to mention this topic so that it gets assigned to me. :slightly_smiling_face:

I have also been using the x86 variant, so no differences there. But no worries, we still have a couple of steps we can take to dig into why we’re seeing different behavior!

Thanks!

7

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.