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 v188.8.131.522. 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 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 firstname.lastname@example.org? Please mention my name and a link to this post in your email.
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.
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?
No, I am still able to crash the base demo custom ui with no changes made.
- I downloaded v184.108.40.2068 of the windows zoom sdk
- I joined a meeting, and opened gallery view video mode
- had two people with video on leave on the same page at the same time
- 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.
Also that fact that the sdk is already setup to just terminate upon such heap corruption is proof of a really deep rooted issue with its networking.
Patching a bug with just crashing the application, instead of fixing the root problem does not help much.
// line 8 of sdk_demo_v2.cpp
HeapSetInformation(NULL, HeapEnableTerminationOnCorruption, NULL, 0);
As it is right now, I am able to mitigate most of the crashing through just not using the userlist and not unsubscribing from users video. However it still will crash occasionally, and It would be nice for the Custom UI Video to be functional.
I see, let me inform the team so that we can get this fixed.
Hi @Wolf_Isaac , just want to point out that v220.127.116.119 was released yesterday, can you try to crash that? Thanks, Bill
I rebuilt my app with v18.104.22.1689 and was able to crash it when a user leaves, the crash is happening in unsubscribe. SDK is creating a video log but no crashdump.
Exception thrown at 0x00007FFAA9A9AE14 (nydus.dll) in sdk_demo_v2.exe: 0xC0000005: Access violation reading location 0xFFFFFFFFFFFFFFFF
at line 364 of custom ui video mgr in function resubscribenormaluser
Running the base demo custom ui with no modifications @ministudio @Michael_Condon
I just built the sdk_demo_v2 from SDK v22.214.171.1249, the only modification is that I hardcoded the creds using appKey and appSecret, rather than using JWT. I was able to crash it first time by 1) start a meeting on another machine, 2) join meeting using sdk_demo_v2, 3) join on two additional machines, and 4) leaving those two machines as same time. I have crash dump, but this should be easily reproduced.
This looks to be a demo app issue and not an issue with the SDK. This will be addressed in a future version of the SDK.