Xamarin.Android DateTime related crashes on Samsung devices

Question

We are experiencing DateTime parsing/instantiating related app crashes on Android in a Xamarin based cross platform app. The crashes only occur on Samung devices, mainly S8, S8+ and Note8 with Android 8 and 9. Unfortunately the stacktraces in the crash reports only consist of a couple of lines. Sadly it is not possible to contact the user to get more information because we do not have any information on who it is.

There are different manifestations of the issue, all somewhat connected:

The DateTime constructor is called with invalid parameters

System.ArgumentOutOfRangeException: Year, Month, and Day parameters describe an un-representable DateTime.
  Module "System.DateTime", line 0, in DateToTicks
    DateToTicks(System.Int32 year, System.Int32 month, System.Int32 day)
  Module "System.DateTime.", line 0, in ctor
    ctor(System.Int32 year, System.Int32 month, System.Int32 day, System.Int32 hour, System.Int32 minute, System.Int32 second)
  Module "System.Threading._ThreadPoolWaitCallback", line 0, in PerformWaitCallback
    PerformWaitCallback()

NullReferenceException in the DateTime constructor

System.NullReferenceException: Object reference not set to an instance of an object
  Module "System.DateTime.", line 0, in ctor
    ctor(System.Int32 year, System.Int32 month, System.Int32 day, System.Int32 hour, System.Int32 minute, System.Int32 second)
  Module "System.Threading._ThreadPoolWaitCallback", line 0, in PerformWaitCallback
    PerformWaitCallback()

However, there are also some related crashes that point towards the JSON library

NullReferenceException in Json DateTimeParser ParseZone

System.NullReferenceException: Object reference not set to an instance of an object
  Module "Newtonsoft.Json.Utilities.DateTimeParser", line 0, in ParseZone
    ParseZone(System.Int32 start)
  Module "Newtonsoft.Json.Utilities.DateTimeParser", line 0, in ParseTimeAndZoneAndWhitespace
    ParseTimeAndZoneAndWhitespace(System.Int32 start)
  Module "System.Threading._ThreadPoolWaitCallback", line 0, in PerformWaitCallback
    PerformWaitCallback()

IndexOutOfRangeException in Json DateTimeParser Parse2Digit

System.IndexOutOfRangeException: Index was outside the bounds of the array.
  Module "Newtonsoft.Json.Utilities.DateTimeParser", line 0, in Parse2Digit
    Parse2Digit(System.Int32 start, System.Int32& num)
  Module "System.Threading._ThreadPoolWaitCallback", line 0, in PerformWaitCallback
    PerformWaitCallback()

NullReferenceException in Json DateTimeParser ParseChar

System.NullReferenceException: Object reference not set to an instance of an object
  Module "Newtonsoft.Json.Utilities.DateTimeParser", line 0, in ParseChar
    ParseChar(System.Int32 start, System.Char ch)
  Module "System.Threading._ThreadPoolWaitCallback", line 0, in PerformWaitCallback
    PerformWaitCallback()

These are only some of the crash reports, there are a couple more but all of them go into the same direction.

what I have tried so far:

• Investigated our code and open source library code that could be causing the issue
• Faked server responses to return countless varieties of valid/invalid date values
• Wrote a test App that parses countless varieties of valid/invalid date values

what I have found out so far:

• I cannot reproduce the issue at all
• As mentioned above it only appears on Samsung *8 devices
  • It does not occur on other Android devices
  • It also does not occur in the iOS or Windows app
• It is unlikely to be an issue in our own code as we do not use these constructors (and seldomly handle datetime values manually alltogether)

Has anyone ran into any similar issue or have an idea into which direction I can keep looking? I am completely clueless and would appreciate any sort of hint.

Answer 1

After quite some investigation it turns out that the issue is related to the random NullReferenceExceptions accuring within Xamarin apps on Samsung devices when deploying a 32 bit apk to a 64 bit device. Due to another issue in the past we had to disable the 64 bit builds, after resolving that issue and deploying a 64 bit version again we have not received a similar crash report yet.