xamarin-macios
xamarin-macios copied to clipboard
xamarin
Random crashes with "Could not find an existing managed instance for this object, nor was it possible to create a new managed instance"
Apple platform
iOS
Framework version
net9.0-*
Affected platform version
VS 2022 17.12
Description
We have received feedback from users experiencing random crashes in our app, which have led to some instances of data loss. The app, used for creating and managing health records, is encountering issues with "marshaling Objective-C objects" like MauiTextField and ContentView.
ObjCRuntime.RuntimeException: Failed to marshal the Objective-C object 0x13d566800 (type: Microsoft_Maui_Platform_MauiTextField). Could not find an existing managed instance for this object, nor was it possible to create a new managed instance (because the type 'Microsoft.Maui.Platform.MauiTextField' does not have a constructor that takes one NativeHandle argument).
at ObjCRuntime.Runtime.MissingCtor(IntPtr , IntPtr , Type , MissingCtorResolution , IntPtr , RuntimeMethodHandle )
at ObjCRuntime.Runtime.ConstructNSObject[NSObject](IntPtr , Type , MissingCtorResolution , IntPtr , RuntimeMethodHandle )
at ObjCRuntime.Runtime.ConstructNSObject[NSObject](IntPtr , Type , MissingCtorResolution )
at ObjCRuntime.Runtime.ConstructNSObject(IntPtr , IntPtr , MissingCtorResolution )
at ObjCRuntime.Runtime.GetNSObject(IntPtr , MissingCtorResolution , Boolean )
at ObjCRuntime.Runtime.GetNSObject(IntPtr )
at ObjCRuntime.Runtime.InvokeConformsToProtocol(IntPtr , IntPtr )
at ObjCRuntime.Runtime.invoke_conforms_to_protocol(IntPtr obj, IntPtr protocol, IntPtr* exception_gchandle)
Exception_EndOfInnerExceptionStack
Error: System.Exception: CurrentDomainOnUnhandledException
---> ObjCRuntime.RuntimeException: Failed to marshal the Objective-C object 0x156f97480 (type: Microsoft_Maui_Platform_ContentView). Could not find an existing managed instance for this object, nor was it possible to create a new managed instance (because the type 'Microsoft.Maui.Platform.ContentView' does not have a constructor that takes one NativeHandle argument).
at ObjCRuntime.Runtime.MissingCtor(IntPtr , IntPtr , Type , MissingCtorResolution , IntPtr , RuntimeMethodHandle )
at ObjCRuntime.Runtime.ConstructNSObject[UIResponder](IntPtr , Type , MissingCtorResolution , IntPtr , RuntimeMethodHandle )
at ObjCRuntime.Runtime.GetNSObject[UIResponder](IntPtr , IntPtr , RuntimeMethodHandle , Boolean )
at ObjCRuntime.Runtime.GetNSObject[UIResponder](IntPtr , IntPtr , RuntimeMethodHandle )
at ObjCRuntime.Runtime.GetNSObject[UIResponder](IntPtr )
at UIKit.UIResponder.get_NextResponder()
at Microsoft.Maui.Platform.ViewExtensions.FindResponder[UIScrollView](UIView view)
at Microsoft.Maui.Platform.KeyboardAutoManagerScroll.AnimateHidingKeyboard()
at ObjCRuntime.Trampolines.SDAction.Invoke(IntPtr block)
at UIKit.UIView.AnimateNotify(Double , Double , UIViewAnimationOptions , Action , UICompletionHandler )
at UIKit.UIView.Animate(Double , Double , UIViewAnimationOptions , Action , Action )
at Microsoft.Maui.Platform.KeyboardAutoManagerScroll.WillHideKeyboard(NSNotification notification)
at Foundation.InternalNSNotificationHandler.Post(NSNotification s)
at Foundation.InternalNSNotificationHandler.__Registrar_Callbacks__.callback_1514_Foundation_InternalNSNotificationHandler_Post(IntPtr pobj, IntPtr sel, IntPtr p0, IntPtr* exception_gchandle)
Exception_EndOfInnerExceptionStack
Steps to Reproduce
Unfortunately, we are unable to provide specific steps to reproduce the issue, as the crashes appear to occur randomly. The issue seems to be related to "marshaling Objective-C objects" like MauiTextField and ContentView, but there is no consistent pattern or specific actions that reliably trigger the error. We are continuing to monitor the situation and gather more information in hopes of identifying any potential triggers. Based on the nature of the issue, we believe it may be related to xamarin-macios. We don't think this happens on Windows, but as https://github.com/dotnet/maui/issues/21485 exists, we are not that sure about this.
Did you find any workaround?
No 😔
Relevant logs
No response
These issues can be rather difficult to track down, and it's imperative to be able to reproduce them, otherwise we'll just be guessing.
However, there's one thing you can do to try to trigger them: run the GC aggressively.
Something like this should do it:
static void Main (string[] arguments)
{
var thread = new Thread (() => {
while (true) {
Thread.Sleep (5000);
GC.Collect ();
}
});
thread.IsBackground = true;
thread.Start ();
// ...
UIApplication.Main(args, null, typeof(AppDelegate));
}
This is obviously not meant to be shipped, but running with this during development will often make the problems you're experiencing easier to reproduce.
Can you try this and see if you have any luck?
Thanks again for your suggestion to aggressively trigger the GC to help reproduce the crashes. Interestingly, we had similar GC.Collect() code in place previously, as part of our attempts to address memory-related issues. This was a temporary, desperate measure to mitigate memory related crashes we were encountering, but it wasn’t a long-term solution. (We also had some temporary teardown code in place, similar to the approach used in the so called "MemoryToolkit". However, that code has since been removed as well.)
Since your suggestion, we've removed the GC.Collect() code entirely in our most recent release (as of last week). Unfortunately, we're still seeing random crashes, but the key difference is that we no longer have any log output. This leads us to suspect that iOS might be terminating the app due to memory pressure, rather than an issue directly related to GC.
We’re continuing to monitor the situation and try to gather more data. Given that the crashes seem random and aren’t easily reproducible.
Just to vent a little... The ticket is closed now, and of course, we can’t reopen it after 7 days. We've spent so much time profiling and troubleshooting this issue, dealing with memory management problems that have been around since Xamarin.Forms. It feels like we've been fighting memory leaks for ages, and now we're just left hanging without any way to follow up. Honestly, it's frustrating not being able to continue the conversation or get the support we need.
Just to vent a little... The ticket is closed now, and of course, we can’t reopen it after 7 days. We've spent so much time profiling and troubleshooting this issue, dealing with memory management problems that have been around since Xamarin.Forms. It feels like we've been fighting memory leaks for ages, and now we're just left hanging without any way to follow up. Honestly, it's frustrating not being able to continue the conversation or get the support we need.
I'm sorry to hear about your struggles, and we're here to help.
We can always reopen issues, so feel free to open a new issue if you can't reopen an issue yourself, we're happy to do that for you.
Since your suggestion, we've removed the GC.Collect() code entirely in our most recent release (as of last week). Unfortunately, we're still seeing random crashes, but the key difference is that we no longer have any log output.
Note that the GC.Collect code shouldn't make a crash app (or fix any crashes [1]) - it's purpose is to trigger any crashes more reliably during development, which would hopefully make them easier to diagnose and fix (instead of hearing about the app crashing for your customers, and not being able to reproduce yourself).
[1]: the one exception here is that GC.Collect may keep your app's memory usage lower, thus preventing the OS from terminating the app if it uses a lot of memory. Note that if there are memory leaks, the app will likely crash sooner or later anyway, the GC.Collect will just delay it.
Thank you for taking the time to respond - I really appreciate it and feel honored, especially since I’ve read many of your responses and blogs over the years. Apologies if my earlier comment came off unconstructive; it’s just been a tough issue to tackle.
We’ve been trying to follow best practices as much as possible, like using static event handlers instead of anonymous, implementing INotifyPropertyChanged properly, and keeping object lifetimes in check with DI and so on. That said, I haven’t dived too deeply into profiling snapshots yet - it’s quite complex for me to fully grasp.
One thing I’ve been wondering: could this issue stem from how the Mono GC and native iOS GC might be interacting? For instance, is it possible that objects are being collected too early as it doesn't makes much sense to me, iOS (?) tries to instantiate a new managed instance. Or might it work if I tried using custom handlers and try to introduce such constructor myself?!
I completely understand how important it is to have a reproduction sample, and I’d genuinely love to provide one. Unfortunately, our corporate app has grown significantly in complexity, and with the ongoing pressure of the project, creating a simplified example hasn’t been feasible. That said, we even brought in freelance “specialists” to help diagnose and address these memory-related challenges, but unfortunately, they weren’t able to offer any better solutions, which has been discouraging.
Well, I don’t know... this really sucks as a bug report, to be honest. I’ve probably used enough ChatGPT energy to power a small city for a year just trying to figure out how to frame this properly. Maybe this is turning into more of a discussion than a report at this point?
I have to admit, I’m feeling a bit desperate at this point, but I really appreciate all the help and insights you’ve provided so far. I’m truly grateful for any further suggestions you might have that could help me work through this. Thanks again for your time, support, and guidance - it's really appreciated!
PS: The app's complexity stems from several factors. It includes dozens of pages with intricate logic, and an ERP-like approach that stores form definitions in the database. Each form can contain 200+ controls, adding to the challenge of managing data and rendering. Users can upload multiple photos, resulting in terabytes of data. The app also relies on third-party libraries like Syncfusion. Additionally, background threads are used for tasks like data/image uploads (to sync local "offline" data with the server) and data processing, requiring careful management of thread safety and performance.
There are a couple of strategies I tend to use when diagnosing this issues:
- The first one is to investigate the code, but with a slightly different view point than usual.
There are a couple of things you need to know first:
- For every NSObject subclass, there's a managed class and a native (Objective-C) class. For every managed instance, there's a corresponding native instance as well. For example: if you create a managed instance of the type
Microsoft.Maui.Platform.MauiTextField, there will also be a corresponding Objective-C instance of the typeMicrosoft_Maui_Platform_MauiTextField[1]. - Whenever a pointer to the native instance shows up in managed code, we need to find the corresponding managed instance.
- The exception in question happens when we can't find that managed instance (and we can't re-create it either).
Typically, this is because the GC has determined that the managed instance is no longer needed, and it's been collected.
The last important bit to know is that we will automatically keep the managed instance alive, as long as the native instance is.
Now the conundrum is: if the native instance showed up in managed code, it's still alive, which means the managed instance shouldn't have been collected... there's at least one caveat to this: if native code only has a weak reference to the native instance, we won't see this weak reference, and we'll think the native instance is no longer alive.
Now to the investigation:
Typically, people try to answer the question "why is this instance freed/collected by the GC?" - but I like to flip the question to become "why should this instance not be freed/collected by the GC?", and sometimes that yields interesting results.
Now I don't know your code base, so I can't offer any more specific advice. Also, you're using MAUI, which often complicates matters.
Often this technique doesn't give any results, but combined with the second one I usually figure something out:
- The second technique I use, is to create a reproducible test case. I know this can be really hard, but here is what I would do: the first step is to figure out exactly what the user was doing when the app crashed, then re-create those steps, and finally automate it so that the steps can be repeated automatically. Then finally leave the app running overnight and hopefully it'll have crashed by the time you get back to work the next day.
So for instance for your second stack trace:
Error: System.Exception: CurrentDomainOnUnhandledException
---> ObjCRuntime.RuntimeException: Failed to marshal the Objective-C object 0x156f97480 (type: Microsoft_Maui_Platform_ContentView). Could not find an existing managed instance for this object, nor was it possible to create a new managed instance (because the type 'Microsoft.Maui.Platform.ContentView' does not have a constructor that takes one NativeHandle argument).
at ObjCRuntime.Runtime.MissingCtor(IntPtr , IntPtr , Type , MissingCtorResolution , IntPtr , RuntimeMethodHandle )
at ObjCRuntime.Runtime.ConstructNSObject[UIResponder](IntPtr , Type , MissingCtorResolution , IntPtr , RuntimeMethodHandle )
at ObjCRuntime.Runtime.GetNSObject[UIResponder](IntPtr , IntPtr , RuntimeMethodHandle , Boolean )
at ObjCRuntime.Runtime.GetNSObject[UIResponder](IntPtr , IntPtr , RuntimeMethodHandle )
at ObjCRuntime.Runtime.GetNSObject[UIResponder](IntPtr )
at UIKit.UIResponder.get_NextResponder()
at Microsoft.Maui.Platform.ViewExtensions.FindResponder[UIScrollView](UIView view)
at Microsoft.Maui.Platform.KeyboardAutoManagerScroll.AnimateHidingKeyboard()
at ObjCRuntime.Trampolines.SDAction.Invoke(IntPtr block)
at UIKit.UIView.AnimateNotify(Double , Double , UIViewAnimationOptions , Action , UICompletionHandler )
at UIKit.UIView.Animate(Double , Double , UIViewAnimationOptions , Action , Action )
at Microsoft.Maui.Platform.KeyboardAutoManagerScroll.WillHideKeyboard(NSNotification notification)
at Foundation.InternalNSNotificationHandler.Post(NSNotification s)
at Foundation.InternalNSNotificationHandler.__Registrar_Callbacks__.callback_1514_Foundation_InternalNSNotificationHandler_Post(IntPtr pobj, IntPtr sel, IntPtr p0, IntPtr* exception_gchandle)
Exception_EndOfInnerExceptionStack
This seems to have happened when the keyboard closed ("KeyboardAutoManagerScroll.WillHideKeyboard" is one of the stack frames). I believe it's possible to open and close the keyboard in code, so I would add that code to the app on a timer (say open and close the keyboard once per second), and then just leave it running for a few hours. Running the GC on a background thread as I previously mentioned would also be a good idea (or you can try both with and without the aggressive GC).
A final note: these are crashes in the UI layer of your app. It rarely matters what the app does in the background, or in any UI not shown around the time of the crash.
[1]: sometimes the names match exactly, sometimes they don't - this is not important.
For now I am going to try this as a workaround:
internal class CustomContentViewHandler : Microsoft.Maui.Handlers.ContentViewHandler
{
protected override CustomContentViewPlatformView CreatePlatformView()
{
return new CustomContentViewPlatformView();
}
}
...
public class CustomContentViewPlatformView : ContentView
{
public CustomContentViewPlatformView() : base()
{
;
}
public CustomContentViewPlatformView(NativeHandle handle)
{
Log.Warning("GURU MEDITATION");
}
}
...
handlers.AddHandler(typeof(Microsoft.Maui.Controls.ContentView), typeof(CustomContentViewHandler));
I'll try to reproduce this anyhow and maybe put a "aggressive GC" version on Testflight for our Testers. If I come up with something new I'll open another ticket. Thanks
Same problem here. Failed to marshal the Objective-C object 0x153d89400 (type: Microsoft_Maui_Platform_MauiTextField). Could not find an existing managed instance for this object, nor was it possible to create a new managed instance (because the type 'Microsoft.Maui.Platform.MauiTextField' does not have a constructor that takes one NativeHandle argument).
Kind of same story too. Though we are still on .NET8 and are using a heavily modified version of the "MemoryToolkit" and regular GCs to prevent leaks. @formerlymisterhenson : Do you by chance use Syncfusion controls? We tracked down some of our memory issues to some of their controls and they told us to call handler.Disconnect() on it when the page is unloaded. They also told us that this happens automatically when using .NET9.
From our crash analytics the crash happens most (all?) of the time when the app is resumed. So may be unloaded gets called when going to sleep, the hander disconnects, managed objects are disposed and this leads to problems on resume. Sleep/resume is somewhat different then a normal page change, so this might be related to it.
But as for you, it is difficult to reproduce and happens only very sporadically and only in our newest release. Which means it is either related to some changes we did to our MemoryToolkit (like calling handler.disconnect for some controls) or the update from maui 8.0.92 to 8.0.100.
Sounds like we’re dealing with pretty much the same issue. And we do use Syncfusion indeed - mostly for SfComboBox and SfListView. Although I have some mixed feelings towards Syncfusion, I am not sure if they're the origin (but cannot exclude it either).
When I tested MemoryToolkit like 6 months ago it seemed very promising initially. But the DisconnectHandler thing in particular was problematic and led to crashes (still remember that line), so this was kind of a show stopper for the use of MemoryToolkit (so I removed it). If I remember correctly MemoryToolkit also collected some things too early leading to "white" pages (I stumbled over some code in MAUI repo here, that by default Shell is caching the last page as a performance optimization??)
For years we used basically the same approach as MemoryToolkit (try do clear children, nulling BindingContext, try to kill EventHandlers with reflection etc.) but I also removed that code entirely shortly after that because it never had a huge impact on the memory situation and I suspected it of degrading the stability in more recent versions of MAUI (and it was ugly 😄). As a side note: We did not wire our "teardown code" directly to Unload, but invoked it after navigating away from the page (only for pages manually pushed onto the navigation stack).
I think the whole "Could not find an existing managed instance for this object" gained momentum after that. Well looking at the timeline, for us it would have been introduced with Microsoft.Maui.Controls 8.0.6x. Thank you for sharing your insights - I hope this helps to narrow down the cause.
PS: Our testers will start with the "constructor workaround" in January, maybe with go live following soon after. If I don't forget to, I'll share the results here.
Thanks for the feedback.
SfCombox and SfListView are exactly the two controls which we identified having memory issues. I was in contact with syncfusion about our findings and their solution for .NET 8 was to call handler.disconnect in unload. For .NET 9 they told us it will not be necessary because it is called by default (which would explain why you face issues although you do not call handler.disconnect manually).
We are still using MemoryToolkit, but a heavily modified version of it, as we also faced issues with the original code. But the idea is still the same. Detect a "true" page unload and try to teardown the page by "resetting" problematic controls (a list that got smaller which each maui release as the maui team seems to have fixed most of the initial memory related issues).
SfCombobox was causing complete page leaks for us, though we have a working workaround for that (without disconnecting the handler) in our teardown code:
if (typeof(SfComboBox).IsAssignableFrom(vte.GetType())) { SfComboBox box = (SfComboBox)vte; box.ItemTemplate = null; box.ItemsSource = null; box.CustomView = null; SfListView lw = box.GetPropertyValue<SfListView>("ListView"); // this is the problematic internal control only accessible by reflection if (lw != null) { lw.ItemsSource = null; lw.ItemTemplate = null; } }
For a normal SfListView it's more complicated. For us it is not causing page leaks but massive native memory leaks (unmanaged code). Because of that we are using the handler.disconnect there as told by syncfusion. In the past we disposed the platformView instead of disconnecting the handler, which instead caused an already disposed exception sometimes. So probably the correct way would be to disconnect the handler AND dispose it's native view (like in the original MemoryToolkit)
Their might be a different way (like for SfCombobox) for SfListView. We were able to pinpoint the leaks to some internal control "VisualContainer" and SF proposed the following solution (which is a bit different from what our memory manager does currently and we did not yet test it):
listView.Handler?.DisconnectHandler(); listView.GetVisualContainer().Handler?.DisconnectHandler(); listView.Children.Clear();
I probably have to do more testing to find the best way to handle this. It may be enough to "reset" the VisualContainer instead of disconnecting the handler.
At all we are very happy with the syncfusion controls (using a bunch of them since xamarin.forms days) and they always respond and fix issues fast. But these memory related things are a bit problematic :-(
I let you know if i find a more stable solution. I will probably also give your workaround a try.
But i will be on holidays for 2 weeks, so i will probably have no news beforce second week of january.
Regards,
Bernd
The "constructor workaround" does not seem to work, as the issue was reported again by a tester. So next I'm trying to manually clean up SfComboBoxes/SfListView...
I noticed some differences after upgrading to the newest version of the syncfusion controls (no more native memory leaks, even without disconnecting handlers).
I also did some tests with .net9 and it seems that memory usage is better with .net9. I also do not need to call DisconnectHandler with .net9 as this is done by default.
Still doing my usual cleanup when unloading the page(but without manual disconnecting handlers or disposing native views).
The .net9 version is now going to the test stage. Will report after it has been stress tested....
Regarding the one with the KeyboardManager. We had this too in the past, but this code in our TearDown logic resolved this (never happend again):
try { KeyboardAutoManagerScroll.Disconnect(); } catch (Exception) { }
We've begun seeing these errors in .NET 9, for seemingly simple Entry fields on iOS
Failed to marshal the Objective-C object 0x119ea9900 (type: Microsoft_Maui_Platform_MauiTextField). Could not find an existing managed instance for this object, nor was it possible to create a new managed instance (because the type 'Microsoft.Maui.Platform.MauiTextField' does not have a constructor that takes one NativeHandle argument).
They occur for us, when WebAuthenticator window has opened, and app is put to sleep while the authenticator window is open.
Which is fairly often, when users need to move from the auth window, into Authenticator app for TOTP tokens etc.
@frederikspang You might consider to set HandlerProperties.DisconnectPolicy="Manual" on the entry field to test if that fixes the issue. However this might indicate a bug. If you have a reproducible sample project that would probably help the maui team to track it down. Setting the disconnect policy to manual for entry fields could probably also be a global workaround when done with AppendMapping for the EntryHandler. Not sure though if this can cause memory leaks.
When the problem only occurs when the app is put to sleep this might indicate that the 'magic code' now doing the disconnect in .net9 is called to soon. Not every page.Unload is a real one. I had to spend some days to figure out the correct way to call my teardown code in .net8 and the only reliable solution for me was to override the destroy method of the page (which is only available when using prism). Not sure how it is wired in .NET9. However the workaround in the next post is working for me.
@formerlymisterhenson This is interesting. I just checked my event logs from the test environment. No crashes, but lots of events triggered by your workaround (which i implemented to see if it can notify me about the issue). I am using this code, which seems to work for me as workaround (together with calling KeyboardAutoManagerScroll.Disconnect() on page.Unload or page.Destroy (only available with prism)):
#if IOS
builder.ConfigureMauiHandlers(handlers =>
{
handlers.AddHandler(typeof(Microsoft.Maui.Controls.Entry), typeof(CustomEntryHandler)); // Crash catcher für missing native element
});
#endif
...
#if IOS
internal class CustomEntryHandler : Microsoft.Maui.Handlers.EntryHandler
{
protected override CustomMauiTextFieldPlatformView CreatePlatformView()
{
return new CustomMauiTextFieldPlatformView
{
BorderStyle = UITextBorderStyle.RoundedRect,
ClipsToBounds = true
};
}
}
}
public class CustomMauiTextFieldPlatformView : Microsoft.Maui.Platform.MauiTextField
{
public CustomMauiTextFieldPlatformView() : base()
{
}
public CustomMauiTextFieldPlatformView(ObjCRuntime.NativeHandle handle)
{
Logger.Instance.Error("### PREVENTING CRASH ###", new Exception("CRASH_PREVENTED_MISSING_MAUI_TEXT_FIELD"));
}
}
#endif
@frederikspang You might consider to set HandlerProperties.DisconnectPolicy="Manual" on the entry field to test if that fixes the issue. However this might indicate a bug. If you have a reproducible sample project that would probably help the maui team to track it down. Setting the disconnect policy to manual for entry fields could probably also be a global workaround when done with AppendMapping for the EntryHandler. Not sure though if this can cause memory leaks.
The default disconnect policy should be automatic on net9. But I found out that my handler's disconnect method is never called even in net9. So i'm not sure that is true.
I am getting the same error when sleep/resume the app, can you please suggest me what the solution to fix this?
Crash report: Failed to marshal the Objective-C object 0x111b03200 (type: Microsoft_Maui_Platform_MauiTextField). Could not find an existing managed instance for this object, nor was it possible to create a new managed instance (because the type 'Microsoft.Maui.Platform.MauiTextField' does not have a constructor that takes one NativeHandle argument).
For some days we're running our app with the concurrent garbage collector disabled (<EnableSGenConc>False</EnableSGenConc>). AFAIK by now the issue was not reported again
@formerlymisterhenson Good you found a workaround which is working for you. But as we now have several people reporting the issue you should probably reopen it so that the maui team can investigate.
For our app, by now, disabling the concurrent garbage collector seems to prevent the crashes. This seems to be somewhat consistent with the initial thoughts by @rolfbjarne. I'll reopen the ticket as it gained attention, although it's still hard to tell what's the underlying cause
I'm seeing this pretty frequently atm to the point its almost crashing in every other session of running our iOS app.
You have a problem with strong references. You may be using weak references everywhere.
Check again the parent of the parent of your page until you find where it is used. Make sure you keep a strong reference on everything that needs to stay.
I tried this class as the platform view in a handler. However, since the error is so random. It's hard to confirm that it solved the issue. Adding the missing constructor in MauiTextField itself will probably resolve the issue completely.
public class MyMauiTextField : MauiTextField
{
public MyMauiTextField(CGRect frame): base(frame)
{
}
protected MyMauiTextField(NativeHandle nh) : base()
{
try
{
this.Handle = nh; //.Handle is not browseable but its there
}
catch(System.Exception ex)
{
System.Diagnostics.Debug.WriteLine(ex.ToString());
}
}
public MyMauiTextField() :base()
{
}
}
I have that issue when my code uses the .Parent property. Removing all access to that property fixes the underlying random issue.
I believe inserting the constructor below in MauiTextField will resolve the problem. My fix above to change the platform view via a handler is a workaround using the hidden NSObject.Handle property
protected internal MauiTextField(NativeHandle nh) : base(nh)
{
}
We are also have such crashes. They appear on random, with no clear steps to reproduce.
SIGABRT SIGABRT: Failed to marshal the Objective-C object 0x116a48000 (type: Microsoft_Maui_Platform_MauiTextField). Could not find an existing managed instance for this object, nor was it possible to create a new managed instance (because the type 'Microsoft.Maui.Platform.MauiTextField' does not have a constructor that takes one NativeHandle argument).
Xamarin Exception Stack: ObjCRuntime.RuntimeException: Failed to marshal the Objective-C object 0x130f64500 (type: Microsoft_Maui_Platform_MauiTextField). Could not find an existing managed instance for this object, nor was it possible to create a new managed instance (because the type 'Microsoft.Maui.Platform.MauiTextField' does not have a constructor that takes one NativeHandle argument). at ObjCRuntime.Runtime.MissingCtor(IntPtr , IntPtr , Type , MissingCtorResolution , IntPtr , RuntimeMethodHandle ) at ObjCRuntime.Runtime.ConstructNSObject[NSObject](IntPtr , Type , MissingCtorResolution , IntPtr , RuntimeMethodHandle ) at ObjCRuntime.Runtime.ConstructNSObject(IntPtr , IntPtr , MissingCtorResolution ) at ObjCRuntime.Runtime.GetNSObject(IntPtr , Boolean , MissingCtorResolution , Boolean ) at ObjCRuntime.Runtime.invoke_conforms_to_protocol(IntPtr obj, IntPtr protocol, IntPtr* exception_gchandle)
Full crash report: Incident Identifier: 0b3f8ab0-4bd5-49a9-9723-d374f4d68800 CrashReporter Key: A2A78668-81A3-4BD9-ACF6-0E26C16CACFB Hardware Model: iPad14,2 Process: SFA.MAUI [8420] Path: /private/var/containers/Bundle/Application/0D6F83F3-2EB4-48ED-B7E6-65F8077D8EF3/SFA.MAUI.app/SFA.MAUI Identifier: com.cchellenic.sfa.maui Version: 13.2.1 (13.2.1) Code Type: arm64 Parent Process: [1]
Date/Time: 2025-02-07T10:20:08.999Z Launch Time: 2025-02-07T09:49:02Z OS Version: iPadOS 17.5.1 (21F90) Report Version: 104
Exception Type: SIGABRT Exception Codes: #0 at 0x1eacff42c Crashed Thread: 0
Application Specific Information: *** Terminating app due to uncaught exception 'SIGABRT', reason: 'Failed to marshal the Objective-C object 0x16771e800 (type: Microsoft_Maui_Platform_MauiTextField). Could not find an existing managed instance for this object, nor was it possible to create a new managed instance (because the type 'Microsoft.Maui.Platform.MauiTextField' does not have a constructor that takes one NativeHandle argument).'
Xamarin Exception Stack: ObjCRuntime.RuntimeException: Failed to marshal the Objective-C object 0x16771e800 (type: Microsoft_Maui_Platform_MauiTextField). Could not find an existing managed instance for this object, nor was it possible to create a new managed instance (because the type 'Microsoft.Maui.Platform.MauiTextField' does not have a constructor that takes one NativeHandle argument). at ObjCRuntime.Runtime.MissingCtor(IntPtr , IntPtr , Type , MissingCtorResolution , IntPtr , RuntimeMethodHandle ) at ObjCRuntime.Runtime.ConstructNSObject[NSObject](IntPtr , Type , MissingCtorResolution , IntPtr , RuntimeMethodHandle ) at ObjCRuntime.Runtime.ConstructNSObject(IntPtr , IntPtr , MissingCtorResolution ) at ObjCRuntime.Runtime.GetNSObject(IntPtr , Boolean , MissingCtorResolution , Boolean ) at ObjCRuntime.Runtime.invoke_conforms_to_protocol(IntPtr obj, IntPtr protocol, IntPtr* exception_gchandle)
Thread 0 Crashed: 0 libsystem_kernel.dylib 0x00000001eacff42c __pthread_kill + 8 1 libsystem_c.dylib 0x00000001a9c06ba0 abort + 176 2 SFA.MAUI 0x00000001012d06c0 0x100024000 + 19580608 3 CoreFoundation 0x00000001a1da7984 __handleUncaughtException + 656 4 libobjc.A.dylib 0x0000000199bc9e20 _objc_terminate() + 128 5 SFA.MAUI 0x000000010152452c 0x100024000 + 22021420 6 libc++abi.dylib 0x00000001fe97b068 std::__terminate(void (*)()) + 12 7 libc++abi.dylib 0x00000001fe97b00c std::terminate() + 104 8 libdispatch.dylib 0x00000001a9b4dde8 _dispatch_client_callout + 36 9 libdispatch.dylib 0x00000001a9b5186c _dispatch_block_invoke_direct + 284 10 FrontBoardServices 0x00000001ba922d58 FBSSERIALQUEUE_IS_CALLING_OUT_TO_A_BLOCK + 48 11 FrontBoardServices 0x00000001ba922cd8 -[FBSMainRunLoopSerialQueue _targetQueue_performNextIfPossible] + 236 12 FrontBoardServices 0x00000001ba922bb0 -[FBSMainRunLoopSerialQueue _performNextFromRunLoopSource] + 24 13 CoreFoundation 0x00000001a1c7b834 CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION + 24 14 CoreFoundation 0x00000001a1c7b7c8 __CFRunLoopDoSource0 + 172 15 CoreFoundation 0x00000001a1c792f8 __CFRunLoopDoSources0 + 336 16 CoreFoundation 0x00000001a1c78484 __CFRunLoopRun + 824 17 CoreFoundation 0x00000001a1c77cd8 CFRunLoopRunSpecific + 604 18 GraphicsServices 0x00000001e6b281a8 GSEventRunModal + 160 19 UIKitCore 0x00000001a42b090c -[UIApplication _run] + 884 20 UIKitCore 0x00000001a43649d0 UIApplicationMain + 336 21 IntuneMAMSwift 0x000000010373cb0c 0x1034a0000 + 2738956 22 SFA.MAUI 0x00000001012cdbf8 0x100024000 + 19569656 23 SFA.MAUI 0x000000010149a5c8 0x100024000 + 21456328 24 SFA.MAUI 0x0000000101498b9c 0x100024000 + 21449628 25 SFA.MAUI 0x000000010148dbf8 0x100024000 + 21404664 26 SFA.MAUI 0x000000010148b7c4 0x100024000 + 21395396 27 SFA.MAUI 0x000000010145a7cc 0x100024000 + 21194700 28 SFA.MAUI 0x0000000101406108 0x100024000 + 20848904 29 SFA.MAUI 0x000000010140be3c 0x100024000 + 20872764 30 SFA.MAUI 0x0000000101461074 0x100024000 + 21221492 31 SFA.MAUI 0x00000001012d8a20 0x100024000 + 19614240 32 SFA.MAUI 0x0000000101544cf8 0x100024000 + 22154488 33 ??? 0x00000001c5329e4c 0x0 + 0
Thread 1: 0 libsystem_kernel.dylib 0x00000001eacf4808 mach_msg2_trap + 8 1 libsystem_kernel.dylib 0x00000001eacf7f20 mach_msg_overwrite + 432 2 libsystem_kernel.dylib 0x00000001eacf7d60 mach_msg + 20 3 CoreFoundation 0x00000001a1c78f5c __CFRunLoopServiceMachPort + 156 4 CoreFoundation 0x00000001a1c78600 __CFRunLoopRun + 1204 5 CoreFoundation 0x00000001a1c77cd8 CFRunLoopRunSpecific + 604 6 WebCore 0x00000001b55572a0 RunWebThread(void*) + 776 7 libsystem_pthread.dylib 0x00000001fea5c06c _pthread_start + 132 8 libsystem_pthread.dylib 0x00000001fea570d8 thread_start + 4
Thread 2: 0 libsystem_kernel.dylib 0x00000001eacfa1cc __psynch_cvwait + 8 1 SFA.MAUI 0x000000010139dcb4 0x100024000 + 20421812 2 libsystem_pthread.dylib 0x00000001fea5c06c _pthread_start + 132 3 libsystem_pthread.dylib 0x00000001fea570d8 thread_start + 4
Thread 3: 0 libsystem_kernel.dylib 0x00000001eacf4784 semaphore_wait_trap + 8 1 SFA.MAUI 0x0000000101418114 0x100024000 + 20922644 2 libsystem_pthread.dylib 0x00000001fea5c06c _pthread_start + 132 3 libsystem_pthread.dylib 0x00000001fea570d8 thread_start + 4
Thread 4: 0 libsystem_kernel.dylib 0x00000001eacfa1cc __psynch_cvwait + 8 1 IntuneMAMSwift 0x000000010371a38c 0x1034a0000 + 2597772 2 libdispatch.dylib 0x00000001a9b4c13c _dispatch_call_block_and_release + 28 3 libdispatch.dylib 0x00000001a9b4ddd4 _dispatch_client_callout + 16 4 libdispatch.dylib 0x00000001a9b55400 _dispatch_lane_serial_drain + 744 5 libdispatch.dylib 0x00000001a9b55f30 _dispatch_lane_invoke + 376 6 libdispatch.dylib 0x00000001a9b60cb4 _dispatch_root_queue_drain_deferred_wlh + 284 7 libdispatch.dylib 0x00000001a9b60528 _dispatch_workloop_worker_thread + 400 8 libsystem_pthread.dylib 0x00000001fea5a934 _pthread_wqthread + 284 9 libsystem_pthread.dylib 0x00000001fea570cc start_wqthread + 4
Thread 5: 0 libsystem_kernel.dylib 0x00000001eacf4808 mach_msg2_trap + 8 1 libsystem_kernel.dylib 0x00000001eacf7f20 mach_msg_overwrite + 432 2 libsystem_kernel.dylib 0x00000001eacf7d60 mach_msg + 20 3 CoreFoundation 0x00000001a1c78f5c __CFRunLoopServiceMachPort + 156 4 CoreFoundation 0x00000001a1c78600 __CFRunLoopRun + 1204 5 CoreFoundation 0x00000001a1c77cd8 CFRunLoopRunSpecific + 604 6 Foundation 0x00000001a0b98e4c -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 208 7 Foundation 0x00000001a0b98c9c -[NSRunLoop(NSRunLoop) runUntilDate:] + 60 8 UIKitCore 0x00000001a42c4640 -[UIEventFetcher threadMain] + 416 9 Foundation 0x00000001a0baf718 NSThread__start + 728 10 libsystem_pthread.dylib 0x00000001fea5c06c _pthread_start + 132 11 libsystem_pthread.dylib 0x00000001fea570d8 thread_start + 4
Thread 6: 0 libsystem_kernel.dylib 0x00000001eacfa1cc __psynch_cvwait + 8 1 SFA.MAUI 0x00000001013339e4 0x100024000 + 19986916 2 SFA.MAUI 0x000000010149a53c 0x100024000 + 21456188 3 SFA.MAUI 0x0000000101498b9c 0x100024000 + 21449628 4 SFA.MAUI 0x000000010148dbf8 0x100024000 + 21404664 5 SFA.MAUI 0x000000010148b7c4 0x100024000 + 21395396 6 SFA.MAUI 0x000000010145a7cc 0x100024000 + 21194700 7 SFA.MAUI 0x0000000101406108 0x100024000 + 20848904 8 SFA.MAUI 0x0000000101418208 0x100024000 + 20922888 9 libsystem_pthread.dylib 0x00000001fea5c06c _pthread_start + 132 10 libsystem_pthread.dylib 0x00000001fea570d8 thread_start + 4
Thread 7: 0 libsystem_kernel.dylib 0x00000001eacfa1cc __psynch_cvwait + 8 1 SFA.MAUI 0x00000001013339e4 0x100024000 + 19986916 2 SFA.MAUI 0x000000010149a53c 0x100024000 + 21456188 3 SFA.MAUI 0x0000000101498b9c 0x100024000 + 21449628 4 SFA.MAUI 0x000000010148dbf8 0x100024000 + 21404664 5 SFA.MAUI 0x000000010148b7c4 0x100024000 + 21395396 6 SFA.MAUI 0x000000010145a7cc 0x100024000 + 21194700 7 SFA.MAUI 0x0000000101406108 0x100024000 + 20848904 8 SFA.MAUI 0x0000000101418208 0x100024000 + 20922888 9 libsystem_pthread.dylib 0x00000001fea5c06c _pthread_start + 132 10 libsystem_pthread.dylib 0x00000001fea570d8 thread_start + 4
Thread 8: 0 libsystem_kernel.dylib 0x00000001eacfb608 kevent + 8 1 SFA.MAUI 0x000000010149a568 0x100024000 + 21456232 2 SFA.MAUI 0x0000000101498b9c 0x100024000 + 21449628 3 SFA.MAUI 0x000000010148dbf8 0x100024000 + 21404664 4 SFA.MAUI 0x000000010148b7c4 0x100024000 + 21395396 5 SFA.MAUI 0x000000010145a7cc 0x100024000 + 21194700 6 SFA.MAUI 0x0000000101406108 0x100024000 + 20848904 7 SFA.MAUI 0x0000000101418208 0x100024000 + 20922888 8 libsystem_pthread.dylib 0x00000001fea5c06c _pthread_start + 132 9 libsystem_pthread.dylib 0x00000001fea570d8 thread_start + 4
Thread 9: 0 libsystem_kernel.dylib 0x00000001eacf4808 mach_msg2_trap + 8 1 libsystem_kernel.dylib 0x00000001eacf7f20 mach_msg_overwrite + 432 2 libsystem_kernel.dylib 0x00000001eacf7d60 mach_msg + 20 3 CoreFoundation 0x00000001a1c78f5c __CFRunLoopServiceMachPort + 156 4 CoreFoundation 0x00000001a1c78600 __CFRunLoopRun + 1204 5 CoreFoundation 0x00000001a1c77cd8 CFRunLoopRunSpecific + 604 6 CFNetwork 0x00000001a2e58c90 _CFHostIsDomainTopLevel + 108172 7 Foundation 0x00000001a0baf718 NSThread__start + 728 8 libsystem_pthread.dylib 0x00000001fea5c06c _pthread_start + 132 9 libsystem_pthread.dylib 0x00000001fea570d8 thread_start + 4
Thread 10: 0 libsystem_kernel.dylib 0x00000001eacfa1cc __psynch_cvwait + 8 1 SFA.MAUI 0x00000001002bcc30 0x100024000 + 2722864 2 SFA.MAUI 0x00000001002bc9c8 0x100024000 + 2722248 3 SFA.MAUI 0x00000001002bc0c0 0x100024000 + 2719936 4 SFA.MAUI 0x00000001002bd294 0x100024000 + 2724500 5 SFA.MAUI 0x00000001002bd308 0x100024000 + 2724616 6 libsystem_pthread.dylib 0x00000001fea5c06c _pthread_start + 132 7 libsystem_pthread.dylib 0x00000001fea570d8 thread_start + 4
Thread 11: 0 libsystem_kernel.dylib 0x00000001eacfa1cc __psynch_cvwait + 8 1 SFA.MAUI 0x00000001002bcc30 0x100024000 + 2722864 2 SFA.MAUI 0x00000001002bc9c8 0x100024000 + 2722248 3 SFA.MAUI 0x00000001002bc0c0 0x100024000 + 2719936 4 SFA.MAUI 0x00000001002bd294 0x100024000 + 2724500 5 SFA.MAUI 0x00000001002bd308 0x100024000 + 2724616 6 libsystem_pthread.dylib 0x00000001fea5c06c _pthread_start + 132 7 libsystem_pthread.dylib 0x00000001fea570d8 thread_start + 4
Thread 12: 0 libsystem_kernel.dylib 0x00000001eacfa1cc __psynch_cvwait + 8 1 SFA.MAUI 0x00000001002bcc30 0x100024000 + 2722864 2 SFA.MAUI 0x00000001002bc9c8 0x100024000 + 2722248 3 SFA.MAUI 0x00000001002bc0c0 0x100024000 + 2719936 4 SFA.MAUI 0x00000001002bd294 0x100024000 + 2724500 5 SFA.MAUI 0x00000001002bd308 0x100024000 + 2724616 6 libsystem_pthread.dylib 0x00000001fea5c06c _pthread_start + 132 7 libsystem_pthread.dylib 0x00000001fea570d8 thread_start + 4
Thread 13: 0 libsystem_kernel.dylib 0x00000001eacfa1cc __psynch_cvwait + 8 1 SFA.MAUI 0x00000001002bcc30 0x100024000 + 2722864 2 SFA.MAUI 0x00000001002bc9c8 0x100024000 + 2722248 3 SFA.MAUI 0x00000001002bc0c0 0x100024000 + 2719936 4 SFA.MAUI 0x00000001002bd294 0x100024000 + 2724500 5 SFA.MAUI 0x00000001002bd308 0x100024000 + 2724616 6 libsystem_pthread.dylib 0x00000001fea5c06c _pthread_start + 132 7 libsystem_pthread.dylib 0x00000001fea570d8 thread_start + 4
Thread 14: 0 libsystem_kernel.dylib 0x00000001eacfa1cc __psynch_cvwait + 8 1 SFA.MAUI 0x00000001002bcc30 0x100024000 + 2722864 2 SFA.MAUI 0x00000001002bc9c8 0x100024000 + 2722248 3 SFA.MAUI 0x00000001002bc0c0 0x100024000 + 2719936 4 SFA.MAUI 0x00000001002bd294 0x100024000 + 2724500 5 SFA.MAUI 0x00000001002bd308 0x100024000 + 2724616 6 libsystem_pthread.dylib 0x00000001fea5c06c _pthread_start + 132 7 libsystem_pthread.dylib 0x00000001fea570d8 thread_start + 4
Thread 15: 0 libsystem_kernel.dylib 0x00000001eacfa1cc __psynch_cvwait + 8 1 SFA.MAUI 0x00000001013339e4 0x100024000 + 19986916 2 SFA.MAUI 0x000000010149a53c 0x100024000 + 21456188 3 SFA.MAUI 0x0000000101498b9c 0x100024000 + 21449628 4 SFA.MAUI 0x000000010148dbf8 0x100024000 + 21404664 5 SFA.MAUI 0x000000010148b7c4 0x100024000 + 21395396 6 SFA.MAUI 0x000000010145a7cc 0x100024000 + 21194700 7 SFA.MAUI 0x0000000101406108 0x100024000 + 20848904 8 SFA.MAUI 0x0000000101418208 0x100024000 + 20922888 9 libsystem_pthread.dylib 0x00000001fea5c06c _pthread_start + 132 10 libsystem_pthread.dylib 0x00000001fea570d8 thread_start + 4
Thread 16: 0 libsystem_kernel.dylib 0x00000001eacf4590 __workq_kernreturn + 8 1 libsystem_pthread.dylib 0x00000001fea570cc start_wqthread + 4
Thread 17: 0 libsystem_kernel.dylib 0x00000001eacfa1cc __psynch_cvwait + 8 1 SFA.MAUI 0x0000000101353dec 0x100024000 + 20119020 2 SFA.MAUI 0x0000000101357a5c 0x100024000 + 20134492 3 SFA.MAUI 0x000000010149a53c 0x100024000 + 21456188 4 SFA.MAUI 0x0000000101498bd4 0x100024000 + 21449684 5 SFA.MAUI 0x000000010148dbf8 0x100024000 + 21404664 6 SFA.MAUI 0x000000010148b7c4 0x100024000 + 21395396 7 SFA.MAUI 0x000000010145a7cc 0x100024000 + 21194700 8 SFA.MAUI 0x0000000101406108 0x100024000 + 20848904 9 SFA.MAUI 0x0000000101418208 0x100024000 + 20922888 10 libsystem_pthread.dylib 0x00000001fea5c06c _pthread_start + 132 11 libsystem_pthread.dylib 0x00000001fea570d8 thread_start + 4
Thread 18: 0 libsystem_kernel.dylib 0x00000001eacf4590 __workq_kernreturn + 8 1 libsystem_pthread.dylib 0x00000001fea570cc start_wqthread + 4
Thread 19: 0 libsystem_kernel.dylib 0x00000001eacf4590 __workq_kernreturn + 8 1 libsystem_pthread.dylib 0x00000001fea570cc start_wqthread + 4
Thread 20: 0 libsystem_kernel.dylib 0x00000001eacfa1cc __psynch_cvwait + 8 1 Foundation 0x00000001a0b038d0 -[_NSThreadPerformInfo wait] + 40 2 Foundation 0x00000001a0b03190 -[NSObject(NSThreadPerformAdditions) performSelector:onThread:withObject:waitUntilDone:modes:] + 716 3 Foundation 0x00000001a0b028ec -[NSObject(NSThreadPerformAdditions) performSelectorOnMainThread:withObject:waitUntilDone:] + 108 4 SFA.MAUI 0x00000001012d923c 0x100024000 + 19616316 5 SFA.MAUI 0x0000000100eccc2c 0x100024000 + 15371308 6 SFA.MAUI 0x0000000101498f24 0x100024000 + 21450532 7 SFA.MAUI 0x000000010148dcd4 0x100024000 + 21404884 8 SFA.MAUI 0x000000010148b7c4 0x100024000 + 21395396 9 SFA.MAUI 0x000000010145a7cc 0x100024000 + 21194700 10 SFA.MAUI 0x0000000101406108 0x100024000 + 20848904 11 SFA.MAUI 0x0000000101418208 0x100024000 + 20922888 12 libsystem_pthread.dylib 0x00000001fea5c06c _pthread_start + 132 13 libsystem_pthread.dylib 0x00000001fea570d8 thread_start + 4
Thread 21: 0 libsystem_kernel.dylib 0x00000001eacfa1cc __psynch_cvwait + 8 1 SFA.MAUI 0x0000000101353dec 0x100024000 + 20119020 2 SFA.MAUI 0x0000000101357a5c 0x100024000 + 20134492 3 SFA.MAUI 0x000000010149a53c 0x100024000 + 21456188 4 SFA.MAUI 0x0000000101498bd4 0x100024000 + 21449684 5 SFA.MAUI 0x000000010148dbf8 0x100024000 + 21404664 6 SFA.MAUI 0x000000010148b7c4 0x100024000 + 21395396 7 SFA.MAUI 0x000000010145a7cc 0x100024000 + 21194700 8 SFA.MAUI 0x0000000101406108 0x100024000 + 20848904 9 SFA.MAUI 0x0000000101418208 0x100024000 + 20922888 10 libsystem_pthread.dylib 0x00000001fea5c06c _pthread_start + 132 11 libsystem_pthread.dylib 0x00000001fea570d8 thread_start + 4
Thread 22: 0 libsystem_kernel.dylib 0x00000001eacf4590 __workq_kernreturn + 8 1 libsystem_pthread.dylib 0x00000001fea570cc start_wqthread + 4
Thread 23: 0 libsystem_kernel.dylib 0x00000001eacf4590 __workq_kernreturn + 8 1 libsystem_pthread.dylib 0x00000001fea570cc start_wqthread + 4
Thread 24: 0 libsystem_kernel.dylib 0x00000001eacfa1cc __psynch_cvwait + 8 1 JavaScriptCore 0x00000001b932b0a4 0x1b7dd0000 + 22392996 2 libsystem_pthread.dylib 0x00000001fea5c06c _pthread_start + 132 3 libsystem_pthread.dylib 0x00000001fea570d8 thread_start + 4
Thread 25: 0 libsystem_kernel.dylib 0x00000001eacf4590 __workq_kernreturn + 8 1 libsystem_pthread.dylib 0x00000001fea570cc start_wqthread + 4
Thread 26: 0 libsystem_kernel.dylib 0x00000001eacf4590 __workq_kernreturn + 8 1 libsystem_pthread.dylib 0x00000001fea570cc start_wqthread + 4
Thread 27: 0 libsystem_kernel.dylib 0x00000001eacf4590 __workq_kernreturn + 8 1 libsystem_pthread.dylib 0x00000001fea570cc start_wqthread + 4
Thread 28: 0 libsystem_kernel.dylib 0x00000001eacf4590 __workq_kernreturn + 8 1 libsystem_pthread.dylib 0x00000001fea570cc start_wqthread + 4
Thread 29: 0 libsystem_kernel.dylib 0x00000001eacf4590 __workq_kernreturn + 8 1 libsystem_pthread.dylib 0x00000001fea570cc start_wqthread + 4
Thread 30: 0 libsystem_kernel.dylib 0x00000001eacf4590 __workq_kernreturn + 8 1 libsystem_pthread.dylib 0x00000001fea570cc start_wqthread + 4
Thread 31: 0 libsystem_kernel.dylib 0x00000001eacf4590 __workq_kernreturn + 8 1 libsystem_pthread.dylib 0x00000001fea570cc start_wqthread + 4
Thread 32: 0 libsystem_platform.dylib 0x00000001fe9a4d00 _platform_strncmp + 16 1 IntuneMAMSwift 0x0000000103743cb0 0x1034a0000 + 2768048 2 IntuneMAMSwift 0x000000010365d4b4 0x1034a0000 + 1823924 3 libdispatch.dylib 0x00000001a9b4c13c _dispatch_call_block_and_release + 28 4 libdispatch.dylib 0x00000001a9b4ddd4 _dispatch_client_callout + 16 5 libdispatch.dylib 0x00000001a9b55400 _dispatch_lane_serial_drain + 744 6 libdispatch.dylib 0x00000001a9b55f30 _dispatch_lane_invoke + 376 7 libdispatch.dylib 0x00000001a9b60cb4 _dispatch_root_queue_drain_deferred_wlh + 284 8 libdispatch.dylib 0x00000001a9b60528 _dispatch_workloop_worker_thread + 400 9 libsystem_pthread.dylib 0x00000001fea5a934 _pthread_wqthread + 284 10 libsystem_pthread.dylib 0x00000001fea570cc start_wqthread + 4
Thread 33: 0 libsystem_kernel.dylib 0x00000001eacf4590 __workq_kernreturn + 8 1 libsystem_pthread.dylib 0x00000001fea570cc start_wqthread + 4
Thread 34: 0 libsystem_kernel.dylib 0x00000001eacf4590 __workq_kernreturn + 8 1 libsystem_pthread.dylib 0x00000001fea570cc start_wqthread + 4
Thread 35: 0 libsystem_kernel.dylib 0x00000001eacf4590 __workq_kernreturn + 8 1 libsystem_pthread.dylib 0x00000001fea570cc start_wqthread + 4
Thread 36: 0 libsystem_kernel.dylib 0x00000001eacf4590 __workq_kernreturn + 8 1 libsystem_pthread.dylib 0x00000001fea570cc start_wqthread + 4
Thread 37: 0 libsystem_kernel.dylib 0x00000001eacf4590 __workq_kernreturn + 8 1 libsystem_pthread.dylib 0x00000001fea570cc start_wqthread + 4
Thread 38: 0 libsystem_kernel.dylib 0x00000001eacf4590 __workq_kernreturn + 8 1 libsystem_pthread.dylib 0x00000001fea570cc start_wqthread + 4
Thread 39: 0 libsystem_kernel.dylib 0x00000001eacf4590 __workq_kernreturn + 8 1 libsystem_pthread.dylib 0x00000001fea570cc start_wqthread + 4
Thread 40: 0 ??? 0x0000000000000000 0x0 + 0
Thread 41: 0 libsystem_kernel.dylib 0x00000001eacfa1cc __psynch_cvwait + 8 1 SFA.MAUI 0x0000000101353dec 0x100024000 + 20119020 2 SFA.MAUI 0x0000000101357a5c 0x100024000 + 20134492 3 SFA.MAUI 0x000000010149a53c 0x100024000 + 21456188 4 SFA.MAUI 0x0000000101498bd4 0x100024000 + 21449684 5 SFA.MAUI 0x000000010148dbf8 0x100024000 + 21404664 6 SFA.MAUI 0x000000010148b7c4 0x100024000 + 21395396 7 SFA.MAUI 0x000000010145a7cc 0x100024000 + 21194700 8 SFA.MAUI 0x0000000101406108 0x100024000 + 20848904 9 SFA.MAUI 0x0000000101418208 0x100024000 + 20922888 10 libsystem_pthread.dylib 0x00000001fea5c06c _pthread_start + 132 11 libsystem_pthread.dylib 0x00000001fea570d8 thread_start + 4
Thread 0 crashed with arm64 Thread State: x21: 0x00000002028f3fa0 x2: 0x0000000000000000 x16: 0x0000000000000148 x3: 0x0000000000000000 x22: 0x0000000302ac0ed0 x4: 0x0000000000000002 x17: 0x00000002028f3ec0 cpsr: 0x0000000040001000 x5: 0x00000001569e4c00 x23: 0x00000002094efc70 x6: 0x0000000000000400 x18: 0x0000000000000000 x10: 0x0000000000d3e200 lr: 0x00000001fea5dc0c x7: 0x000000000061a300 x24: 0x0000000000000045 x11: 0x0000000000bf3d01 x8: 0x1dec012dcacb7eae x19: 0x0000000000000006 x25: 0x00000001a20b843d x9: 0x1dec012fc844406e x12: 0x00000001569e4000 fp: 0x000000016fdd9110 x26: 0x00000002039d0f40 x13: 0x0000000000003fff pc: 0x00000001eacff42c x27: 0x00000002094ea000 x14: 0x0000000000000ee5 x20: 0x0000000000000103 x0: 0x0000000000000000 sp: 0x000000016fdd90f0 x28: 0x0000000000000003 x15: 0x0000000202900e58 x1: 0x0000000000000000
Binary Images:
0x0000000100024000 - 0x00000001019cffff +SFA.MAUI arm64
It seems quite a few people are running into this related to MauiTextField, so it might be a bug in MAUI.
However, we'll need a way to reproduce this ourselves in order to track it down. It doesn't necessarily have to be a small test project, it can be a modified version of a real-life project, where it's modified to automatically triggering the problem - say the problem occurs when opening a particular page, if the app automatically opens and closes said page in a loop, it would be possible to just leave the app running (overnight if necessary) until the crash is triggered.
Hi @formerlymisterhenson. We have added the "need-info" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.
![microsoft-github-policy-service[bot] avatar](https://avatars.githubusercontent.com/in/95686?v=4 "Published by a pub.dev verified publisher"){kind=small}