[Bug] UWP Crash: ComCallHelpers.Call (__ComObject, RuntimeTypeHandle, Int32, Size)

[holecekp]

Description

AppCenter reports the following a crash of my application on UWP:

ComCallHelpers.Call (__ComObject, RuntimeTypeHandle, Int32, Size) System.Exception: Unspecified error (Exception from HRESULT: 0x80004005)

• OS of the crashing device: WINDOWS 10.0.19041
• Language of the crashing device: English
• Crashed after: 3m 32s

Stack Trace:

I have a label which has FormattedString as its content. This formatted string can consists of a few parts that have different colors (however, in this case, the FormattedString had only a single Span). From the end of the stack trace: the view model updated a property that has type of FormattedString and that is data-bound to a Label. The view model then executed PropertyChanged to notify about this change. After that, LabelRenderer in Xamarin.Forms crashed the application.

Unfortunately, this will be one of many Xamarin.Forms bugs on UWP that either happen randomly, or are connected only to some computer configurations. I do excessive testing and I have never encountered this crash on my computer. Providing a repro solution will be almost impossible. Still, I think that even these bugs, which are very hard to reproduce, should not be ignored if they lead to crashes. I hope that the stack trace from AppCenter will be helpful.

Steps to Reproduce

1. Unable to reproduce locally. The crash probably occurs randomly, or only on some device configurations. I have looked to Microsoft Partner Center Health reports and 3 crashes are reported at that exact time. So I guess this has been the same user and the app crashed repeatedly.

Expected Behavior

No crashes.

Actual Behavior

Application crashes.

Basic Information

• Version with issue: 4.8.0.1364
• Last known good version: ?
• IDE: VS 2019
• Platform Target Frameworks:
  • UWP: 18362
• Nuget Packages: Xamarin.Forms (4.8.0.1364) Xamarin.Essentials (1.5.3.2) Microsoft.NETCore.UniversalWindowsPlatform (6.2.10) Microsoft.AppCenter.Crashes (3.4.1)

Workaround

No workaround

[holecekp]

Microsoft Partner Center reports 6 hits in the last 72 hours in its Health Reporrts :-(. I have not been able to reproduce this bug on computer with Visual Studio, but I have reproduced it on a laptop. I have been using the app for about 2 minutes and, suddenly, it crashed.

[hartez]

This formatted string can consists of a few parts that have different colors (however, in this case, the FormattedString had only a single Span).

@holecekp Are you able to tell us anything more specific about the values in the formatted string? If we knew more about the content (including the span and the colors), that might help us track this down.

[hartez]

The method with the crash, FindDefaultLineHeight, is very weird. The UpdateText method in the renderer is using it to measure all of the heights of the spans, but it's doing so by iterating over the spans and, for each one,

1. Converting it to a run
2. Adding it to the renderer's TextBlock
3. Measuring the TextBlock
4. Removing it from the renderer's TextBlock
5. Returning the height

After which the renderer immediately adds the run back to the TextBlock.

This seems really awkward and inefficient, unless I'm missing something. I'd need to dive deeper, but it sort of looks like RecalculateSpanPositions (which uses the list of heights gathered from this method) will size middle lines incorrectly if later spans are shorter than earlier spans.

[holecekp]

@hartez The application is a Morse code translator. The text has generally multiple lines. The content is provided by the user. It can be either a normal text, or a Morse code (characters ".", "-", "/", spaces and newlines).

The application can transmit the entered text as a Morse code using the speakers. The purpose of the formatted text is to show the current position what has already been transmitted:

• First there is a single span with the whole text. No specific color is set for it (the TextColor set for the Label is used).
• When the first Morse code is transmitted, the FormattedText is replaced by two spans. The first span contains the first code with blue color. The other span contains the rest of the string without color.
• When the second Morse code is transmitted, there is a span with the first two codes in blue and another span with the rest of the text. This repeats. until the end of the text is reached.
• Finally, there is again only one span without color as at the beginning.

The last possible situation is when the user did not enter any text yet (or when it was cleared) - a FormattedText without any spans is set.

I have looked at the stack trace and the crash happened in a function that cannot be called when the transmission is on. So when it crashed, there must have been only a single span with the whole text in the FormattedString, or a FormattedString without any spans.

Update:

• Besides normal text, the label can also contain Unicode characters "\u00b7" and "\u2212" (for dot and dash).
• I have tried to put the OnPropertyChanged call into try..catch block so that I could log the exception and try to continue normally. This however does not work. It seems that the app crashes completely.
• I am using Micosoft AppCenter for crash logging. This log is however seldom caught and reported by it correctly. Health reports in the Microsoft Partner Center reports this crash always but without any details (there is usually only "Unknown" instead of the error message and stack trace).
• Short time before the crash I could often notice a short lag (like a fraction of second of hour-glass cursor). The next action after the lag crashed the application.

[jsuarezruiz]

I have tried to reproduce the issue notifying the change of TextColor etc. every short time. But I have not managed to reproduce the issue :( However, in FindDefaultLineHeight we basically do what E.Z has already commented, we add a line, Measure it to obtain the size, eliminated the line and return the height. Although I have not managed to reproduce, I think we can accept the issue and find a more efficient way to get the line size.

Hay do you think @hartez?

[holecekp]

I also suggest using the release mode and run the app in x64 mode when trying to reproduce it. My experience is that these two settings makes various bugs on UWP much more likely to appear in general.

[holecekp]

By the way, the bug is also in 5.0.0 pre 3. I have reproduced the issue also in that version accidentally while I was trying to reproduce another issue.

The application was in the foreground but I was not using the computer for about 3 minutes (it seems that this period of inactivity increases the chance for reproducing this issue). Then I quickly clicked several times on a button that updates an Editor text and an Label with FormattedText (single Span without color settings). The application crashed.