Need help diagnosing crash with custom GUI

My organization has developed a Zoom application using Windows C++ SDK which can run in either classic mode or custom GUI mode, on Win 10 Pro 1803. The production code is based on SDK 4.6.21666.0427 (from 04/27/20) and works fine. Because of the impending 9-month release window, we are updating to use the latest SDK v5.7.6.1072. This required pretty minimal changes: using VC2019 instead of VC2017, and updating the PinVideo API. The classic mode works fine, but when running in custom GUI mode our app is now crashing inside sdk.dll. The crash is happening when calling ICustomizedVideoContainer::Hide(), access violation at address 0. It’s reproducible when switching from a populated gallery view to a new unpopulated one. We create a video container and populate it with 4 normal elements, subcribe one of them, then unsubscribe, delete all elements, create 9 new normal elements in same container, all unsubscribed, and then hide the video container. This same logic worked using the older SDK. I have a minidump for the crash, if you have the sdk.pdb you should be able to see which line of code is failing.

Link to zip containing exe, pdb, and dmp

Thanks for help!

No response? I’m stumped on this. No matter what I try the app is unstable and will crash somewhere in the SDK, but only when running in custom GUI mode. The classic mode passed our QA tests, so this would seem to rule out a build or deployment issue. I have some other questions I’ll post separately.

Thanks,

Bill Gardner

Hey @ministudio,

Thanks for using the dev forum!

Can you reproduce the crash once more and then send me your SDK log files and DUMP file in an email to developersupport@zoom.us? Please mention my name and a link to this post in your email.

Thanks!
Michael

Hi Michael,

Thanks for the reply. I’m assuming you mean the logs in C:\Users<user>\AppData\Roaming\Zoom SDK\logs. Strangely, I’m not getting any zoomcrash reports for these crashes, but I have set up the machine to produce minidumps and those are getting produced. I will reproduce and send you what I have.

Thanks,

Bill Gardner

I enabled logs and crash dumps and sent to you via email.

Hey I am having the same problem…

Were you able to fix it???

I got the same exact error when I tried to read from the UsersList in the CustomVideoMgr function resubscribeNormalUser(ntype)

It would only occur when 2 users left at the same time

I think I’ve just found a workaround. I rewrote my app logic so it never deletes any videoElements (until app closing). It creates a bunch of video elements when the meeting starts and from there on just reuses them as needed, by show/hide, resize, and subscribe/unsubscribe. So far this seems to work. The older logic deleted and recreated elements whenever the gallery size changed, which worked fine with the older SDK. I’ve been pulling my hair out for several weeks on this.

Ok ill give it a try and let you know

my discord is WolfEY#9345 if I could ask you a few questions that would be great

It seems my rewrite has only made the app less likely to crash. It’s now crashing (sometimes) when a user leaves and we unsubscribe the user’s video. It’s crashing in the normalElement->Unsubscribe() method.

Hey @Wolf_Isaac @ministudio,

We have identified the issue and have released a fix for it in the latest version of the SDK. Can you update and let me know if this resolved the crash for you?

Thanks!
Michael

No, I am still able to crash the base demo custom ui with no changes made.

  1. I downloaded v5.7.6.1078 of the windows zoom sdk
  2. I joined a meeting, and opened gallery view video mode
  3. had two people with video on leave on the same page at the same time
  4. Crash/Freeze until crash followed shortly

I think this is a much deeper problem than you think, as an asynchronous leave event is triggered during the synchronous handling of the initial user leaving. The UserInfo pointer for the second user is deleted asyncrhonously while the first user’s leaving is being synchronously processed, causing heap corruption when the second user who left is refrenced syncrounously and is not handled properly from the start.