Crashes on Unity 2022.3.10f1 on Android

[AldeRoberge]

Hello! I've been trying to fix a bug :

A scripted object (script unknown or not yet loaded) has a different serialization layout when loading. (Read 52 bytes but expected 64 bytes) Did you #ifdef UNITY_EDITOR a section of your serialized properties in any of your scripts?

And I found that Runtime-Monitoring might be the culprit. (Deleting it from the project resolves the issue)

Happens on :

• Logs error (see above) on Windows
• Logs error and crashes on Android (app closes)

Setup :

• Unity 2022.3.10f1
• Android, IL2CPP

Here's the full log :

A scripted object (script unknown or not yet loaded) has a different serialization layout when loading. (Read 52 bytes but expected 64 bytes) Did you #ifdef UNITY_EDITOR a section of your serialized properties in any of your scripts? UnityEngine.StackTraceUtility:ExtractStackTrace () (at C:/build/output/unity/unity/Runtime/Export/Scripting/StackTrace.cs:37) UnityEngine.ResourcesAPI:LoadAll (string,System.Type) (at C:/build/output/unity/unity/Runtime/Export/Resources/Resources.bindings.cs:72) UnityEngine.Resources:LoadAll (string,System.Type) (at C:/build/output/unity/unity/Runtime/Export/Resources/Resources.bindings.cs:143) UnityEngine.Resources:LoadAll<Baracuda.Monitoring.Systems.MonitoringSettings> (string) (at C:/build/output/unity/unity/Runtime/Export/Resources/Resources.bindings.cs:155) Baracuda.Monitoring.Systems.MonitoringSettings:get_Singleton () (at ./Packages/com.baracuda.runtime-monitoring/Runtime/Scripts/Core/Systems/MonitoringSettings.cs:510) Baracuda.Monitoring.Monitor:Construct () (at ./Packages/com.baracuda.runtime-monitoring/Runtime/Scripts/Monitor.cs:105) Baracuda.Monitoring.Monitor:.cctor () (at ./Packages/com.baracuda.runtime-monitoring/Runtime/Scripts/Monitor.cs:93)

[JohnBaracuda]

Hi Alexander, I encountered a similar issue before, though it wasn't directly related to the monitoring tool. The tool appears prominently in the stack trace because it's the first to invoke a Resources.Load call. This call triggers the deserialization of all resource objects, and it seems that one or more of these objects has a mismatch in its serialized fields. This mismatch, possibly due to a #ifdef directive, a missing script, or another issue, is likely causing the crash. I'd recommend checking the scriptable objects in your "Resources" folder for any discrepancies. Additionally, try disabling runtime monitoring in a build to see if the issue persists. You can disable it via Tools -> RuntimeMonitoring -> Settings.I hope this helps. Unfortunately, due to time constraints, I'm not actively maintaining the tool at the moment, which means that I haven't really tested it in newer versions of Unity and can only offer limited assistance.

[AldeRoberge]

Hello John,

Thanks for the quick answer. I will try to launch Resources.LoadAll from a dummy script to see if it behaves the same.

I will update this comment when tests are completed.

Edit : Here's the result :

public class ResourcesLoadAll : MonoBehaviour { void Start() { var dummyCode = Resources.LoadAll<TextAsset>(string.Empty).FirstOrDefault(); Debug.Log($"Resources.LoadAll<TextAsset>(null) returned {dummyCode}"); } }

Output :

Autoconnected Player "Autoconnected Player" A scripted object (script unknown or not yet loaded) has a different serialization layout when loading. (Read 52 bytes but expected 64 bytes) Did you #ifdef UNITY_EDITOR a section of your serialized properties in any of your scripts?

So your assumptions were absolutely right, when you said :

The tool appears prominently in the stack trace because it's the first to invoke a Resources.Load call. This call triggers the deserialization of all resource objects, and it seems that one or more of these objects has a mismatch in its serialized fields.

It seems like my debugging journey does not end here. Thank you for this awesome tool, and sorry for pointing towards it as the culprit.

If anyone has this problem in the future, here's a list of threads mentionning the issue :
https://forum.unity.com/threads/did-you-ifdef-unity_editor-a-section-of-your-serialized-properties.122639/
https://forum.unity.com/threads/did-you-ifdef-unity_editor-a-section-of-your-serialized-properties-in-any-of-your-scripts.298682/
https://discussions.unity.com/t/a-script-behaviour-has-a-different-serialization-layout/179172/8

I will update if I ever find what the problem was, since the above threads are from many years ago and provide little to no clue to what the issue is.

[AldeRoberge]

After many hours of debugging, I finally found the problem. It has nothing to do with Barracuda Runtime Monitoring, but here's the problem if anyone ever finds himself in this situation.

Error :

csharp "A scripted object (script unknown or not yet loaded) has a different serialization layout when loading. (Read 52 bytes but expected 64 bytes) Did you #ifdef UNITY_EDITOR a section of your serialized properties in any of your scripts?"

Setup :
IL2CPP, Unity 2022.3.10f1 (Platforms : Windows and Android)

After manually using the "binary search algoritm",
I traced back the error to HurricaneVR after 3 full days of debugging, and I'm baffled no one else is having this problem.

I deleted all 3 resources folder and found the culprit : It IS because of the Assets/Plugins/HurricaneVR/Framework/Resources
Then I kept deleting and building, until I found that It IS because of the HVREditorPreferences file in the Resources folder.

Problem : HVREditorPreferences.asset is in the Resources folder (INCLUDED IN BUILD) (Assets/Plugins/HurricaneVR/Framework/Resources) but the file is in (Assets/Plugins/HurricaneVR/Framework/Editor/HVREditorPreferences.cs) (NOT INCLUDED IN BUILD).

This closes this issue, and hoping no one ever has to deal with this problem ever again. I'll file a report with Unity so that they provide more information on the debug log. Makes me wish I was using an open source engine, and with the turmoil of the current days, I might do that for my next project.