Bug report: CloudXR SDK inside of Unity

Since the first release of CloudXR our team has been working with a setup comprised of Unity + CloudXR. To be more exact, we built a Unity wrapper around the CloudXR SDK and where able to develop our CloudXR clients directly in Unity. Technically speaking the wrapper was composed of 2 components: one for Android and one for Windows.

Once the Android wrapper was up and running, we haven’t faced any major issues with it.
Unfortunately the Windows wrapper is a completely different story. With CloudXR 1.2 the wrapper worked perfectly and we were able to set up a sophisticated testing environment inside of Unity on Windows. In CloudXR 2.0 the wrapper was broken and it doesn’t seem that CloudXR 2.1 will solve this issue.

A more detailed explanation of the issue:
Before I describe this issue, please bear in mind that all of this is currently working on Android and this issue is independent of the Unity version. We have tested it on multiple Unity releases and the issue is exactly the same.

The core of the problem is that as soon we call cxrConnect, the engine/windowsBuild simply crashes. A call to cxrCreateReceiver creates a valid handle and once we try to connect using this handle, the system crashes. Looking at Unity’s logs, it seems that the crash happens due to a “null pointer dereference” in the SDK.

We have not been able to work around this issue and rewriting our testing setup in C++ is not an option. It is perplexing that is used to work perfectly fine in CloudXr 1.1 and 1.2, but not in 2.0 and 2.1. We consider this feature critical for our project.

We are ready to offer more information if needed!

1 Like


Thanks for the report. Could you please provide the server/client logs? Section “5.3 Log Files” of the SDK overview guide includes their locations.



Here are the logs.
cxr-logs.zip (3.2 KB)

There is an apparent hour difference between the client and the server, but don’t be bothered by that.

By the way: in your log file, it says that the client is trying to delete the log file into which the current logging info is written. This also looks like a bug, or?


just tested our Unity wrapper with the new CloudXR 2.1 release and we still get the same error. The log files look more or less the same:

CloudXR Client Log 2021-05-06 12.34.27
NVIDIA CloudXR v2.1 (CL# 29897464), built on Apr 28 2021 00:33:33.

[12:34:27.738] Cleaning up older files.
[12:34:27.739] Adapter 0: Description='NVIDIA GeForce RTX 2080 Super with Max-Q Design’
[12:34:27.792] Direct3D setup done.
[12:34:28.144] Using cuvid yuv2rgb path
[12:34:28.274] Using cuvid yuv2rgb path

As a total a-side, please post on the forums if you decide to make that wrapper public. I realize it’s a neat piece of code to keep inhouse, and I wouldn’t blame you, but would love to have access to something like that if you ever do decide to make it open source or available thru unity market place. Super cool.


Hi DtEdge,

We have the same issue - made a dll wrapper for Windows, it looked like it would work but crashed in cxrConnect(), a few calls deep. Looks like a null pointer dereference, and we got the same log output. I thought it might be related to the D3DDevice (which was difficult to get a handle to in the dll, but not impossible) and exclusive mode, but I couldn’t get any more info. We started building it on v2.0, so never had a 1.2 version working.

However, our Android wrapper didn’t work either, it looked like it couldn’t negotiate a connection (although it didn’t crash). Did you work through that problem?

Hey David,

We wrote our Android wrapper some time ago and I remember there where some problems similar to what you describe, but I don’t remember how we fixed it. But I still have an advice for you: the CloudXR SDK is full of bugs, undocumented features and to be honest it does not follow best practices.
If you’re passing a pointer to their SDK, do not assume they’re making a copy of your data. It seems they’re actually just storing the pointer and using it at some later point. Therefore, make sure the data you pass to their SDK will exist for the whole duration of the session.
Another tip I can give you is to basically replicate in Unity the exact code they have in their samples, because it doesn’t seem like they’re doing any testing outside those samples. (This is implicitly related to the pointer stuff)

Good luck with the Unity wrapper. I’m glad we’re not the only ones doing it. It would be interesting to compare our solutions at some later point.

Thanks for the tips, for now we have abandoned our plugin since we couldn’t get it to work on any platform. It is a shame though, since we are Unity developers and would be able to make a much more feature-rich, cross-platform viewer if we could do it within Unity.

Perhaps I will give it another blast when a new CloudXR version drops… I suspect our solutions were similar but yes it would be fun to compare if we can get it sorted out with NDAs. :)