Description
When I try to auth into the C# SDK demo it returns SDKERR_VIDEO_NOTREADY
Which Desktop Client SDK version?
zoom-c-sharp-wrapper-5.5.12511.0422
To Reproduce(If applicable)
Steps to reproduce the behavior:
Device (please complete the following information):
Hey @Takabrycheri,
Thanks for using the dev forum!
Using the same JWT, are you seeing this error in the C++ demo as well?
Thanks!
Michael
Hi @Michael_Condon,
honestly i tried but i failed because i had other errors with visual studio and then i didn’t try anymore.
I can’t even compile it to run it…
Also in the C++ template many files are in different folders and therefore many files cannot find them, it took me about ten minutes to change all the includes
Hi all,
I recognized the same problem, but in fact it is simply error code 11 which usually means “Video-Not-Ready”, but that of course makes no sense when authorizing the SDK.
The call to authService.SDKAuth(new AuthContext { jwt_token = token })); probably returns another kind of error code.
In any case it is numerical 11. Which means… what?
Can anybody from Zoom clarify on this?
Thanks
Ah, and it does not always happen. More often on slow machines as it seems… So maybe a race condition? Maybe related to garbage collection in c#?
And it does NOT only happen in the demo app. Also in custom app using the sdk.
Hey @roland.oldenburg,
Since Zoom does not actively maintain the C# wrapper, developer support is very limited there. If this can be reproduced in C++ we will be able to assist you.
Thanks!
Michael
I also have this problem with the C# wrapper sometimes. I understand your policy about limited support for it.
Then please advice what error code 11 is, so I can debug it myself. According to documentation (https://marketplace.zoom.us/docs/sdk/native-sdks/windows/resource/error-codes#12-authentication-error) valid return codes for authentication are only 0-7 but the SDK DLLs return 11. There is no documentation about this behavior. This 11 is returned by native SDK not by wrapper.
Hey @andrez,
That error code usually means that the video module of the SDK has not been initialized properly. This can be caused by improper linking/importing of the SDK DLL’s.
Thanks!
Michael
Actually it is a misunderstanding of the original thread opener that error code 11 in context of authentication is related to the video module.
But I found the meaning of error code 11 in context of authentication. The recent C++ SDK updated the AuthResult enumeration.
Meaning is:
AUTHRET_JWTTOKENWRONG, ///<The jwt token to authenticate is wrong.
Is there any way the community can contribute bug fixes to the C# wrapper?
We can assume that this behavior is a bug in the C# wrapper.
Hey @andrez,
Ah I see, that makes sense 
The AUTHRET_JWTTOKENWRONG is usually not a bug with the SDK or wrapper. JWT’s are really tricky to get right. Usually, there is a mistake in the payload used to generate the JWT.
We are in the process of making the C# more community-driven for the future, but at this time it can only be modified locally.
Thanks!
Michael
Hi there @Michael_Condon, @andrez,
I just did some further testing on the affected machine.
And I have proof now, that this is caused by the c# SDK wrapper!
I started my app on the affected machine and made it dump the “problematic” token. I then copied the string and started the c+±SDK-Demo-App and pasted it there. SDK auth worked perfectly fine.
So: The EXACT SAME TOKEN works in the c+±demo-app but not using the c#-sdk-wrapper.
Oh and I used the very same executable and deps (even copied the whole directory) that are working fine on my machine. I even tried out the VERY SAME token on my machine using the same app/executable. Worked.
So my guess is: There is something harmful happening to the token string when passed into native/c++ part. And it must be something like a race condition or so as it does not happen on every machine. Andre even wrote to me about cases where he could stop it “breaking” when using a debugger. So maybe an early firing garbage collection? Lost references to the string and therefore “freed” to early? Maybe an encoding thing? (System language dependent…?)
P.S. As you guys are using PtrToStringChars maybe it is something like this: string - pin_ptr & PtrToStringChars vs. StringToHGlobalAnsi: Why does PtrToStringChars var loose its value? - Stack Overflow
Or maybe there is a problem when converting from UTF to ANSI…? This here indicates that StringToHGlobalAnsi would be the better choice: Convert from System String to Char - C# | Microsoft Docs
Hi there,
to be honest I don’t know what changed, maybe I’ve failed creating JWT token without notice it but now seems working fine, it also join meeting without problems.
Maybe I try it for a few days on different machines before confirming that it actually works, considering what @roland.oldenburg said.
Thanks anyway for the help, I will keep you updated 
Hey @roland.oldenburg,
Are you waiting for the initialization to finish before calling SDKAuth? Can you provide your code?
Thanks!
Michael
That may be it!!! I will check for that…
Ok. Checked it. Does not seem to be it.
Cannot provide the Code, sorry.
Still: I am a little confused. How am I supposed to wait for “initialization to finish”?
I mean, I am calling synchronously CZoomSDKeDotNetWrap.Instance.Initialize(initParam))
and I am checking, that the result is SDKError.SDKERR_SUCCESS
All that is done in UI Thread.
Is there anything else I am supposed to do before calling CZoomSDKeDotNetWrap.Instance.GetAuthServiceWrap().SDKAuth(..)?
Hey @roland.oldenburg,
If you are checking the return value of initialize, then synchronously calling sdkAuth you should be ok. Have you provided a valid web domain?
Thanks!
Michael
Of course.
h t t p s : // zoom . us
Really, literally, as said: It is the same code with the same JWT, behaving different in the c# code on two different machines. One fails with Auth 11. The other is successful.
And the JWT itself is fine as the c++ sdk demo accepts it and successfully authenticates SDK on the “failing” machine. So JWT token works on both machines. But one is failing with it when using c# wrapper.
Ah. And thanks as well.
Hey @roland.oldenburg,
Can you set the demo app to Release and x86, in the actual wrapper solution clean and build, then clean and build the demo app?
Thanks!
Michael