Xamarin-macios: iOS 14.2 app crashes if deployed via mdm but not from appstore

Created on 11 Nov 2020  ·  170Comments  ·  Source: xamarin/xamarin-macios

🚨⚠️🚨⚠️🚨⚠️🚨⚠️

See current proposed solution

🚨⚠️🚨⚠️🚨⚠️🚨⚠️

Steps to Reproduce

  1. The App has been built using Azure Devop pipelines it is then deployed to AppStore connect Via Fastlane
  2. The App is then deployed to devices via Mobile Iron
  3. Most apps are working but the combination of MobileIron, iOS 14.2 and it seems iPhone 11 are causing the issue described in the post.
  4. On iOS 14.1 - iPhone 11 everything works as expected see forum post.

https://forums.xamarin.com/discussion/186138/ios-14-2-app-crashes-if-deployed-via-mdm-but-not-from-appstore

Expected Behavior

The App shout start normally

Actual Behavior

The app crashes on start as it takes to long to start.

Environment

iOS 14.2 built with Mac OS 10.15.
https://github.com/actions/virtual-environments/blob/main/images/macos/macos-10.15-Readme.md

Symbolicated StackTrace

    0x00000001031448a8                                                               (in REDACTED.Mobile.iOS)
    wrapper_runtime_invoke_object_runtime_invoke_dynamic_intptr_intptr_intptr_intptr (in REDACTED.Mobile.iOS) + 260
    mono_jit_runtime_invoke                                                          (in REDACTED.Mobile.iOS) + 1104
    mono_runtime_invoke_checked                                                      (in REDACTED.Mobile.iOS) + 148
    create_exception_two_strings                                                     (in REDACTED.Mobile.iOS) + 360
    mono_exception_from_name_two_strings_checked                                     (in REDACTED.Mobile.iOS) + 148
    create_domain_objects                                                            (in REDACTED.Mobile.iOS) + 348
    mono_runtime_init_checked                                                        (in REDACTED.Mobile.iOS) + 312
    mini_init                                                                        (in REDACTED.Mobile.iOS) + 8200
    xamarin_main                                                                     (in REDACTED.Mobile.iOS) (monotouch-main.m:425)
    main                                                                             (in REDACTED.Mobile.iOS) (main.m:236)

Crash Report

Incident Identifier: 7A338BC3-9B9D-45BA-8367-6D2C7DB38D54
CrashReporter Key: 0a7f5514b1eabef9a9ced769aec120d56c1212d7
Hardware Model: iPhone12,1
Process: REDACTED.Mobile.iOS [441]
Path: /private/var/containers/Bundle/Application/ACDDB724-517E-4FC1-B07E-DEAEE9FE213A/REDACTED.Mobile.iOS.app/REDACTED.Mobile.iOS
Identifier: REDACTED
Version: 2011041216 (1.0.1)
AppStoreTools: 12A7604b
Code Type: ARM-64 (Native)
Role: Foreground
Parent Process: launchd [1]
Coalition: REDACTED [411]

Date/Time: 2020-11-09 14:53:13.4760 +0000
Launch Time: 2020-11-09 14:52:53.4304 +0000
OS Version: iPhone OS 14.2 (18B92)
Release Type: User
Baseband Version: 2.02.04
Report Version: 104

Exception Type: EXC_BAD_ACCESS (SIGKILL)
Exception Subtype: UNKNOWN_0x32 at 0x0000000105c908a8
VM Region Info: 0x105c908a8 is in 0x105c90000-0x105c94000; bytes after start: 2216 bytes before end: 14167
REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL
VM_ALLOCATE 105c8c000-105c90000 [ 16K] rw-/rwx SM=PRV
---> mapped file 105c90000-105c94000 [ 16K] r-x/r-x SM=COW ...t_id=5d9c747d
VM_ALLOCATE 105c94000-105c98000 [ 16K] rw-/rwx SM=PRV

Termination Reason: Namespace SPRINGBOARD, Code 0x8badf00d
Termination Description: SPRINGBOARD, domain:10 code:0x8BADF00D explanation:process-launch watchdog transgression: application:441 exhausted real (wall clock) time allowance of 20.00 seconds | ProcessVisibility: Foreground | ProcessState: Running | WatchdogEvent: process-launch | WatchdogVisibility: Foreground | WatchdogCPUStatistics: ( | "Elapsed total CPU time (seconds): 29.110 (user 29.110, system 0.000), 24% CPU", | "Elapsed application CPU time (seconds): 19.906, 17% CPU" | ) reportType:CrashLog maxTerminationResistance:Interactive>
Triggered by Thread: 0

```

bug iOS

Most helpful comment

We are now fairly sure the root issue is identified (testing is ongoing). IOW the information that Apple shared with us does match what people describe in this thread.

Context

Xamarin.iOS depends on small pieces of machine code called trampolines for a variety of functions. The runtime uses some low-level code to support an _infinite_ (dynamic) number of trampolines. This is the piece that stopped working.

In older versions of Xamarin.iOS (think MonoTouch) the AOT compiler used a fixed number for each type of trampolines. Going back to the old behaviour solve the issue. This can be done by using the --aot=nopagetrampolines option (but continue reading).

The main problem is that apps can run out of trampolines and crash/abort with a message like:

Ran out of trampolines of type %d in '%s' (limit %d)

The AOT compiler cannot know how many, of each type, of trampoline will be needed (it's known at runtime) and generating trampolines increases the executable size, so using extremely large numbers of them is not a good solution.

Suggested Workaround

Add the following options to the Additional mtouch arguments inside your application options.

--aot=nopagetrampolines,ntrampolines=40960,nrgctx-trampolines=40960,nrgctx-fetch-trampolines=256,ngsharedvt-trampolines=4096,nimt-trampolines=4096

UPDATE You might already have some additional arguments. Make sure you're appending the ones above and that you have a space between any existing and new ones. IOW the --aot= options are comma separated but mtouch options are space separated.

Screen Shot 2020-12-03 at 10 15 56 AM

Those options should be added to all (Debug/Release/...) project configuration for device builds, which is where the AOT compiler is being used. IOW it's not needed for simulator builds.

Testing

Once you produce a build you must re-test your application. Running out of trampolines happens at runtime and will crash (abort) the application. The console (Console.app) logs will show something like:

Ran out of trampolines of type X

If this happens you need to increase the amount for the mentioned type (X) of trampoline. You can try to double the existing amount (suggested above).

Trampoline types vs option names

  • normal trampolines (type 0) -> ntrampolines=X
  • rgctx trampolines (type 1) -> nrgctx-trampolines=X
  • imt trampolines (type 2) -> nimt-trampolines=X
  • gsharedvt arg trampolines (type 3): ngsharedvt-trampolines=X
  • unbox arbitrary trampolines (type 5): nunbox-arbitrary-trampolines=X
  • rgctx fetch trampolines -> nrgctx-fetch-trampolines=X

Example

Ran out of trampolines of type 2 (limit 4096)

  • Trampoline 2imtnimt-trampolines
  • Change the option from nimt-trampolines=4096 to nimt-trampolines=8192
  • Rebuild and re-test the application

We're aware this information is a bit raw and not very easy to consume. The goal was to get the information, including a workaround, out fast. Expect this post to be edited/refined until more appropriate documentation becomes available.

Big thanks to @vargaz who wrote most of this post. All mistakes are mine :-)
Also a huge thanks to everyone, here in this post, at Apple and Microsoft, who help to diagnose, debug and find a solution.

All 170 comments

I am experiencing the same issue with Xamarin.iOS (14.4.1.3) apps as well. The app crash only occurs if the app is deployed via MDM (AirWatch) from the App Store and does not occur if the app is built as an IPA and deployed via MDM.

The following workaround resolves the app crash:
1) Deploy app via MDM.
2) Enable "Offload App" iOS feature (Settings, General, iDevice Storage, Select app, tap "Offload App")
3) Next time the app is launched it is downloaded again from the App Store and the app crash no longer occurs.

The app are build identically for AppStore / AdHoc / MDM.

The code:0x8BADF00D means the watchdog killed the app since it took too much time to startup. It's possible that some 3rd party code is trying to do something different (e.g. reach a server) and that cause an unacceptable delay.

@kodejack can you open the console app and give us the logs from the device where this happens (between the app start and it's crash 20 seconds later). It's possible that either us, some 3rd party or the OS has logged warnings/errors that could shed some light on what went wrong. Thanks!

Here is my console output (app name replaced with REDACTED). I don't know if they are relevant but these events stand out:

Nov 12 12:24:37 iPad mediaserverd(MediaExperience)[481] <Notice>: -CMSessionMgr- CMSessionMgrHandleApplicationStateChange: Client com.REDACTED with pid '796' is now Foreground Running. Background entitlement: NO ActiveLongFormVideoSession: NO WhitelistedLongFormVideoApp NO
Nov 12 12:24:37 iPad powerd[41] <Notice>: Sleep revert state: 1
Nov 12 12:24:37 iPad mediaserverd(MediaExperience)[481] <Notice>: -CMSessionMgr- CMSessionMgrHandleApplicationStateChange: Sending EndInterruption to com.REDACTED with pid '796' because client moved to ForegroundRunning and is not allowed to play in the background

Full console output during 20 second app start to app crash:

==========  Nov 12, 2020 at 12:24:36 PM  ==========
Nov 12 12:24:35 iPad sharingd(CoreUtils)[531] <Notice>: NearbyInfo sending activity level, original: 0x7 encrypted:0x6
Nov 12 12:24:36 iPad locationd[64] <Notice>: MotionCoprocessor,startTime,626894676.519928,motionType,1,youthType,0,youthTypeReason,0
Nov 12 12:24:36 iPad sharingd(CoreUtils)[531] <Notice>: NearbyInfo Linger advertise stop: UserActive
Nov 12 12:24:36 iPad identityservicesd(IDSKVStore)[54] <Notice>: Saving database.
Nov 12 12:24:36 iPad identityservicesd(IDSKVStore)[54] <Notice>: PublicIdentityCache Destroying database.
Nov 12 12:24:36 iPad sharingd(CoreUtils)[531] <Notice>: NearbyInfo sending activity level, original: 0x7 encrypted:0x6
Nov 12 12:24:36 iPad identityservicesd(IDSKVStore)[54] <Notice>: PublicIdentityCache Closed database.
Nov 12 12:24:37 iPad SpringBoard(CoreMotion)[510] <Notice>: [CLIoHidInterface] Property for usage pair {65280, 9}: {GyroProperties = {    GyroFactoryMode = 0;
GyroMeasurementRange = 2000;
GyroXAxisOffset = 0;
GyroYAxisOffset = 0;
GyroZAxisOffset = 0;
}} was set successfully
Nov 12 12:24:37 iPad backboardd(IOKit)[61] <Notice>: 0x100000474: set report interval:5000 client:D36BA427-3397-4858-B96C-6A99F62AD918
Nov 12 12:24:37 iPad SpringBoard(CoreMotion)[510] <Notice>: [CLIoHidInterface] Property for usage pair {65280, 9}: {ReportInterval = 5000} was set successfully
Nov 12 12:24:37 iPad SpringBoard(CoreMotion)[510] <Notice>: [CLIoHidInterface] Property for usage pair {65280, 9}: {GyroExtLevelTriggerSync = 0} was set successfully
Nov 12 12:24:37 iPad backboardd(IOKit)[61] <Notice>: 0x100000474: set batch interval:15000 client:D36BA427-3397-4858-B96C-6A99F62AD918
Nov 12 12:24:37 iPad SpringBoard(CoreMotion)[510] <Notice>: [CLIoHidInterface] Property for usage pair {65280, 9}: {BatchInterval = 15000} was set successfully
Nov 12 12:24:37 iPad SpringBoard(CoreMotion)[510] <Notice>: {"msg":"CLGyroBiasEstimatorClientRemote::registerWithGyroBiasEstimatorPrivate", "event":"activity", "isBuildingGYTT":0, "client":"0x283d91600", "info":"0x104519618"}
Nov 12 12:24:37 iPad SpringBoard(LocationSupport)[510] <Notice>: {"msg":"Sending cached messages to daemon", "event":"activity"}
Nov 12 12:24:37 iPad locationd[64] <Notice>: {"msg":"state transition", "event":"state_transition", "state":"DaemonClient", "id":"0x1025768c0", "property":"lifecycle", "old":"0x0", "new":"0x1025768c0"}
Nov 12 12:24:37 iPad locationd[64] <Notice>: {"msg":"state transition", "event":"state_transition", "state":"DaemonClient", "id":"0x1025768c0", "property":"clientName", "old":"", "new":"com.apple.springboard"}
Nov 12 12:24:37 iPad locationd[64] <Notice>: Client com.apple.springboard connected with message name kCLConnectionMessageGyroBiasEstimation
Nov 12 12:24:37 iPad locationd[64] <Notice>: {"msg":"kCLConnectionMessageGyroBiasEstimation", "event":"activity", "this":"0x1025768c0", "registrationRequired":0, "registrationReceived":0}
Nov 12 12:24:37 iPad locationd[64] <Notice>: os_transaction created: (<private>) <private>
Nov 12 12:24:37 iPad locationd[64] <Notice>: Client com.apple.springboard (0x1025768c0) is subscribing to notification kCLConnectionMessageGyroBiasEstimation
Nov 12 12:24:37 iPad locationd[64] <Notice>: CLGyroBiasEstimator,SPUEnabled,1,BuildingGYTT,0,NumClients,1
Nov 12 12:24:37 iPad backboardd(PalmRejection)[61] <Notice>: number_of_contacts=1 number_of_fingers=1 number_of_palms=0
Nov 12 12:24:37 iPad backboardd(MultitouchHID)[61] <Notice>: [HID] [MT] dispatchEvent Dispatching event with 1 children, _eventMask=0x23 _childEventMask=0x3 Cancel=0 Touching=1 inRange=1
Nov 12 12:24:37 iPad SpringBoard(SpringBoardHome)[510] <Notice>: Allowing tap for icon view '<private>'
Nov 12 12:24:37 iPad SpringBoard(SpringBoardHome)[510] <Notice>: SBIconView touches began with event: <private>, tap gesture: <private>
Nov 12 12:24:37 iPad SpringBoard(SpringBoardHome)[510] <Notice>: Icon touch began: <private>
Nov 12 12:24:37 iPad SpringBoard(SpringBoard)[510] <Notice>: Found a reasonable launch image for <private>, not pre-warming SplashBoard. Load image into the snapshot instance.
Nov 12 12:24:37 iPad backboardd(MultitouchHID)[61] <Notice>: [HID] [MT] dispatchEvent Dispatching event with 1 children, _eventMask=0x23 _childEventMask=0x3 Cancel=0 Touching=0 inRange=0
Nov 12 12:24:37 iPad SpringBoard(SpringBoardHome)[510] <Notice>: Allowing tap for icon view '<private>'
Nov 12 12:24:37 iPad SpringBoard(SpringBoardHome)[510] <Notice>: Icon tapped: <private>
Nov 12 12:24:37 iPad SpringBoard(SpringBoard)[510] <Notice>: Initiating launch from icon view: <private>
Nov 12 12:24:37 iPad SpringBoard(SpringBoard)[510] <Notice>: Executing request: <SBMainWorkspaceTransitionRequest: 0x280fab330; eventLabel: SBUIApplicationIconLaunchEventLabel; display: Main; source: HomeScreen>
Nov 12 12:24:37 iPad locationd[64] <Notice>: MotionCoprocessor,startTime,626894678.115018,motionType,2,youthType,0,youthTypeReason,0
Nov 12 12:24:37 iPad locationd[64] <Notice>: os_transaction created: (<private>) <private>
Nov 12 12:24:37 iPad locationd[64] <Notice>: @WifiLogic, handleInput, System::CoarseMotion
Nov 12 12:24:37 iPad locationd[64] <Notice>: {"msg":"got motion state notification", "subHarvester":"Avenger"}
Nov 12 12:24:37 iPad locationd[64] <Notice>: {"msg":"updated avenger harvester motion activity state", "fLastMotionActivity":1, "nextMotionActivity":2, "subHarvester":"Avenger"}
Nov 12 12:24:37 iPad locationd[64] <Notice>: {"msg":"updateOperationalModeIfNecessary", "fIsAllowedToUseBest":0, "fCurrentTimeOffsetThreshold":"45.000000", "subHarvester":"Avenger"}
Nov 12 12:24:37 iPad locationd[64] <Notice>: {"msg":"CLWifi1SystemLogic::apply", "event":"elapsed", "begin_mach":248680274879, "end_mach":248680327724, "elapsed_s":"0.002201875", "event":"System::CoarseMotion", "now_s":"626894677.651976943"}
Nov 12 12:24:37 iPad locationd[64] <Notice>: os_transaction releasing: (<private>) <private>
Nov 12 12:24:37 iPad SpringBoard(SpringBoard)[510] <Notice>: Running <SBAppToAppWorkspaceTransaction: 0x10d9be9b0> for transition request:<SBMainWorkspaceTransitionRequest: 0x280fab330; eventLabel: SBUIApplicationIconLaunchEventLabel; display: Main; source: HomeScreen> {
applicationContext = <SBWorkspaceApplicationSceneTransitionContext: 0x2806fe3c0; background: NO> entities = {
SBLayoutRolePrimary = <SBDeviceApplicationSceneEntity: 0x281e5c550; ID: sceneID:com.REDACTED-default; layoutRole: primary>;
};
}
Nov 12 12:24:37 iPad SpringBoard(FrontBoard)[510] <Notice>: Creating process for executionContext with identity: application<com.REDACTED>
Nov 12 12:24:37 iPad SpringBoard(FrontBoard)[510] <Notice>: Created <FBWorkspace: 0x280a81340; application<com.REDACTED>>
Nov 12 12:24:37 iPad SpringBoard(FrontBoard)[510] <Notice>: Bootstrapping application<com.REDACTED> with intent foreground-interactive
Nov 12 12:24:37 iPad backboardd[61] <Notice>: Setting minimum brightness level: 0.000000 with fade duration 0.500000
Nov 12 12:24:37 iPad backboardd[61] <Notice>: Set BrightnessSystem property:DisplayBrightnessFadePeriod to:0.5
Nov 12 12:24:37 iPad backboardd[61] <Notice>: Set BrightnessSystem property:BrightnessMinPhysicalWithFade to:0
Nov 12 12:24:37 iPad backboardd[61] <Notice>: soft cancel on display:<main>
Nov 12 12:24:37 iPad runningboardd(RunningBoard)[31] <Notice>: Acquiring assertion targeting application<com.REDACTED> from originator [daemon<com.apple.SpringBoard>:510] with description <RBSAssertionDescriptor| "FBApplicationProcess" ID:31-510-1699 target:application<com.REDACTED> attributes:[    <RBSRunningReasonAttribute| runningReason:10000>,
    <RBSPreventIdleSleepGrant>,
    <RBSDefineRelativeStartTimeGrant>,
    <RBSGPUAccessGrant>,
    <RBSCPUAccessGrant| role:UserInteractiveNonFocal>,
    <RBSJetsamPriorityGrant| priority:Foreground>,
    <RBSResistTerminationGrant| terminationResistance:Interactive>,
    <RBSEndowmentGrant| namespace:com.apple.frontboard.visibility>
    ]>
Nov 12 12:24:37 iPad runningboardd(RunningBoard)[31] <Notice>: Assertion 31-510-1699 (target:application<com.REDACTED>) will be created as active
Nov 12 12:24:37 iPad runningboardd(RunningBoard)[31] <Notice>: Executing launch request for application<com.REDACTED> (FBApplicationProcess)
Nov 12 12:24:37 iPad runningboardd(RunningBoard)[31] <Notice>: Creating and launching job for: application<com.REDACTED>
Nov 12 12:24:37 iPad runningboardd(RunningBoard)[31] <Notice>: _mutateContextIfNeeded called for com.REDACTED
Nov 12 12:24:37 iPad runningboardd(RunningBoard)[31] <Notice>: Inserting mach service com.REDACTED.gsEvents into job for application<com.REDACTED>
Nov 12 12:24:37 iPad runningboardd(RunningBoard)[31] <Notice>: Finished acquiring assertion 31-510-1699 (target:application<com.REDACTED>)
Nov 12 12:24:37 iPad runningboardd(AppServerSupport)[31] <Notice>: <OSLaunchdJob | handle=28BA0B70-901E-4660-915C-E8451235B89E>: submitAndStart succeeded, state=2
Nov 12 12:24:37 iPad SpringBoard(SpringBoard)[510] <Notice>: SBMainWorkspaceApplicationSceneLayoutElementViewController-sceneID:com.REDACTED-default will begin transition to visible YES
Nov 12 12:24:37 iPad SpringBoard(SpringBoardFoundation)[510] <Notice>: Evaluate: no change - reason: Window unhidden: <SBMainDisplaySceneLayoutWindow: 0x10448c270>
Nov 12 12:24:37 iPad runningboardd(RunningBoardServices)[31] <Notice>: Caching handle <private>, with ipc id 17b28c870000031c, and pid 796
Nov 12 12:24:37 iPad runningboardd(RunningBoardServices)[31] <Notice>: Full encoding handle <private>, with data f7b28c870000031c, and pid 796
Nov 12 12:24:37 iPad runningboardd(RunningBoard)[31] <Notice>: [application<com.REDACTED>:796] This process will be managed.
Nov 12 12:24:37 iPad runningboardd(RunningBoard)[31] <Notice>: [application<com.REDACTED>:796] HOME is <private>
Nov 12 12:24:37 iPad runningboardd(RunningBoard)[31] <Notice>: [application<com.REDACTED>:796] TMPDIR is <private>
Nov 12 12:24:37 iPad runningboardd(RunningBoard)[31] <Notice>: Now tracking process: [application<com.REDACTED>:796]
Nov 12 12:24:37 iPad runningboardd(RunningBoard)[31] <Notice>: Using default underlying assertion for app: [application<com.REDACTED>:796]
Nov 12 12:24:37 iPad runningboardd(RunningBoard)[31] <Notice>: Acquiring assertion targeting [application<com.REDACTED>:796] from originator [application<com.REDACTED>:796] with description <RBSAssertionDescriptor| "RB Underlying Assertion" ID:31-31-1700 target:796 attributes:[  <RBSDomainAttribute| domain:"com.apple.underlying" name:"defaultUnderlyingAppAssertion" sourceEnvironment:"(null)">,
    <RBSAcquisitionCompletionAttribute| policy:AfterApplication>
    ]>
Nov 12 12:24:37 iPad kernel[0] <Notice>: memorystatus: set assertion priority(10) target REDACTED:796
Nov 12 12:24:37 iPad runningboardd(RunningBoard)[31] <Notice>: Calculated state for application<com.REDACTED>: running-active (role: UserInteractiveNonFocal)
Nov 12 12:24:37 iPad runningboardd(RunningBoard)[31] <Notice>: Assertion 31-31-1700 (target:[application<com.REDACTED>:796]) will be created as active
Nov 12 12:24:37 iPad runningboardd(RunningBoard)[31] <Notice>: processStartTime calculated start is 10361.686905 (now:10361.690707, diff0.003802)
Nov 12 12:24:37 iPad runningboardd(RunningBoard)[31] <Notice>: [application<com.REDACTED>:796] Set jetsam priority to 10 [0] flag[1]
Nov 12 12:24:37 iPad runningboardd(RunningBoard)[31] <Notice>: [application<com.REDACTED>:796] Resuming task.
Nov 12 12:24:37 iPad runningboardd(RunningBoard)[31] <Notice>: [application<com.REDACTED>:796] Set darwin role to: UserInteractiveNonFocal
Nov 12 12:24:37 iPad runningboardd(RunningBoard)[31] <Notice>: [application<com.REDACTED>:796] Set GPU priority to "allow"
Nov 12 12:24:37 iPad runningboardd(RunningBoard)[31] <Notice>: Calculated state for application<com.REDACTED>: running-active (role: UserInteractiveNonFocal)
Nov 12 12:24:37 iPad SpringBoard(FrontBoard)[510] <Notice>: [application<com.REDACTED>:796] Bootstrap success!
Nov 12 12:24:37 iPad runningboardd(AppServerSupport)[31] <Notice>: <OSLaunchdJob | handle=28BA0B70-901E-4660-915C-E8451235B89E>: monitor initial state is 2
Nov 12 12:24:37 iPad SpringBoard(RunningBoardServices)[510] <Notice>: Hit the server for a process handle 17b28c870000031c that resolved to: [application<com.REDACTED>:796]
Nov 12 12:24:37 iPad SpringBoard(RunningBoardServices)[510] <Notice>: Caching handle <private>, with ipc id 17b28c870000031c, and pid 796
Nov 12 12:24:37 iPad SpringBoard(FrontBoard)[510] <Notice>: [application<com.REDACTED>:796] Setting process task state to: Running
Nov 12 12:24:37 iPad SpringBoard(FrontBoard)[510] <Notice>: [application<com.REDACTED>:796] Setting process visibility to: Foreground
Nov 12 12:24:37 iPad SpringBoard(RunningBoardServices)[510] <Notice>: Hit the server for a process handle 17b28c870000031c that resolved to: [application<com.REDACTED>:796]
Nov 12 12:24:37 iPad SpringBoard(RunningBoardServices)[510] <Notice>: Caching handle <private>, with ipc id 17b28c870000031c, and pid 796
Nov 12 12:24:37 iPad SpringBoard(FrontBoard)[510] <Notice>: [application<com.REDACTED>:796] Registering event dispatcher at connect
Nov 12 12:24:37 iPad SpringBoard(FrontBoard)[510] <Notice>: Registering: <FBWorkspaceEventDispatcherRegistration: 0x2833631b0> for identity: 796
Nov 12 12:24:37 iPad SpringBoard(FrontBoard)[510] <Notice>: [application<com.REDACTED>:796] Initial launch assertion state: ForegroundActive.
Nov 12 12:24:37 iPad SpringBoard(FrontBoard)[510] <Notice>: [application<com.REDACTED>:796] Not creating workspace endpoint injector.
Nov 12 12:24:37 iPad mediaserverd(RunningBoardServices)[481] <Notice>: Hit the server for a process handle 17b28c870000031c that resolved to: [application<com.REDACTED>:796]
Nov 12 12:24:37 iPad mediaserverd(RunningBoardServices)[481] <Notice>: Caching handle <private>, with ipc id 17b28c870000031c, and pid 796
Nov 12 12:24:37 iPad runningboardd(RunningBoard)[31] <Notice>: Acquired process power assertion with ID 38172 for pid 796
Nov 12 12:24:37 iPad runningboardd(RunningBoard)[31] <Notice>: [application<com.REDACTED>:796] reported to RB as running
Nov 12 12:24:37 iPad runningboardd(AppServerSupport)[31] <Notice>: <OSLaunchdJob | handle=28BA0B70-901E-4660-915C-E8451235B89E>: starting monitoring
Nov 12 12:24:37 iPad SpringBoard(FrontBoard)[510] <Notice>: Adding: <FBApplicationProcess: 0x1047b0da0; application<com.REDACTED>:796(v871)>
Nov 12 12:24:37 iPad runningboardd(RunningBoard)[31] <Notice>: Finished acquiring assertion 31-31-1700 (target:[application<com.REDACTED>:796])
Nov 12 12:24:37 iPad SpringBoard(RunningBoardServices)[510] <Notice>: Updating configuration of monitor <RBSProcessMonitorConfiguration| id:M510-2 qos:25 predicates:[<RBSProcessPredicate <RBSProcessIdentifierPredicate| 547>>, <RBSProcessPredicate <RBSProcessIdentifierPredicate| 796>>, <RBSProcessPredicate <RBSProcessIdentifierPredicate| 679>>, <RBSProcessPredicate <RBSProcessIdentifierPredicate| 532>>, <RBSProcessPredicate <RBSProcessIdentifierPredicate| 751>>, <RBSProcessPredicate <RBSProcessIdentifierPredicate| 523>>] descriptor:<RBSProcessStateDescriptor| values:1> events:0x0>
Nov 12 12:24:37 iPad runningboardd(RunningBoard)[31] <Notice>: Successfully acquired underlying assertion for [application<com.REDACTED>:796]
Nov 12 12:24:37 iPad mediaserverd(MediaExperience)[481] <Notice>: -CMSessionMgr- CMSessionMgrHandleApplicationStateChange: Client com.REDACTED with pid '796' is now Foreground Running. Background entitlement: NO ActiveLongFormVideoSession: NO WhitelistedLongFormVideoApp NO
Nov 12 12:24:37 iPad powerd[41] <Notice>: Sleep revert state: 1
Nov 12 12:24:37 iPad mediaserverd(MediaExperience)[481] <Notice>: -CMSessionMgr- CMSessionMgrHandleApplicationStateChange: Sending EndInterruption to com.REDACTED with pid '796' because client moved to ForegroundRunning and is not allowed to play in the background
Nov 12 12:24:37 iPad powerd[41] <Notice>: Process runningboardd.31 Created SystemIsActive "application<com.REDACTED>;(null):(null);31-510-1699:FBApplicationProcess" age:00:00:00  id:51539645724 [System: PrevIdle SysAct]
Nov 12 12:24:37 iPad SpringBoard(FrontBoard)[510] <Notice>: change foreground process from list:<FBApplicationProcess: 0x1047b0da0; application<com.REDACTED>:796(v871)>
Nov 12 12:24:37 iPad SpringBoard(SpringBoard)[510] <Notice>: Beging pending app suggestions update because Transitioning
Nov 12 12:24:37 iPad SpringBoard(UserNotificationsServer)[510] <Notice>: [com.REDACTED] Foreground app will not request ephemeral notifications isAppClip: NO wantsEphemeral notifications: NO
Nov 12 12:24:37 iPad SpringBoard(SpringBoard)[510] <Notice>: Deactivating wallpaper orientation source ActiveOrientation
Nov 12 12:24:37 iPad SpringBoard(UserNotificationsServer)[510] <Notice>: [com.REDACTED] com.REDACTED application state changed to ForegroundRunning
Nov 12 12:24:37 iPad SpringBoard(UserNotificationsServer)[510] <Notice>: [com.REDACTED] Ignore becoming foreground for application without push registration
Nov 12 12:24:37 iPad SpringBoard(UIKitCore)[510] <Notice>: Added: <UIApplicationSceneDeactivationAssertion: 0x283133660; reason: systemAnimation; all scene levels; hasPredicate: NO>
Nov 12 12:24:37 iPad SpringBoard(SpringBoard)[510] <Notice>: participant=0x2827b5d40:SBHomeGestureParticipantIdentifierSwitcher suppression set to:None
Nov 12 12:24:37 iPad SpringBoard(SpringBoard)[510] <Notice>: Disabling home screen icon rotation for reason: SBAppToAppWorkspaceTransaction
Nov 12 12:24:37 iPad CommCenter[83] <Notice>: #I <private> request: <private>, expects reply.
Nov 12 12:24:37 iPad CommCenter[83] <Notice>: #I FBSDisplayLayoutUpdateHandler: update start
Nov 12 12:24:37 iPad CommCenter[83] <Notice>: #I FBSDisplayLayoutUpdateHandler: app <private> (UIApplicationElement 1 hasKeyboardFocus 0)
Nov 12 12:24:37 iPad CommCenter[83] <Notice>: #I <private> reply to request '<private>'.
Nov 12 12:24:37 iPad SpringBoard(SpringBoard)[510] <Notice>: [Main] dispatch event:<SBInsertionSwitcherModifierEvent: 0x28336a760; type: Insertion; intoIndex: 0; phase: DidUpdateModel; appLayout: <SBAppLayout: 0x282724780; primary: com.REDACTED; environment: main>>
Nov 12 12:24:37 iPad CommCenter(FrontBoardServices)[83] <Notice>: Creating service facility connection with <private>
Nov 12 12:24:37 iPad SpringBoard(RunningBoardServices)[510] <Notice>: Caching handle <private>, with ipc id 17b28c870000031c, and pid 796
Nov 12 12:24:37 iPad CommCenter[83] <Notice>: #I <private> request: <private>, expects reply.
Nov 12 12:24:37 iPad CommCenter[83] <Notice>: #I <private> reply to request '<private>'.
Nov 12 12:24:37 iPad CommCenter(RunningBoardServices)[83] <Notice>: Caching handle <private>, with ipc id 17b28c870000031c, and pid 796
Nov 12 12:24:37 iPad wifid(WiFiPolicy)[49] <Notice>: App state params {    IO80211IsInHomeScreen = 0;
IO80211IsLatencySensitiveAppActive = 0;
}
Nov 12 12:24:37 iPad wifid(WiFiPolicy)[49] <Notice>: WiFiDeviceSetProperty: ERROR: Setting reg entry key IO80211AppState failed e00002d8
Nov 12 12:24:37 iPad wifid(WiFiPolicy)[49] <Notice>: BG Application: Not Present, BG Daemon: Present. Daemons: apsd  Cloud Clients:
Nov 12 12:24:37 iPad CommCenter(FrontBoardServices)[83] <Notice>: [FBSSystemAppProxy:0x103842550] Service facility connection invalidated
Nov 12 12:24:37 iPad SpringBoard(SpringBoard)[510] <Notice>: [Main] dispatch event:<SBMainTransitionSwitcherModifierEvent: 0x2806e2ff0; type: MainTransition; transitionID: B6E5D56D-561B-4C24-9D4D-4F152E2236C2; phase: Prepare; animated: YES; fromAppLayout: 0x0; toAppLayout: <SBAppLayout: 0x282724780; primary: com.REDACTED; environment: main>; fromEnvironmentMode: home-screen; toEnvironmentMode: application; pendingTermination: {(
)}>
Nov 12 12:24:37 iPad CommCenter[83] <Notice>: #I FBSDisplayLayoutUpdateHandler: 4. app got notification state: pid=796 for <private>
Nov 12 12:24:37 iPad CommCenter[83] <Notice>: #I ActivationObserver: notifyAboutFrontAppChange : app: <private>; pid: 796; net: 0
Nov 12 12:24:37 iPad CommCenter[83] <Notice>: #I FBSDisplayLayoutUpdateHandler: 5. app got notification state: new counter=69
Nov 12 12:24:37 iPad SpringBoard(SpringBoard)[510] <Notice>: [Main] handle response:<SBSwitcherModifierEventResponse: 0x2832d58f0> {
<SBSwitcherModifierEventResponse: 0x2832e2160> {
        <SBTimerEventSwitcherEventResponse: 0x2832e2190; delay: 0.500000; reason: kSBTransitionModifierInvalidateAsyncRenderingReason>;
        <SBInvalidateAdjustedAppLayoutsSwitcherEventResponse: 0x2832e22e0>;
    };
<SBSwitcherModifierEventResponse: 0x2832e1ad0> {
        <SBUpdateLayoutSwitcherEventResponse: 0x28270e640; layoutImmediately; layout; style; mode: None>;
        <SBRequestFolderSnapshotsSwitcherEventResponse: 0x2832e1c20; snapshotRequested: YES>;
        <SBIconOverlayVisibilitySwitcherEventResponse: 0x28270d400; visible: YES; appLayout: <SBAppLayout: 0x282724780; primary: com.REDACTED; environment: main>>;
        <SBIconViewVisibilitySwitcherEventResponse: 0x281eaa580; visible: NO; animationSettings: 0x0; appLayout: <SBAppLayout: 0x282724780; primary: com.REDACTED; environment: main>>;
        <SBTimerEventSwitcherEventResponse: 0x2832e33f0; delay: 0.300000; reason: kSBI
Nov 12 12:24:37 iPad locationd(RunningBoardServices)[64] <Notice>: Hit the server for a process handle 17b28c870000031c that resolved to: [application<com.REDACTED>:796]
Nov 12 12:24:37 iPad wifid(RunningBoardServices)[49] <Notice>: Hit the server for a process handle 17b28c870000031c that resolved to: [application<com.REDACTED>:796]
Nov 12 12:24:37 iPad wifid(RunningBoardServices)[49] <Notice>: Caching handle <private>, with ipc id 17b28c870000031c, and pid 796
Nov 12 12:24:37 iPad locationd(RunningBoardServices)[64] <Notice>: Caching handle <private>, with ipc id 17b28c870000031c, and pid 796
Nov 12 12:24:37 iPad SpringBoard(SpringBoard)[510] <Notice>: Begin requiring home screen content for reason 'SBGridSwitcherViewController-0x1050aaa00-Main'
Nov 12 12:24:37 iPad locationd[64] <Notice>: {"msg":"#CLIUA Marking change", "clientKey":"com.REDACTED", "reason":"Process state from RunningBoard", "assertionLevel":5, "coming":1}
Nov 12 12:24:37 iPad SpringBoard(SpringBoardFoundation)[510] <Notice>: Push: <SBMainSwitcherWindow: 0x10455d7a0>
Nov 12 12:24:37 iPad SpringBoard(SpringBoardFoundation)[510] <Notice>: Evaluate: making new window key: <SBMainSwitcherWindow: 0x10455d7a0>, for reason: push
Nov 12 12:24:37 iPad SpringBoard(SpringBoard)[510] <Notice>: updateKeyboardFocusDeferringRules: SpringBoard gets focus for reasons:(noKeyboardFocusProcess)
Nov 12 12:24:37 iPad runningboardd(RunningBoard)[31] <Notice>: Acquiring assertion targeting [daemon<com.apple.SpringBoard>:510](UIScene:com.apple.frontboard.systemappservices::com.apple.springboard) from originator [daemon<com.apple.SpringBoard>:510] with description <RBSAssertionDescriptor| "injecting inherited from "UIScene:com.apple.frontboard.systemappservices::com.apple.springboard" to 510<UIScene:com.apple.frontboard.systemappservices::com.apple.springboard>" ID:31-510-1701 target:510<UIScene:com.apple.frontboard.systemappservices::com.apple.springboard> attributes:[    <RBSHereditaryGrant| endowmentNamespace:com.apple.boardservices.endpoint-injection UIScene:com.apple.frontboard.systemappservices::com.apple.springboard>,
    <RBSHereditaryGrant| endowmentNamespace:com.apple.frontboard.visibility UIScene:com.apple.frontboard.systemappservices::com.apple.springboard>
    ]>
Nov 12 12:24:37 iPad runningboardd(RunningBoard)[31] <Notice>: Assertion 31-510-1701 (target:[daemon<com.apple.SpringBoard>:510](UIScene:com.apple.frontboard.systemappservices::com.apple.springboard)) will be created as active
Nov 12 12:24:37 iPad SpringBoard(SpringBoard)[510] <Notice>: Ignoring interaction events for reason: default -- count: 1
Nov 12 12:24:37 iPad backboardd(BackBoardHIDEventFoundation)[61] <Notice>: new deferring rules for pid:510: [    <environment: system> -> <pid: 510; token: 0x15718FD7> reason: "1-deferDiscrete: systemGestures",
<environment: keyboardFocus; display: builtin> -> <pid: 510; token: 0xA872C3A8> reason: "131-deferDiscrete: Key Window event focus deferral",
<environment: keyboardFocus; display: builtin> -> <pid: 510; token: 0x5D484C4> reason: "132-deferDiscrete: Key Window event focus deferral"
]
Nov 12 12:24:37 iPad backboardd(BackBoardHIDEventFoundation)[61] <Notice>: new resolutions for pid:510 (    <display: builtin; environment: keyboardFocus; pid: 510; token: 0x5D484C4>,
<display: null; environment: system; pid: 510; token: 0x15718FD7>,
<display: builtin; environment: cameraButton; pid: 510>
)
Nov 12 12:24:37 iPad runningboardd(RunningBoard)[31] <Notice>: [daemon<com.apple.SpringBoard>:510] Ignoring jetsam update because this process is not memory-managed
Nov 12 12:24:37 iPad runningboardd(RunningBoard)[31] <Notice>: [daemon<com.apple.SpringBoard>:510] Ignoring suspend because this process is not lifecycle managed
Nov 12 12:24:37 iPad runningboardd(RunningBoard)[31] <Notice>: [daemon<com.apple.SpringBoard>:510] Ignoring GPU update because this process is not GPU managed
Nov 12 12:24:37 iPad runningboardd(RunningBoard)[31] <Notice>: Calculated state for daemon<com.apple.SpringBoard>: running-active (role: UserInteractiveNonFocal)
Nov 12 12:24:37 iPad runningboardd(RunningBoard)[31] <Notice>: Finished acquiring assertion 31-510-1701 (target:[daemon<com.apple.SpringBoard>:510](UIScene:com.apple.frontboard.systemappservices::com.apple.springboard))
Nov 12 12:24:37 iPad homed(HomeKitDaemon)[478] <Notice>: Received app state change: <RBSProcessStateUpdate| process:[daemon<com.apple.SpringBoard>:510] oldState:<RBSProcessState| task:running-active debug:none endowments:[  com.apple.frontboard.visibility
    ] rbAssertions:[
    <RBSProcessAssertionInfo| type:1 reason:0 name:"Custom" domain:"(null)" expl:"creating 510<UIRootWindow:0x10460eb30> visibility">,
    <RBSProcessAssertionInfo| type:2 reason:0 name:"Domain" domain:"com.apple.underlying:UnderlyingDarwinRoleUI" expl:"RB Underlying Assertion">,
    <RBSProcessAssertionInfo| type:1 reason:10005 name:"Custom" domain:"(null)" expl:"FBSystemShell">,
    <RBSProcessAssertionInfo| type:1 reason:0 name:"Custom" domain:"(null)" expl:"FBSystemApp-PreventIdleSleep">,
    <RBSProcessAssertionInfo| type:1 reason:0 name:"Custom" domain:"(null)" expl:"injecting inherited from "UIRootWindow:0x10460eb30" to 510<UIScene:com.apple.frontboard.systemappservices::com.apple.springboard>">,
    <RBSProcessAssertionInfo| type:1 reason:0 name:"Custom" domain:"(null)" expl:"creating 510<UIRootWindow:0x10462a340> visibility">
    ]> newState:<RBSProcessState| task:running-active debug:none endowments:[
    com.apple.frontboard.visibility
    ] rbAssertions:[
    <RBSProcessAssertionInfo| type:1 reason:0 name:"Custom" domain:"(null)" expl:"FBSystemApp-PreventIdleSleep">,
    <RBSProcessAssertionInfo| type:2 reason:0 name:"Domain" domain:"com.apple.underlying:UnderlyingDarwinRoleUI" expl:"RB Underlying Assertion">,
    <RBSProcessAssertionInfo| type:1 reason:0 name:"Custom" domain:"(null)" expl:"injecting inherited from "UIScene:com.apple.frontboard.systemappservices::com.apple.springboard" to 510<UIScene:com.apple.frontboard.systemappservices::com.apple.springboard>">,
    <RBSProcessAssertionInfo| type:1 reason:0 name:"Custom" domain:"(null)" expl:"injecting inherited from "UIRootWindow:0x10460eb30" to 510<UIScene:com.apple.frontboard.systemappservices::com.apple.springboard>">,
    <RBSProcessAssertionInfo| type:1 reason:0 name:"Custom" domain:"(null)" expl:"creating 510<UIRootWindow:0x10462a340> visibility">,
    <RBSProcessAssertionInfo| type:1 reason:0 name:"Custom" domain:"(null)" expl:"creating 510<UIRootWindow:0x10460eb30> visibility">,
    <RBSProcessAssertionInfo| type:1 reason:10005 name:"Custom" domain:"(null)" expl:"FBSystemShell">
    ]> exitEvent:(null)>
Nov 12 12:24:37 iPad homed(HomeKitDaemon)[478] <Notice>: <HMDProcessInfo, Identifier: 510, Name: SpringBoard, Application Identifier: com.apple.springboard, State: foreground, Monitored: YES, Application: <__HMDApplicationInfo, Bundle Identifier: com.apple.springboard, Vendor Identifier: <[36] {length = 8, bytes = 0x3239453141414543} ... {length = 8, bytes = 0x3345394446463939}>>, Connections: (    "<HMDXPCClientConnection, Name: SpringBoard, Entitlements: com.apple.developer.homekit>",
"<HMDXPCClientConnection, Name: SpringBoard, Entitlements: com.apple.developer.homekit>"
)> back into foreground
Nov 12 12:24:37 iPad homed(HomeKitDaemon)[478] <Notice>: Processing change of state for <HMDProcessInfo, Identifier: 510, Name: SpringBoard, Application Identifier: com.apple.springboard, State: foreground, Monitored: YES, Application: <__HMDApplicationInfo, Bundle Identifier: com.apple.springboard, Vendor Identifier: <[36] {length = 8, bytes = 0x3239453141414543} ... {length = 8, bytes = 0x3345394446463939}>>, Connections: (    "<HMDXPCClientConnection, Name: SpringBoard, Entitlements: com.apple.developer.homekit>",
"<HMDXPCClientConnection, Name: SpringBoard, Entitlements: com.apple.developer.homekit>"
)>
Nov 12 12:24:37 iPad sharingd[531] <Notice>: SystemUI changed: 0x10 -> 0x0
Nov 12 12:24:37 iPad symptomsd(RunningBoardServices)[123] <Notice>: Hit the server for a process handle 17b28c870000031c that resolved to: [application<com.REDACTED>:796]
Nov 12 12:24:37 iPad symptomsd(RunningBoardServices)[123] <Notice>: Caching handle <private>, with ipc id 17b28c870000031c, and pid 796
Nov 12 12:24:37 iPad contextstored(RunningBoardServices)[57] <Notice>: Hit the server for a process handle 17b28c870000031c that resolved to: [application<com.REDACTED>:796]
Nov 12 12:24:37 iPad contextstored(RunningBoardServices)[57] <Notice>: Caching handle <private>, with ipc id 17b28c870000031c, and pid 796
Nov 12 12:24:37 iPad SpringBoard(SpringBoard)[510] <Notice>: Ending ignoring interaction events for reason: default -- new count: 0
Nov 12 12:24:37 iPad UserEventAgent(RunningBoardServices)[28] <Notice>: Hit the server for a process handle 17b28c870000031c that resolved to: [application<com.REDACTED>:796]
Nov 12 12:24:37 iPad UserEventAgent(RunningBoardServices)[28] <Notice>: Caching handle <private>, with ipc id 17b28c870000031c, and pid 796
Nov 12 12:24:37 iPad kbd(RunningBoardServices)[299] <Notice>: Hit the server for a process handle 17b28c870000031c that resolved to: [application<com.REDACTED>:796]
Nov 12 12:24:37 iPad kbd(RunningBoardServices)[299] <Notice>: Caching handle <private>, with ipc id 17b28c870000031c, and pid 796
Nov 12 12:24:37 iPad accessoryd(RunningBoardServices)[150] <Notice>: Hit the server for a process handle 17b28c870000031c that resolved to: [application<com.REDACTED>:796]
Nov 12 12:24:37 iPad watchdogd(RunningBoardServices)[55] <Notice>: Hit the server for a process handle 17b28c870000031c that resolved to: [application<com.REDACTED>:796]
Nov 12 12:24:37 iPad accessoryd(RunningBoardServices)[150] <Notice>: Caching handle <private>, with ipc id 17b28c870000031c, and pid 796
Nov 12 12:24:37 iPad SpringBoard(UIKitCore)[510] <Notice>: Added: <UIApplicationSceneDeactivationAssertion: 0x283190a50; reason: systemAnimation; all scene levels; hasPredicate: YES>
Nov 12 12:24:37 iPad SpringBoard(UIKitCore)[510] <Notice>: Removed: <UIApplicationSceneDeactivationAssertion: 0x283133660; reason: systemAnimation; all scene levels; hasPredicate: NO>
Nov 12 12:24:37 iPad SpringBoard(SpringBoard)[510] <Notice>: [Main] dispatch event:<SBMainTransitionSwitcherModifierEvent: 0x2806e79b0; type: MainTransition; transitionID: B6E5D56D-561B-4C24-9D4D-4F152E2236C2; phase: Animate; animated: YES; fromAppLayout: 0x0; toAppLayout: <SBAppLayout: 0x282724780; primary: com.REDACTED; environment: main>; fromEnvironmentMode: home-screen; toEnvironmentMode: application; pendingTermination: {(
)}>
Nov 12 12:24:37 iPad watchdogd(RunningBoardServices)[55] <Notice>: Caching handle <private>, with ipc id 17b28c870000031c, and pid 796
Nov 12 12:24:37 iPad SpringBoard(SpringBoard)[510] <Notice>: adding status bar settings assertion: <SBAppStatusBarSettingsAssertion: 0x2831f7db0> {    settings = <SBAppStatusBarSettings: 0x283f87780; alpha: 0>;
level = app switcher;
reason = kSBMainAppSwitcherStatusBarReason;
}
Nov 12 12:24:37 iPad accessoryd(System)[150] <Notice>: Posting application state change {    ACCPlatformApplicationStateDisplayIDKey = "com.REDACTED";
ACCPlatformApplicationStateKey = 8;
ACCPlatformApplicationStateProcessIDKey = 796;
}
Nov 12 12:24:37 iPad SpringBoard(SpringBoard)[510] <Notice>: adding floating dock behavior assertion: <SBFloatingDockBehaviorAssertion: 0x282707c80> {    pinned = NO;
animated = YES;
gesture possible = YES;
visible progress = 0.000000;
level = in app;
reason = in app;
timestamp = 2020-11-12 17:24:37 +0000;
}
Nov 12 12:24:37 iPad accessoryd[150] <Notice>: handling app state change notification {    ACCPlatformApplicationStateDisplayIDKey = "com.REDACTED";
ACCPlatformApplicationStateKey = 8;
ACCPlatformApplicationStateProcessIDKey = 796;
}
Nov 12 12:24:37 iPad aggregated(RunningBoardServices)[70] <Notice>: Hit the server for a process handle 17b28c870000031c that resolved to: [application<com.REDACTED>:796]
Nov 12 12:24:37 iPad aggregated(RunningBoardServices)[70] <Notice>: Caching handle <private>, with ipc id 17b28c870000031c, and pid 796
Nov 12 12:24:37 iPad SpringBoard(FrontBoard)[510] <Notice>: [application<com.REDACTED>:796] Registered new scene: <FBUIApplicationWorkspaceScene: 0x280afd4a0; sceneID:com.REDACTED-default> (fromRemnant = 0)
Nov 12 12:24:37 iPad SpringBoard(UIKitCore)[510] <Notice>: Now tracking: <FBScene: 0x280afed60; sceneID: sceneID:com.REDACTED-default; valid: YES>
Nov 12 12:24:37 iPad SpringBoard(FrontBoard)[510] <Notice>: [application<com.REDACTED>:796] Workspace interruption policy did change: terminate
Nov 12 12:24:37 iPad SpringBoard(UIKitCore)[510] <Notice>: [sceneID:com.REDACTED-default] Setting deactivation reasons to: 'systemAnimation' for reason: scene settings update - settings are eligible for deactivation reasons.
Nov 12 12:24:37 iPad SpringBoard(SpringBoard)[510] <Notice>: SBIdleTimerGlobalCoordinator - _setIdleTimerWithDescriptor:<SBIdleTimerDescriptor: 0x283138450; timerMode: Automatic; sampleInterval: 4.0s; quickUnwarnInterval: 102.0s; warnInterval: 100.0s; totalInterval: 120.0s> reason:"SBAppDidEnterForeground"]
Nov 12 12:24:37 iPad SpringBoard(SpringBoard)[510] <Notice>: 0x2827e6200 reconfigured attention timeouts:(    "<ITIdleTimeout: 0x283ccd000; identifier: 1; duration: 100.0s>",
"<ITIdleTimeout: 0x283ccc920; identifier: 2; duration: 102.0s>",
"<ITIdleTimeout: 0x283ccd240; identifier: 3; duration: 120.0s>"
)
Nov 12 12:24:37 iPad runningboardd(RunningBoard)[31] <Notice>: Acquiring assertion targeting [application<com.REDACTED>:796] from originator [daemon<com.apple.SpringBoard>:510] with description <RBSAssertionDescriptor| "com.apple.frontboard.after-life.subordinate" ID:31-510-1702 target:796 attributes:[ <RBSSubordinateProcessAttribute>
    ]>
Nov 12 12:24:37 iPad runningboardd(RunningBoard)[31] <Notice>: Assertion 31-510-1702 (target:[application<com.REDACTED>:796]) will be created as active
Nov 12 12:24:37 iPad backboardd(AttentionAwareness)[61] <Notice>:                 RemoteClient.m:603 :   10361.72177:  Info: reset attention lost timeout for com.apple.springboard.GlobalBacklightIdleTimer at   10361.72177
Nov 12 12:24:37 iPad backboardd(AttentionAwareness)[61] <Notice>:                 RemoteClient.m:334 :   10361.72191:  Info: updated config <AWRemoteClient: 0x12be18a20> (identifier: com.apple.springboard.GlobalBacklightIdleTimer samplingInterval:       4.00000 samplingDelay:      84.00000 sampleWhileAbsent: false attentionLostTimeouts: 100, 102, 120 notificationMask NONE mask AttentionLost|Button|Keyboard|Digitizer|Pointer|GameController|FaceDetect|MesaTouch|GenericGesture attentionLostEventMask AttentionLost|Button|Keyboard|Digitizer|Pointer|GameController|MesaTouch|GenericGesture tagIndex 111), old config <AWRemoteClient: 0x12be18a20> (identifier: com.apple.springboard.GlobalBacklightIdleTimer samplingInterval:       4.00000 samplingDelay:      84.00000 sampleWhileAbsent: false attentionLostTimeouts: 100, 102, 120 notificationMask NONE mask AttentionLost|Button|Keyboard|Digitizer|Pointer|GameController|FaceDetect|MesaTouch|GenericGesture attentionLostEventMask AttentionLost|Button|Keyboard|Digitizer|Pointer|GameController|MesaTouch|GenericGesture tagIndex 110)
Nov 12 12:24:37 iPad runningboardd(RunningBoard)[31] <Notice>: Finished acquiring assertion 31-510-1702 (target:[application<com.REDACTED>:796])
Nov 12 12:24:37 iPad runningboardd(RunningBoard)[31] <Notice>: Calculated state for application<com.REDACTED>: running-active (role: UserInteractiveNonFocal)
Nov 12 12:24:37 iPad SpringBoard(IdleTimerHosting)[510] <Notice>: <0x2827e5740> - reconfigure attention client with configuration:<AWAttentionAwarenessConfiguration: 0x28162c310> (identifier: com.apple.springboard.GlobalBacklightIdleTimer samplingInterval:       4.00000 samplingDelay:      84.00000 sampleWhileAbsent: false attentionLostTimeouts:     102.00000,     100.00000,     120.00000 notificationMask NONE mask Button|Keyboard|Digitizer|Pointer|GameController|FaceDetect|MesaTouch|GenericGesture attentionLostEventMask Button|Keyboard|Digitizer|Pointer|GameController|MesaTouch|GenericGesture tagIndex 111 (tag <ITAttentionAwarenessContext: 0x283f8ab30>))
Nov 12 12:24:37 iPad SpringBoard(FrontBoard)[510] <Notice>: [sceneID:com.REDACTED-default] Scene lifecycle state did change: Foreground
Nov 12 12:24:37 iPad SpringBoard(FrontBoard)[510] <Notice>: [sceneID:com.REDACTED-default] Scene assertion state did change: ForegroundActive.
Nov 12 12:24:37 iPad SpringBoard(FrontBoard)[510] <Notice>: [application<com.REDACTED>:796] Launch assertion supersedes update of workspace assertion to ForegroundActive.
Nov 12 12:24:37 iPad SpringBoard(FrontBoard)[510] <Notice>: [application<com.REDACTED>:796] Workspace assertion state did change: ForegroundActive (acquireAssertion = NO).
Nov 12 12:24:37 iPad SpringBoard(SpringBoardHome)[510] <Notice>: Icon touch canceled (tap gesture may still succeed): <private>
Nov 12 12:24:37 iPad dmd[479] <Notice>: Update foreground bundle identifiers
Nov 12 12:24:37 iPad contextstored(BiomeStreams)[57] <Notice>: Received connection request for BMFileAccessService from pid 57
Nov 12 12:24:37 iPad symptomsd(SymptomEvaluator)[123] <Notice>: com.REDACTED: Foreground: true
Nov 12 12:24:37 iPad symptomsd(WiFiAnalytics)[123] <Notice>: -[WAClient _wakeUpNotificationForThisClientReceived:]_block_invoke::974:XPC: Received 'wake up' notification, but this client has no indication the connection is dead (daemonConnectionValid == true). Not starting connection recovery
Nov 12 12:24:37 iPad SpringBoard(SpringBoard)[510] <Notice>: Application process state changed for com.REDACTED: <SBApplicationProcessState: 0x283cd8fa0; pid: 796; taskState: Running; visibility: Foreground>
Nov 12 12:24:37 iPad SpringBoard(SpringBoard)[510] <Notice>: Application process state changed for com.REDACTED: <SBApplicationProcessState: 0x283cd80a0; pid: 796; taskState: Running; visibility: Foreground>
Nov 12 12:24:37 iPad SpringBoard(SpringBoard)[510] <Notice>: didSelectKeyboardFocusProcess:<FBApplicationProcess: 0x1047b0da0; application<com.REDACTED>:796(v871)> token:(null)
Nov 12 12:24:37 iPad SpringBoard(SpringBoard)[510] <Notice>: updateKeyboardFocusDeferringRules: app focus pid:796 token:(null)
Nov 12 12:24:37 iPad backboardd(BackBoardHIDEventFoundation)[61] <Notice>: new deferring rules for pid:510: [    <environment: system> -> <pid: 510; token: 0x15718FD7> reason: "1-deferDiscrete: systemGestures",
<environment: keyboardFocus; display: builtin> -> <pid: 510; token: 0x5D484C4> reason: "132-deferDiscrete: Key Window event focus deferral",
<environment: keyboardFocus; display: builtin> -> <pid: 796> reason: "133-deferDiscrete: SpringBoardToApp",
<environment: keyboardFocus; display: builtin; token: 0x5D484C4> -> <pid: 796> reason: "134-deferDiscrete: SpringBoardToAppCompatibility"
]
Nov 12 12:24:37 iPad backboardd(BackBoardHIDEventFoundation)[61] <Notice>: new resolutions for pid:510 (    <display: null; environment: system; pid: 510; token: 0x15718FD7>,
<display: builtin; environment: cameraButton; pid: 510>
)
Nov 12 12:24:37 iPad backboardd(BackBoardHIDEventFoundation)[61] <Notice>: new resolutions for pid:796 (<display: builtin; environment: keyboardFocus; pid: 796>)
Nov 12 12:24:37 iPad chronod(ChronoCore)[222] <Notice>: noting foreground launch for com.REDACTED with widget extension; trigger metadata query
Nov 12 12:24:37 iPad locationd[64] <Notice>: Recording parameters: localize: <private>, record: <private>
Nov 12 12:24:37 iPad locationd[64] <Notice>: Recording is blacked out
Nov 12 12:24:37 iPad dasd[113] <Notice>: Trigger: <private> is now [<private>]
Nov 12 12:24:37 iPad dasd[113] <Notice>: Foreground apps changed\M-b\M^@\M^T-<private>
Nov 12 12:24:37 iPad symptomsd(SymptomEvaluator)[123] <Notice>: Failed to find process for com.REDACTED
Nov 12 12:24:37 iPad kernel(Sandbox)[0] <Error>: Sandbox: REDACTED(796) deny(2) file-test-existence /usr/bin/gdb
Nov 12 12:24:37 iPad kernel(Sandbox)[0] <Error>: Sandbox: REDACTED(796) deny(2) file-test-existence /bin/gdb
Nov 12 12:24:37 iPad kernel(Sandbox)[0] <Error>: Sandbox: REDACTED(796) deny(2) file-test-existence /sbin/gdb
Nov 12 12:24:37 iPad kernel(Sandbox)[0] <Error>: Sandbox: REDACTED(796) deny(2) file-test-existence /usr/bin/lldb
Nov 12 12:24:37 iPad kernel(Sandbox)[0] <Error>: Sandbox: REDACTED(796) deny(2) file-test-existence /bin/lldb
Nov 12 12:24:37 iPad kernel(Sandbox)[0] <Error>: Sandbox: REDACTED(796) deny(2) file-test-existence /sbin/lldb
Nov 12 12:24:38 iPad SpringBoard(SpringBoard)[510] <Notice>: [Main] dispatch event:<SBTimerSwitcherModifierEvent: 0x283cdc1c0; type: Timer; reason: kSBIconZoomDisallowAcceleratedHomeButtonPressReason>
Nov 12 12:24:38 iPad SpringBoard(SpringBoard)[510] <Notice>: [Main] dispatch event:<SBTimerSwitcherModifierEvent: 0x283cfdbe0; type: Timer; reason: kSBTransitionModifierInvalidateAsyncRenderingReason>
Nov 12 12:24:38 iPad SpringBoard(UIKitCore)[510] <Notice>: Added: <UIApplicationSceneDeactivationAssertion: 0x283188a20; reason: systemGesture; all scene levels; hasPredicate: YES>
Nov 12 12:24:38 iPad SpringBoard(UIKitCore)[510] <Notice>: Removed: <UIApplicationSceneDeactivationAssertion: 0x283190a50; reason: systemAnimation; all scene levels; hasPredicate: NO>
Nov 12 12:24:38 iPad SpringBoard(UIKitCore)[510] <Notice>: [sceneID:com.REDACTED-default] Setting deactivation reasons to: '(none)' for reason: updateAllScenesForBand - Assertion removed.
Nov 12 12:24:38 iPad SpringBoard(SpringBoard)[510] <Notice>: [Main] dispatch event:<SBMainTransitionSwitcherModifierEvent: 0x280683190; type: MainTransition; transitionID: B6E5D56D-561B-4C24-9D4D-4F152E2236C2; phase: Complete; animated: YES; fromAppLayout: 0x0; toAppLayout: <SBAppLayout: 0x282724780; primary: com.REDACTED; environment: main>; fromEnvironmentMode: home-screen; toEnvironmentMode: application; pendingTermination: {(
)}>
Nov 12 12:24:38 iPad SpringBoard(SpringBoard)[510] <Notice>: [Main] handle response:<SBSwitcherModifierEventResponse: 0x283199e00> {
<SBPreemptAnimationSwitcherEventResponse: 0x28319b060>;
<SBSwitcherModifierEventResponse: 0x28319a940> {
        <SBInvalidateAdjustedAppLayoutsSwitcherEventResponse: 0x2831986c0>;
        <SBSwitcherModifierEventResponse: 0x283198c90> {
            <SBRequestFolderSnapshotsSwitcherEventResponse: 0x283198bd0; snapshotRequested: NO>;
            <SBIconOverlayVisibilitySwitcherEventResponse: 0x2828a2a00; visible: NO; appLayout: <SBAppLayout: 0x282724780; primary: com.REDACTED; environment: main>>;
            <SBIconViewVisibilitySwitcherEventResponse: 0x281e63d90; visible: YES; animationSettings: 0x0; appLayout: <SBAppLayout: 0x282724780; primary: com.REDACTED; environment: main>>;
            <SBMatchMoveToIconViewSwitcherEventResponse: 0x2828a84c0; active: NO; appLayout: <SBAppLayout: 0x282724780; primary: com.REDACTED; environment: main>>;
        };
    };
}
Nov 12 12:24:38 iPad SpringBoard(UIKitCore)[510] <Notice>: Removed: <UIApplicationSceneDeactivationAssertion: 0x283188a20; reason: systemGesture; all scene levels; hasPredicate: NO>
Nov 12 12:24:38 iPad SpringBoard(SpringBoard)[510] <Notice>: End requiring home screen content for reason 'SBGridSwitcherViewController-0x1050aaa00-Main'
Nov 12 12:24:38 iPad useractivityd(Sharing)[512] <Notice>: client process changing types to scan for to Handoff, CopyPaste
Nov 12 12:24:38 iPad SpringBoard(SpringBoard)[510] <Notice>: Ignoring interaction events for reason: default -- count: 1
Nov 12 12:24:38 iPad sharingd[531] <Notice>: Skipping request for enabled: YES, state: PoweredOff, shouldStart: YES, scanForCopyPaste: YES, scanForHandoff: YES
Nov 12 12:24:38 iPad SpringBoard(SpringBoard)[510] <Notice>: Ending ignoring interaction events for reason: default -- new count: 0
Nov 12 12:24:38 iPad backboardd(AttentionAwareness)[61] <Notice>:              EventStatistics.m:48  :   10362.56828:  Info: 2 Digitizer since   10129.81967 (Thu Nov 12 12:20:45 2020)
Nov 12 12:24:38 iPad SpringBoard(CoreMotion)[510] <Notice>: [CLIoHidInterface] Property for usage pair {65280, 9}: {GyroProperties = {    GyroFactoryMode = 0;
GyroMeasurementRange = 2000;
GyroXAxisOffset = 0;
GyroYAxisOffset = 0;
GyroZAxisOffset = 0;
}} was set successfully
Nov 12 12:24:38 iPad backboardd(IOKit)[61] <Notice>: 0x100000474: set report interval:1000000 client:D36BA427-3397-4858-B96C-6A99F62AD918
Nov 12 12:24:38 iPad SpringBoard(CoreMotion)[510] <Notice>: [CLIoHidInterface] Property for usage pair {65280, 9}: {ReportInterval = 1000000} was set successfully
Nov 12 12:24:38 iPad SpringBoard(CoreMotion)[510] <Notice>: [CLIoHidInterface] Property for usage pair {65280, 9}: {GyroExtLevelTriggerSync = 0} was set successfully
Nov 12 12:24:38 iPad backboardd(IOKit)[61] <Notice>: 0x100000474: set batch interval:15000 client:D36BA427-3397-4858-B96C-6A99F62AD918
Nov 12 12:24:38 iPad SpringBoard(CoreMotion)[510] <Notice>: [CLIoHidInterface] Property for usage pair {65280, 9}: {BatchInterval = 15000} was set successfully
Nov 12 12:24:38 iPad SpringBoard(CoreMotion)[510] <Notice>: [CLIoHidInterface] Property for usage pair {65280, 9}: {GyroProperties = {    GyroFactoryMode = 0;
GyroMeasurementRange = 2000;
GyroXAxisOffset = 0;
GyroYAxisOffset = 0;
GyroZAxisOffset = 0;
}} was set successfully
Nov 12 12:24:38 iPad backboardd(IOKit)[61] <Notice>: 0x100000474: set report interval:0 client:D36BA427-3397-4858-B96C-6A99F62AD918
Nov 12 12:24:38 iPad SpringBoard(CoreMotion)[510] <Notice>: [CLIoHidInterface] Property for usage pair {65280, 9}: {ReportInterval = 0} was set successfully
Nov 12 12:24:38 iPad SpringBoard(CoreMotion)[510] <Notice>: [CLIoHidInterface] Property for usage pair {65280, 9}: {GyroExtLevelTriggerSync = 0} was set successfully
Nov 12 12:24:38 iPad backboardd(IOKit)[61] <Notice>: 0x100000474: set batch interval:15000 client:D36BA427-3397-4858-B96C-6A99F62AD918
Nov 12 12:24:38 iPad SpringBoard(CoreMotion)[510] <Notice>: [CLIoHidInterface] Property for usage pair {65280, 9}: {BatchInterval = 15000} was set successfully
Nov 12 12:24:38 iPad SpringBoard(CoreMotion)[510] <Notice>: {"msg":"CLGyroBiasEstimatorClientRemote::unregisterWithGyroBiasEstimatorPrivate", "event":"activity", "client":"0x283d91600"}
Nov 12 12:24:38 iPad locationd(LocationSupport)[64] <Notice>: #Warning Location connection invalid!
Nov 12 12:24:38 iPad locationd(LocationSupport)[64] <Notice>: {"msg":"CLConnection::handleDisconnection", "event":"activity"}
Nov 12 12:24:38 iPad locationd[64] <Notice>: Client com.apple.springboard disconnected
Nov 12 12:24:38 iPad locationd[64] <Notice>: os_transaction released: (<private>) <private>
Nov 12 12:24:38 iPad locationd[64] <Notice>: CLGyroBiasEstimator,SPUEnabled,0,BuildingGYTT,0,NumClients,0
Nov 12 12:24:38 iPad locationd[64] <Notice>: {"msg":"state transition", "event":"state_transition", "state":"DaemonClient", "id":"0x1025768c0", "property":"lifecycle", "old":"0x1025768c0", "new":"0x0"}
Nov 12 12:24:38 iPad locationd[64] <Notice>: MotionCoprocessor,startTime,626894679.087704,motionType,2,youthType,0,youthTypeReason,0
Nov 12 12:24:39 iPad dasd[113] <Notice>: Attempting to suspend based on triggers: (     "com.apple.das.apppolicy.appchanged" )
Nov 12 12:24:39 iPad dasd[113] <Notice>: Recent Applications: <private>
Nov 12 12:24:39 iPad dasd[113] <Notice>: Evaluating 5 activities based on triggers
Nov 12 12:24:39 iPad dasd[113] <Notice>: com.apple.cloudphotod.sync.discretionary-when-background:5C4BBB:[  {name: NetworkQualityPolicy, policyWeight: 11.400, response: {Decision: Absolutely Must Not Proceed, Score: 0.00, Rationale: [{[networkPathAvailability]: Required:1.00, Observed:0.00},]}}
], FinalDecision: Absolutely Must Not Proceed}
Nov 12 12:24:40 iPad sharingd(CoreUtils)[531] <Notice>: Activity level changed 7 (Screen) -> 11 (User)
Nov 12 12:24:40 iPad sharingd(CoreUtils)[531] <Notice>: NearbyInfo sending activity level, original: 0xb encrypted:0xa
Nov 12 12:24:41 iPad locationd[64] <Notice>: MotionCoprocessor,startTime,626894681.656119,motionType,2,youthType,0,youthTypeReason,0
Nov 12 12:24:41 iPad locationd[64] <Notice>: MotionCoprocessor,startTime,626894681.973073,motionType,1,youthType,0,youthTypeReason,0
Nov 12 12:24:41 iPad locationd[64] <Notice>: os_transaction created: (<private>) <private>
Nov 12 12:24:41 iPad locationd[64] <Notice>: @WifiLogic, handleInput, System::CoarseMotion
Nov 12 12:24:41 iPad locationd[64] <Notice>: {"msg":"got motion state notification", "subHarvester":"Avenger"}
Nov 12 12:24:41 iPad locationd[64] <Notice>: {"msg":"updated avenger harvester motion activity state", "fLastMotionActivity":2, "nextMotionActivity":1, "subHarvester":"Avenger"}
Nov 12 12:24:41 iPad locationd[64] <Notice>: {"msg":"updateOperationalModeIfNecessary", "fIsAllowedToUseBest":0, "fCurrentTimeOffsetThreshold":"45.000000", "subHarvester":"Avenger"}
Nov 12 12:24:41 iPad locationd[64] <Notice>: {"msg":"CLWifi1SystemLogic::apply", "event":"elapsed", "begin_mach":248772883863, "end_mach":248772985094, "elapsed_s":"0.004217958", "event":"System::CoarseMotion", "now_s":"626894681.510658979"}
Nov 12 12:24:41 iPad locationd[64] <Notice>: os_transaction releasing: (<private>) <private>
Nov 12 12:24:41 iPad locationd[64] <Notice>: {"msg":"got motion state notification", "subHarvester":"Avenger"}
Nov 12 12:24:41 iPad locationd[64] <Notice>: {"msg":"updated avenger harvester motion activity state", "fLastMotionActivity":1, "nextMotionActivity":2, "subHarvester":"Avenger"}
Nov 12 12:24:41 iPad locationd[64] <Notice>: {"msg":"updateOperationalModeIfNecessary", "fIsAllowedToUseBest":0, "fCurrentTimeOffsetThreshold":"45.000000", "subHarvester":"Avenger"}
Nov 12 12:24:42 iPad wifid(WiFiPolicy)[49] <Notice>: WiFiDeviceSetProperty: ERROR: Setting reg entry key IO80211InterfaceHeartBeat failed e00002d8
Nov 12 12:24:43 iPad duetexpertd(AppPredictionInternal)[568] <Notice>: Last app launch was the homescreen. Not going to process donations for previous app session end.
Nov 12 12:24:43 iPad duetexpertd(ProactiveContextClient)[568] <Notice>: Attempting to update location of interest since update age is 33.058880
Nov 12 12:24:43 iPad duetexpertd(CoreLocation)[568] <Notice>: {"msg":"CLLocationManager", "event":"activity", "_cmd":"location", "self":"0x102b199b0"}
Nov 12 12:24:43 iPad locationd[64] <Notice>: {"msg":"client getting effective client name", "bundleId":"", "bundlePath":"\134/System\134/Library\134/PrivateFrameworks\134/CoreParsec.framework"}
Nov 12 12:24:43 iPad duetexpertd(ProactiveContextClient)[568] <Notice>: Querying GPS location now, requesting with precise location: NO
Nov 12 12:24:43 iPad duetexpertd(CoreLocation)[568] <Notice>: {"msg":"CLLocationManager", "event":"activity", "_cmd":"setDesiredAccuracy:", "self":"0x102b199b0", "accuracy":"100.000000"}
Nov 12 12:24:43 iPad duetexpertd(CoreLocation)[568] <Notice>: {"msg":"state transition", "event":"state_transition", "state":"LocationManager", "id":"0x102b199b0", "property":"desiredAccuracy", "old":"100.000000", "new":"100.000000"}
Nov 12 12:24:43 iPad duetexpertd(CoreLocation)[568] <Notice>: {"msg":"CLLocationManager", "event":"activity", "_cmd":"requestLocation", "self":"0x102b199b0"}
Nov 12 12:24:43 iPad duetexpertd(CoreLocation)[568] <Notice>: {"msg":"state transition", "event":"state_transition", "state":"LocationManager", "id":"0x102b199b0", "property":"requestingLocation", "old":0, "new":1}
Nov 12 12:24:43 iPad locationd[64] <Notice>: {"msg":"Incoming message", "event":"activity", "name":"kCLConnectionMessageLocation", "this":"0x1022cc9c0", "registrationReceived":1}
Nov 12 12:24:43 iPad locationd[64] <Notice>: Client /System/Library/PrivateFrameworks/CoreParsec.framework (0x1022cc9c0) is subscribing to notification kCLConnectionMessageLocation
Nov 12 12:24:43 iPad locationd[64] <Notice>: Client /System/Library/PrivateFrameworks/CoreParsec.framework (0x1022cc9c0) is subscribing to notification kCLConnectionMessageLocationUnavailable
Nov 12 12:24:43 iPad locationd[64] <Notice>: client '/System/Library/PrivateFrameworks/CoreParsec.framework' authorized for location; starting shortly
Nov 12 12:24:43 iPad locationd[64] <Notice>: client '/System/Library/PrivateFrameworks/CoreParsec.framework' authorized for location; starting now, desiredAccuracy, 100.0, distanceFilter, -1.0, operatingMode 0, dynamicAccuracyReductionEnabled 0, allowsAlteredAccessoryLocations 0, activityType 0
Nov 12 12:24:43 iPad locationd[64] <Notice>: @ClxClient, register, /System/Library/PrivateFrameworks/CoreParsec.framework, accuracy, 100.0
Nov 12 12:24:43 iPad locationd[64] <Notice>: #Warning Denying process assertion to <private>
Nov 12 12:24:43 iPad locationd[64] <Notice>: os_transaction created: (<private>) <private>
Nov 12 12:24:43 iPad locationd[64] <Notice>: @ClxClient, accuracy, 0, 1, 0, level, Fine, reg?, 1
Nov 12 12:24:43 iPad locationd[64] <Notice>: {"msg":"#Stream Client interest changed", "notification":"CLLocationProvider_Type::kNotificationLocationFine", "is interested":1}
Nov 12 12:24:43 iPad locationd[64] <Notice>: {"msg":"#Stream Starting location for source", "source":"CLStreamingAwareLocationProviderStateMachine::kLocationSourceLocal", "notification":"CLLocationProvider_Type::kNotificationLocationFine", "include motion":0}
Nov 12 12:24:43 iPad locationd[64] <Notice>: @ClxProvider, start, wifi, desiredAccuracy, 100.0
Nov 12 12:24:43 iPad locationd[64] <Notice>: WlpReg, 1, loccontroller
Nov 12 12:24:43 iPad locationd[64] <Notice>: @ClxProvider, start, simulated, desiredAccuracy, 100.0
Nov 12 12:24:43 iPad locationd[64] <Notice>: #techstatus,signalling
Nov 12 12:24:43 iPad locationd[64] <Notice>: @WifiLogic, entry, register, notification, Location, lsb, 1, 1, 1
Nov 12 12:24:43 iPad locationd[64] <Notice>: #techstatus,posting notification
Nov 12 12:24:43 iPad locationd[64] <Notice>: os_transaction created: (<private>) <private>
Nov 12 12:24:43 iPad locationd[64] <Notice>: {"msg":"Sending location to client", "client":"\134/System\134/Library\134/PrivateFrameworks\134/CoreParsec.framework", "location":<private>}
Nov 12 12:24:43 iPad locationd[64] <Notice>: @WifiLogic, handleInput, Client::Registration
Nov 12 12:24:43 iPad symptomsd(CoreLocation)[123] <Notice>: {"msg":"CLCopyTechnologiesInUse", "event":"activity"}
Nov 12 12:24:43 iPad locationd[64] <Notice>: #techstatus,enquired,sz,2,gpsClientActive,0,gpsHwActive,0
Nov 12 12:24:43 iPad aggregated(CoreLocation)[70] <Notice>: {"msg":"CLCopyTechnologiesInUse", "event":"activity"}
Nov 12 12:24:43 iPad locationd[64] <Notice>: {"msg":"CLWifi1SystemLogic::apply", "event":"elapsed", "begin_mach":248811791834, "end_mach":248811855894, "elapsed_s":"0.002669167", "event":"Client::Registration", "now_s":"626894683.131734967"}
Nov 12 12:24:43 iPad locationd[64] <Notice>: #techstatus,enquired,sz,2,gpsClientActive,0,gpsHwActive,0
Nov 12 12:24:43 iPad locationd[64] <Notice>: @WifiFlow, outcome, nofix
Nov 12 12:24:43 iPad locationd[64] <Notice>: @ClxWifi, Fix, 0, ll, N/A
Nov 12 12:24:43 iPad locationd[64] <Notice>: os_transaction releasing: (<private>) <private>
Nov 12 12:24:43 iPad locationd[64] <Notice>: {"msg":"#sbim client arrow state changed", "clientKey":"com.apple.locationd.bundle-\134/System\134/Library\134/PrivateFrameworks\134/CoreParsec.framework", "entityClass":"SystemService", "oldArrowState":"RequestingLocationInformation", "newArrowState":"ReceivingLocationInformation", "dueToDeauthorization":0}
Nov 12 12:24:43 iPad locationd[64] <Notice>: {"msg":"#sbim entity class arrow state changed", "entityClass":"SystemService", "oldArrowState":"RequestingLocationInformation", "newArrowState":"ReceivingLocationInformation", "dueToDeauthorization":0}
Nov 12 12:24:43 iPad locationd[64] <Notice>: {"msg":"#Stream Received notification", "notification":"CLLocationProvider_Type::kNotificationLocationUnavailable"}
Nov 12 12:24:43 iPad locationd[64] <Notice>: {"msg":"#Stream Source no longer available", "source":"CLStreamingAwareLocationProviderStateMachine::kLocationSourceLocal"}
Nov 12 12:24:43 iPad locationd[64] <Notice>: {"msg":"#Stream Starting location for source", "source":"CLStreamingAwareLocationProviderStateMachine::kLocationSourceLocal", "notification":"CLLocationProvider_Type::kNotificationLocationFine", "include motion":0}
Nov 12 12:24:43 iPad wifid(CoreLocation)[49] <Notice>: {"msg":"#CLLocationManager invoking #delegate - location unavailable", "self":"0x131e12900", "delegate":"0x131e12d60", "selector":"locationManager:didFailWithError:"}
Nov 12 12:24:43 iPad wifid(WiFiPolicy)[49] <Notice>: -[WiFiLocationManager locationManager:didFailWithError:]: error: Error Domain=kCLErrorDomain Code=0 "(null)"
Nov 12 12:24:43 iPad destinationd(CoreLocation)[209] <Notice>: {"msg":"#CLLocationManager invoking #delegate - location unavailable", "self":"0x101204190", "delegate":"0x101106200", "selector":"locationManager:didFailWithError:"}
Nov 12 12:24:43 iPad navd(CoreLocation)[599] <Notice>: {"msg":"#CLLocationManager invoking #delegate - location unavailable", "self":"0x10020fa20", "delegate":"0x10020fe10", "selector":"locationManager:didFailWithError:"}
Nov 12 12:24:43 iPad navd[599] <Error>: <private> failed while leeching with error: <private>
Nov 12 12:24:43 iPad locationd[64] <Notice>: MotionCoprocessor,startTime,626894684.219326,motionType,1,youthType,0,youthTypeReason,0
Nov 12 12:24:45 iPad locationd[64] <Notice>: {"msg":"adapter details", "adapterDescription":"usb host", "batteryChargerType":"kChargerTypeUsb", "level":100, "family":3758112777, "fullyCharged":1}
Nov 12 12:24:45 iPad wifid(WiFiPolicy)[49] <Notice>: manager->wow.lpasSetting 1 CFSetGetCount(manager->wow.wowClients) 1 isWowActivityRegistered=0 manager->wow.overrideWoWState 0 manager->externalPower 1 manager->iokit.battery.chargeLevel 100
Nov 12 12:24:45 iPad wifid(WiFiPolicy)[49] <Notice>: WiFiDeviceSetProperty: ERROR: Setting reg entry key IO80211InterfaceExternelPowerState failed e00002d8
Nov 12 12:24:45 iPad wifid(WiFiPolicy)[49] <Notice>: Posting metrics for AJ
Nov 12 12:24:45 iPad wifid(WiFiPolicy)[49] <Notice>: External power state is 1
Nov 12 12:24:45 iPad UserEventAgent(IOAccessoryManager)[28] <Notice>: handle battery state update: isExtChg=1->1, enableHalogenMitigationsAndUI 1
Nov 12 12:24:45 iPad wifid(WiFiPolicy)[49] <Notice>: External power state is same as before 1, bailing out
Nov 12 12:24:45 iPad symptomsd(SymptomEvaluator)[123] <Notice>: Power: battery-percentage 100.00 battery-power-connected 1 battery-charging 0 battery-warn 0 battery-critical 0
Nov 12 12:24:45 iPad backboardd[61] <Notice>: touch (main) events starting 8.07344s ago: [    down: 1,
up: 1,
recentHitTestContexts: [<touchID: 0xEA; contextID: 0xA872C3A8; pid: 510>]
]
Nov 12 12:24:45 iPad sharingd(CoreUtils)[531] <Notice>: NearbyInfo sending activity level, original: 0xb encrypted:0xa
Nov 12 12:24:46 iPad locationd[64] <Notice>: MotionCoprocessor,startTime,626894686.782955,motionType,1,youthType,0,youthTypeReason,0
Nov 12 12:24:48 iPad duetexpertd(ProactiveContextClient)[568] <Notice>: Timeout waiting for location update
Nov 12 12:24:48 iPad duetexpertd(CoreLocation)[568] <Notice>: {"msg":"CLLocationManager", "event":"activity", "_cmd":"location", "self":"0x102b199b0"}
Nov 12 12:24:48 iPad locationd[64] <Notice>: {"msg":"client getting effective client name", "bundleId":"", "bundlePath":"\134/System\134/Library\134/PrivateFrameworks\134/CoreParsec.framework"}
Nov 12 12:24:48 iPad locationd[64] <Notice>: {"msg":"Incoming message", "event":"activity", "name":"kCLConnectionMessageMotionActivityQuery", "this":"0x1026e3580", "registrationReceived":0}
Nov 12 12:24:48 iPad locationd[64] <Notice>: os_transaction created: (<private>) <private>
Nov 12 12:24:48 iPad locationd[64] <Notice>: os_transaction releasing: (<private>) <private>
Nov 12 12:24:48 iPad duetexpertd(ProactiveContextClient)[568] <Notice>: Current motion activities: <private>
Nov 12 12:24:48 iPad duetexpertd(CoreLocation)[568] <Notice>: {"msg":"CLLocationManager", "event":"activity", "_cmd":"location", "self":"0x102b199b0"}
Nov 12 12:24:48 iPad locationd[64] <Notice>: {"msg":"client getting effective client name", "bundleId":"", "bundlePath":"\134/System\134/Library\134/PrivateFrameworks\134/CoreParsec.framework"}
Nov 12 12:24:48 iPad apsd(PersistentConnection)[143] <Notice>: SimpleTimer <PCSimpleTimer: 0x104e329e0> has fired
Nov 12 12:24:48 iPad apsd(PersistentConnection)[143] <Notice>: Invalidating simple timer <PCSimpleTimer: 0x104e329e0>
Nov 12 12:24:48 iPad apsd(PersistentConnection)[143] <Notice>: Disabling power monitoring for <PCSimpleTimer: 0x104e329e0> - 3 timers
Nov 12 12:24:48 iPad symptomsd(WiFiAnalytics)[123] <Notice>: -[WAClient _wakeUpNotificationForThisClientReceived:]_block_invoke::974:XPC: Received 'wake up' notification, but this client has no indication the connection is dead (daemonConnectionValid == true). Not starting connection recovery
Nov 12 12:24:48 iPad runningboardd(RunningBoard)[31] <Notice>: Assertion did invalidate due to timeout: 31-31-1700 (target:[application<com.REDACTED>:796])
Nov 12 12:24:48 iPad runningboardd(RunningBoard)[31] <Notice>: Attempting to rename power assertion 38172 for target application<com.REDACTED> to application<com.REDACTED>31-510-1699:FBApplicationProcess
Nov 12 12:24:48 iPad runningboardd(RunningBoard)[31] <Notice>: Calculated state for application<com.REDACTED>: running-active (role: UserInteractiveNonFocal)
Nov 12 12:24:48 iPad locationd[64] <Notice>: MotionCoprocessor,startTime,626894689.345704,motionType,1,youthType,0,youthTypeReason,0
Nov 12 12:24:49 iPad akd(Accounts)[492] <Notice>: "The connection to ACDAccountStore was invalidated."
Nov 12 12:24:51 iPad sharingd(CoreUtils)[531] <Notice>: NearbyInfo sending activity level, original: 0xb encrypted:0xa
Nov 12 12:24:51 iPad locationd[64] <Notice>: MotionCoprocessor,startTime,626894691.909009,motionType,1,youthType,0,youthTypeReason,0
Nov 12 12:24:53 iPad duetexpertd(CoreLocation)[568] <Notice>: {"msg":"CLLocationManager", "event":"activity", "_cmd":"onLocationRequestTimeout", "self":"0x102b199b0"}
Nov 12 12:24:53 iPad duetexpertd(CoreLocation)[568] <Notice>: {"msg":"state transition", "event":"state_transition", "state":"LocationManager", "id":"0x102b199b0", "property":"requestingLocation", "old":1, "new":0}
Nov 12 12:24:53 iPad duetexpertd(CoreLocation)[568] <Notice>: {"msg":"#CLLocationManager invoking #delegate - request timeout", "self":"0x102b199b0", "delegate":"0x102b19960", "selector":"locationManager:didUpdateLocations:", "location":<private>}
Nov 12 12:24:53 iPad duetexpertd(CoreLocation)[568] <Notice>: {"msg":"CLLocationManager", "event":"activity", "_cmd":"location", "self":"0x102b199b0"}
Nov 12 12:24:53 iPad locationd[64] <Notice>: {"msg":"Incoming message", "event":"activity", "name":"kCLConnectionMessageLocation", "this":"0x1022cc9c0", "registrationReceived":1}
Nov 12 12:24:53 iPad locationd[64] <Notice>: Client /System/Library/PrivateFrameworks/CoreParsec.framework (0x1022cc9c0) is unsubscribing to notification kCLConnectionMessageLocation
Nov 12 12:24:53 iPad locationd[64] <Notice>: {"msg":"client getting effective client name", "bundleId":"", "bundlePath":"\134/System\134/Library\134/PrivateFrameworks\134/CoreParsec.framework"}
Nov 12 12:24:53 iPad locationd[64] <Notice>: Client /System/Library/PrivateFrameworks/CoreParsec.framework (0x1022cc9c0) is unsubscribing to notification kCLConnectionMessageLocationUnavailable
Nov 12 12:24:53 iPad locationd[64] <Notice>: client '/System/Library/PrivateFrameworks/CoreParsec.framework' unsubscribing from location
Nov 12 12:24:53 iPad locationd[64] <Notice>: @ClxClient, unsubscribe, /System/Library/PrivateFrameworks/CoreParsec.framework
Nov 12 12:24:53 iPad locationd[64] <Notice>: #Warning Denying process assertion to <private>
Nov 12 12:24:53 iPad locationd[64] <Notice>: os_transaction released: (<private>) <private>
Nov 12 12:24:53 iPad duetexpertd(AppPredictionInternal)[568] <Notice>: Unexpected NULL isEnterpriseApp for bundleId: com.apple.DEC.AppPredictionInternal.backlightActivated
Nov 12 12:24:53 iPad locationd[64] <Notice>: @ClxClient, accuracy, 0, 0, 0, level, None, reg?, 0
Nov 12 12:24:53 iPad locationd[64] <Notice>: {"msg":"#Stream Client interest changed", "notification":"CLLocationProvider_Type::kNotificationLocationFine", "is interested":0}
Nov 12 12:24:53 iPad locationd[64] <Notice>: {"msg":"#Stream Stopping location for source", "source":"CLStreamingAwareLocationProviderStateMachine::kLocationSourceLocal"}
Nov 12 12:24:53 iPad locationd[64] <Notice>: @ClxProvider, stop, <private>, desiredAccuracy, -1.0
Nov 12 12:24:53 iPad locationd[64] <Notice>: WlpReg, 0, loccontroller
Nov 12 12:24:53 iPad locationd[64] <Notice>: @ClxProvider, stop, <private>, desiredAccuracy, -1.0
Nov 12 12:24:53 iPad locationd[64] <Notice>: @WifiLogic, entry, unregister, notification, Location, lsb, 0, 1, 1
Nov 12 12:24:53 iPad locationd[64] <Notice>: #techstatus,signalling
Nov 12 12:24:53 iPad locationd[64] <Notice>: @WifiEntry, unregister for odometer notification
Nov 12 12:24:53 iPad locationd[64] <Notice>: os_transaction created: (<private>) <private>
Nov 12 12:24:53 iPad locationd[64] <Notice>: @WifiLogic, handleInput, Client::Unregistration
Nov 12 12:24:53 iPad locationd[64] <Notice>: #techstatus,posting notification
Nov 12 12:24:53 iPad symptomsd(CoreLocation)[123] <Notice>: {"msg":"CLCopyTechnologiesInUse", "event":"activity"}
Nov 12 12:24:53 iPad locationd[64] <Notice>: #techstatus,enquired,sz,0,gpsClientActive,0,gpsHwActive,0
Nov 12 12:24:53 iPad locationd[64] <Notice>: {"msg":"CLWifi1SystemLogic::apply", "event":"elapsed", "begin_mach":249051780921, "end_mach":249051864702, "elapsed_s":"0.003490875", "event":"Client::Unregistration", "now_s":"626894693.130777001"}
Nov 12 12:24:53 iPad locationd[64] <Notice>: @WifiFlow, nexttimer, off
Nov 12 12:24:53 iPad aggregated(CoreLocation)[70] <Notice>: {"msg":"CLCopyTechnologiesInUse", "event":"activity"}
Nov 12 12:24:53 iPad locationd[64] <Notice>: os_transaction releasing: (<private>) <private>
Nov 12 12:24:53 iPad locationd[64] <Notice>: #techstatus,enquired,sz,0,gpsClientActive,0,gpsHwActive,0
Nov 12 12:24:53 iPad duetexpertd(AppPredictionInternal)[568] <Notice>: ATXUpdatePredictions: cache age 450.000000, reason app launch
Nov 12 12:24:53 iPad duetexpertd(AppPredictionInternal)[568] <Notice>: <private> - -[ATXUpdatePredictionsManager disabledConsumerSubTypesWithHomeScreenPageConfigs:]: <private>
Nov 12 12:24:53 iPad duetexpertd(AppPredictionInternal)[568] <Notice>: The prediction cache seems valid and was refreshed 283.25 seconds ago (450.00 second refresh rate) at path: <private>
Nov 12 12:24:53 iPad duetexpertd(AppPredictionInternal)[568] <Notice>: The prediction cache seems valid and was refreshed 283.39 seconds ago (450.00 second refresh rate) at path: <private>
Nov 12 12:24:53 iPad duetexpertd(AppPredictionInternal)[568] <Notice>: <private> - -[ATXUpdatePredictionsManager updateBehavioralPredictionsIfOlderThan:reason:]_block_invoke: app consumerSubTypes to refresh: <private>
Nov 12 12:24:53 iPad duetexpertd(AppPredictionInternal)[568] <Notice>: <private> - -[ATXUpdatePredictionsManager updateBehavioralPredictionsIfOlderThan:reason:]_block_invoke: action consumerSubTypes to refresh: <private>
Nov 12 12:24:53 iPad locationd[64] <Notice>: {"msg":"#sbim client arrow state changed", "clientKey":"com.apple.locationd.bundle-\134/System\134/Library\134/PrivateFrameworks\134/CoreParsec.framework", "entityClass":"SystemService", "oldArrowState":"ReceivingLocationInformation", "newArrowState":"RequestingLocationInformation", "dueToDeauthorization":0}
Nov 12 12:24:53 iPad locationd[64] <Notice>: {"msg":"#sbim entity class arrow state changed", "entityClass":"SystemService", "oldArrowState":"ReceivingLocationInformation", "newArrowState":"RequestingLocationInformation", "dueToDeauthorization":0}
Nov 12 12:24:54 iPad locationd[64] <Notice>: MotionCoprocessor,startTime,626894694.472479,motionType,1,youthType,0,youthTypeReason,0
Nov 12 12:24:55 iPad sharingd(CoreUtils)[531] <Notice>: NearbyInfo sending activity level, original: 0xb encrypted:0xa
Nov 12 12:24:56 iPad locationd[64] <Notice>: MotionCoprocessor,startTime,626894697.035772,motionType,1,youthType,0,youthTypeReason,0
Nov 12 12:24:57 iPad SpringBoard(FrontBoard)[510] <Error>: [application<com.REDACTED>:796] Provision violated for watchdog process-launch: <FBSProcessResourceProvision: 0x2813ec580; allowance: <; FBSProcessResourceAllowance; type: realTime; timeValue: 20.0s>; violated: YES>
Nov 12 12:24:57 iPad SpringBoard(FrontBoard)[510] <Notice>: [application<com.REDACTED>:796] Received termination request: <FBSProcessTerminationRequest: 0x282709600; label: "watchdog provision violated"; exceptionCode: "Watchdog Violation (0x8BADF00D)"; reportType: CrashLog; explanation: "process-launch watchdog transgression: application<com.REDACTED>:796 exhausted real (wall clock) time allowance of 20.00 seconds">
Nov 12 12:24:57 iPad SpringBoard(FrontBoard)[510] <Notice>: [application<com.REDACTED>:796] Now flagged as pending exit for reason: terminate with request
Nov 12 12:24:57 iPad SpringBoard(FrontBoard)[510] <Notice>: [application<com.REDACTED>:796] Executing termination request: <FBSProcessTerminationRequest: 0x282708f00; label: "watchdog provision violated"; exceptionCode: "Watchdog Violation (0x8BADF00D)"; reportType: CrashLog; explanation: "process-launch watchdog transgression: application<com.REDACTED>:796 exhausted real (wall clock) time allowance of 20.00 seconds">
Nov 12 12:24:57 iPad runningboardd(RunningBoard)[31] <Notice>: Received termination request from [daemon<com.apple.SpringBoard>:510] on <RBSProcessPredicate <RBSProcessHandlePredicateImpl| application<com.REDACTED>:796>> with context <RBSTerminateContext| domain:10 code:0x8BADF00D explanation:process-launch watchdog transgression: application<com.REDACTED>:796 exhausted real (wall clock) time allowance of 20.00 seconds
ProcessVisibility: Foreground
ProcessState: Running
WatchdogEvent: process-launch
WatchdogVisibility: Foreground
WatchdogCPUStatistics: (
"Elapsed total CPU time (seconds): 23.360 (user 23.360, system 0.000), 15% CPU",
"Elapsed application CPU time (seconds): 19.920, 12% CPU"
) reportType:CrashLog maxTerminationResistance:Interactive>
Nov 12 12:24:57 iPad runningboardd(RunningBoard)[31] <Notice>: Executing termination request for: <RBSProcessPredicate <RBSProcessHandlePredicateImpl| application<com.REDACTED>:796>>
Nov 12 12:24:57 iPad runningboardd(RunningBoard)[31] <Notice>: [application<com.REDACTED>:796] Terminating with context: <RBSTerminateContext| domain:10 code:0x8BADF00D explanation:process-launch watchdog transgression: application<com.REDACTED>:796 exhausted real (wall clock) time allowance of 20.00 seconds
ProcessVisibility: Foreground
ProcessState: Running
WatchdogEvent: process-launch
WatchdogVisibility: Foreground
WatchdogCPUStatistics: (
"Elapsed total CPU time (seconds): 23.360 (user 23.360, system 0.000), 15% CPU",
"Elapsed application CPU time (seconds): 19.920, 12% CPU"
) reportType:CrashLog maxTerminationResistance:Interactive>
Nov 12 12:24:57 iPad runningboardd(RunningBoard)[31] <Notice>: [application<com.REDACTED>:796] terminate_with_reason() success
Nov 12 12:24:57 iPad runningboardd(AppServerSupport)[31] <Notice>: 28BA0B70-901E-4660-915C-E8451235B89E monitor: got an update with state 4
Nov 12 12:24:57 iPad runningboardd(RunningBoard)[31] <Notice>: [application<com.REDACTED>:796] termination reported by launchd (10, 2343432205, 9)
Nov 12 12:24:57 iPad runningboardd(RunningBoard)[31] <Notice>: Removing process: [application<com.REDACTED>:796]
Nov 12 12:24:57 iPad runningboardd(RunningBoard)[31] <Notice>: Removing launch job for: [application<com.REDACTED>:796]
Nov 12 12:24:57 iPad runningboardd(AppServerSupport)[31] <Notice>: <OSLaunchdJob | handle=28BA0B70-901E-4660-915C-E8451235B89E>: remove succeeded
Nov 12 12:24:57 iPad runningboardd(RunningBoard)[31] <Notice>: Removed job for [application<com.REDACTED>:796]
Nov 12 12:24:57 iPad runningboardd(RunningBoard)[31] <Notice>: Removing assertions for terminated process: [application<com.REDACTED>:796]
Nov 12 12:24:57 iPad runningboardd(RunningBoard)[31] <Notice>: Removed last relative-start-date-defining assertion for process application<com.REDACTED>
Nov 12 12:24:57 iPad powerd[41] <Notice>: Process runningboardd.31 Released SystemIsActive "application<com.REDACTED>31-510-1699:FBApplicationProcess" age:00:00:20  id:51539645724 [System: PrevIdle SysAct]
Nov 12 12:24:57 iPad SpringBoard(RunningBoardServices)[510] <Notice>: Firing exit handlers for 796 with context <RBSProcessExitContext| specific, status:<RBSProcessExitStatus| domain:frontboard(10) code:watchdog(0x8badf00d)>>
Nov 12 12:24:57 iPad SpringBoard(FrontBoard)[510] <Notice>: [application<com.REDACTED>:796] Connection to remote process failed.
Nov 12 12:24:57 iPad SpringBoard(FrontBoard)[510] <Notice>: [application<com.REDACTED>:796] Process exited: <FBProcessExitContext; watchdog ("watchdog provision violated")>.
Nov 12 12:24:57 iPad SpringBoard(FrontBoard)[510] <Notice>: [application<com.REDACTED>:796] Setting process task state to: Not Running
Nov 12 12:24:57 iPad SpringBoard(FrontBoard)[510] <Notice>: [application<com.REDACTED>:796] Setting process visibility to: Unknown
Nov 12 12:24:57 iPad SpringBoard(FrontBoard)[510] <Notice>: change foreground process from list:(null)
Nov 12 12:24:57 iPad SpringBoard(FrontBoard)[510] <Notice>: [application<com.REDACTED>:796] Invalidating workspace.
Nov 12 12:24:57 iPad SpringBoard(FrontBoard)[510] <Notice>: Removing workspace registration for processHandle: [application<com.REDACTED>:796]
Nov 12 12:24:57 iPad runningboardd(RunningBoard)[31] <Notice>: Released power assertion with ID 38172
Nov 12 12:24:57 iPad runningboardd(RunningBoard)[31] <Notice>: Calculated state for application<com.REDACTED>: none (role: None)
Nov 12 12:24:57 iPad SpringBoard(FrontBoard)[510] <Notice>: Removing: <FBApplicationProcess: 0x1047b0da0; application<com.REDACTED>:796(v871)>
Nov 12 12:24:57 iPad runningboardd(RunningBoard)[31] <Notice>: Calculated state for application<com.REDACTED>: none (role: None)
Nov 12 12:24:57 iPad mediaserverd(MediaExperience)[481] <Notice>: -CMSessionMgr- CMSessionMgrHandleApplicationStateChange: Client com.REDACTED with pid '796' is now Terminated. Background entitlement: NO ActiveLongFormVideoSession: NO WhitelistedLongFormVideoApp NO
Nov 12 12:24:57 iPad SpringBoard(RunningBoardServices)[510] <Notice>: Updating configuration of monitor <RBSProcessMonitorConfiguration| id:M510-2 qos:25 predicates:[<RBSProcessPredicate <RBSProcessIdentifierPredicate| 547>>, <RBSProcessPredicate <RBSProcessIdentifierPredicate| 679>>, <RBSProcessPredicate <RBSProcessIdentifierPredicate| 532>>, <RBSProcessPredicate <RBSProcessIdentifierPredicate| 751>>, <RBSProcessPredicate <RBSProcessIdentifierPredicate| 523>>] descriptor:<RBSProcessStateDescriptor| values:1> events:0x0>
Nov 12 12:24:57 iPad SpringBoard(SpringBoard)[510] <Notice>: SBMainWorkspaceApplicationSceneLayoutElementViewController-sceneID:com.REDACTED-default did end transition to visible YES
Nov 12 12:24:57 iPad SpringBoard(SpringBoard)[510] <Notice>: SBMainWorkspaceApplicationSceneLayoutElementViewController-sceneID:com.REDACTED-default shouldDisplayLayoutElementBecomeActive=YES because isEffectivelyForeground=YES isSuspendedUnderLock=NO sceneIfExists=<FBScene: 0x280afed60; sceneID: sceneID:com.REDACTED-default; valid: YES>
Nov 12 12:24:57 iPad SpringBoard(FrontBoard)[510] <Notice>: [application<com.REDACTED>:796] Dropping launch assertion.
Nov 12 12:24:57 iPad SpringBoard(SpringBoard)[510] <Notice>: sceneHandle=<SBDeviceApplicationSceneHandle: 0x10960dca0; sceneID: sceneID:com.REDACTED-default; scenePointer: 0x280afed60; scene: <FBScene: 0x280afed60; sceneID: sceneID:com.REDACTED-default; valid: YES> {    specification = UIApplicationSceneSpecification;
settings = <UIApplicationSceneSettings: 0x281375080> {
displayConfiguration = "<FBSDisplayConfiguration: 0x2804b81c0; Main; mode: "1024x1366@2x 120Hz p3 SDR">";
frame = {{0, 0}, {1024, 1366}};
level = 1.0;
interfaceOrientation = landscapeRight (3);
foreground = YES;
interruptionPolicy = default;
isOccluded = BSSettingFlagNotSet;
otherSettings = <BSSettings: 0x283cf8020> {
statusBarStyleOverridesToSuppress = (none);
deactivationReasons = ;
deviceOrientationEventsEnabled = YES;
canShowAlerts = YES;
userInterfaceStyle = dark;
peripheryInsets = UIEdgeInsets: {0, 0, 0, 0};
deviceOrientation =
Nov 12 12:24:57 iPad SpringBoard(FrontBoard)[510] <Error>: Ignoring state for untracked process [application<com.REDACTED>:796]: <RBSProcessState| task:none debug:none>
Nov 12 12:24:57 iPad SpringBoard(SpringBoard)[510] <Notice>: End pending app suggestions update because Transitioning
Nov 12 12:24:57 iPad SpringBoard(UserNotificationsServer)[510] <Notice>: [com.REDACTED] com.REDACTED application state changed to Terminated
Nov 12 12:24:57 iPad SpringBoard(SpringBoard)[510] <Notice>: Front display did change: <SBApplication: 0x2806856c0; com.REDACTED>
Nov 12 12:24:57 iPad SpringBoard(SpringBoard)[510] <Notice>: 0x2827e6200 reconfigured attention timeouts:(    "<ITIdleTimeout: 0x283dcc740; identifier: 1; duration: 100.0s>",
"<ITIdleTimeout: 0x283dcc6a0; identifier: 2; duration: 102.0s>",
"<ITIdleTimeout: 0x283dccc20; identifier: 3; duration: 120.0s>"
)
Nov 12 12:24:57 iPad SpringBoard(UserNotificationsServer)[510] <Notice>: [com.REDACTED] Ignore becoming background for application without push registration
Nov 12 12:24:57 iPad backboardd(AttentionAwareness)[61] <Notice>:                 RemoteClient.m:603 :   10381.72167:  Info: reset attention lost timeout for com.apple.springboard.GlobalBacklightIdleTimer at   10381.72167
Nov 12 12:24:57 iPad backboardd(AttentionAwareness)[61] <Notice>:                 RemoteClient.m:334 :   10381.72180:  Info: updated config <AWRemoteClient: 0x12be18a20> (identifier: com.apple.springboard.GlobalBacklightIdleTimer samplingInterval:       4.00000 samplingDelay:      84.00000 sampleWhileAbsent: false attentionLostTimeouts: 100, 102, 120 notificationMask NONE mask AttentionLost|Button|Keyboard|Digitizer|Pointer|GameController|FaceDetect|MesaTouch|GenericGesture attentionLostEventMask AttentionLost|Button|Keyboard|Digitizer|Pointer|GameController|MesaTouch|GenericGesture tagIndex 112), old config <AWRemoteClient: 0x12be18a20> (identifier: com.apple.springboard.GlobalBacklightIdleTimer samplingInterval:       4.00000 samplingDelay:      84.00000 sampleWhileAbsent: false attentionLostTimeouts: 100, 102, 120 notificationMask NONE mask AttentionLost|Button|Keyboard|Digitizer|Pointer|GameController|FaceDetect|MesaTouch|GenericGesture attentionLostEventMask AttentionLost|Button|Keyboard|Digitizer|Pointer|GameController|MesaTouch|GenericGesture tagIndex 111)
Nov 12 12:24:57 iPad SpringBoard(IdleTimerHosting)[510] <Notice>: <0x2827e5740> - reconfigure attention client with configuration:<AWAttentionAwarenessConfiguration: 0x2816c65a0> (identifier: com.apple.springboard.GlobalBacklightIdleTimer samplingInterval:       4.00000 samplingDelay:      84.00000 sampleWhileAbsent: false attentionLostTimeouts:     102.00000,     100.00000,     120.00000 notificationMask NONE mask Button|Keyboard|Digitizer|Pointer|GameController|FaceDetect|MesaTouch|GenericGesture attentionLostEventMask Button|Keyboard|Digitizer|Pointer|GameController|MesaTouch|GenericGesture tagIndex 112 (tag <ITAttentionAwarenessContext: 0x283fa8e50>))
Nov 12 12:24:57 iPad SpringBoard(SpringBoard)[510] <Notice>: activity is unchanged, still disabled
Nov 12 12:24:57 iPad SpringBoard(BaseBoard)[510] <Error>: Unable to get short BSD proc info for 796: No such process
Nov 12 12:24:57 iPad SpringBoard(SpringBoard)[510] <Notice>: SBIdleTimerGlobalCoordinator - _setIdleTimerWithDescriptor:<SBIdleTimerDescriptor: 0x28318aeb0; timerMode: Automatic; sampleInterval: 4.0s; quickUnwarnInterval: 102.0s; warnInterval: 100.0s; totalInterval: 120.0s> reason:"SBAppDidEnterBackground"]
Nov 12 12:24:57 iPad SpringBoard(SpringBoard)[510] <Notice>: 0x2827e6200 reconfigured attention timeouts:(    "<ITIdleTimeout: 0x283cdf640; identifier: 1; duration: 100.0s>",
"<ITIdleTimeout: 0x283cddd20; identifier: 2; duration: 102.0s>",
"<ITIdleTimeout: 0x283cdd4c0; identifier: 3; duration: 120.0s>"
)
Nov 12 12:24:57 iPad backboardd(AttentionAwareness)[61] <Notice>:                 RemoteClient.m:603 :   10381.72521:  Info: reset attention lost timeout for com.apple.springboard.GlobalBacklightIdleTimer at   10381.72521
Nov 12 12:24:57 iPad backboardd(AttentionAwareness)[61] <Notice>:                 RemoteClient.m:334 :   10381.72532:  Info: updated config <AWRemoteClient: 0x12be18a20> (identifier: com.apple.springboard.GlobalBacklightIdleTimer samplingInterval:       4.00000 samplingDelay:      84.00000 sampleWhileAbsent: false attentionLostTimeouts: 100, 102, 120 notificationMask NONE mask AttentionLost|Button|Keyboard|Digitizer|Pointer|GameController|FaceDetect|MesaTouch|GenericGesture attentionLostEventMask AttentionLost|Button|Keyboard|Digitizer|Pointer|GameController|MesaTouch|GenericGesture tagIndex 113), old config <AWRemoteClient: 0x12be18a20> (identifier: com.apple.springboard.GlobalBacklightIdleTimer samplingInterval:       4.00000 samplingDelay:      84.00000 sampleWhileAbsent: false attentionLostTimeouts: 100, 102, 120 notificationMask NONE mask AttentionLost|Button|Keyboard|Digitizer|Pointer|GameController|FaceDetect|MesaTouch|GenericGesture attentionLostEventMask AttentionLost|Button|Keyboard|Digitizer|Pointer|GameController|MesaTouch|GenericGesture tagIndex 112)
Nov 12 12:24:57 iPad SpringBoard(IdleTimerHosting)[510] <Notice>: <0x2827e5740> - reconfigure attention client with configuration:<AWAttentionAwarenessConfiguration: 0x28160ea70> (identifier: com.apple.springboard.GlobalBacklightIdleTimer samplingInterval:       4.00000 samplingDelay:      84.00000 sampleWhileAbsent: false attentionLostTimeouts:     102.00000,     100.00000,     120.00000 notificationMask NONE mask Button|Keyboard|Digitizer|Pointer|GameController|FaceDetect|MesaTouch|GenericGesture attentionLostEventMask Button|Keyboard|Digitizer|Pointer|GameController|MesaTouch|GenericGesture tagIndex 113 (tag <ITAttentionAwarenessContext: 0x283fb63d0>))
Nov 12 12:24:57 iPad backboardd[61] <Notice>: Setting minimum brightness level: 0.000000 with fade duration 0.500000
Nov 12 12:24:57 iPad backboardd[61] <Notice>: Set BrightnessSystem property:DisplayBrightnessFadePeriod to:0.5
Nov 12 12:24:57 iPad backboardd[61] <Notice>: Set BrightnessSystem property:BrightnessMinPhysicalWithFade to:0
Nov 12 12:24:57 iPad SpringBoard(SpringBoard)[510] <Notice>: SBMainWorkspaceApplicationSceneLayoutElementViewController-sceneID:com.REDACTED-default will begin transition to visible NO
Nov 12 12:24:57 iPad SpringBoard(SpringBoard)[510] <Notice>: Beging pending app suggestions update because Transitioning
Nov 12 12:24:57 iPad SpringBoard(SpringBoard)[510] <Notice>: Deactivating wallpaper orientation source ActiveOrientation
Nov 12 12:24:57 iPad SpringBoard(SpringBoard)[510] <Notice>: participant=0x2827b5d40:SBHomeGestureParticipantIdentifierSwitcher suppression set to:Suppress
Nov 12 12:24:57 iPad ReportCrash[797] <Notice>: Launched ReportCrash to service - com.apple.ReportCrash
Nov 12 12:24:57 iPad ReportCrash(CrashReporterSupport)[797] <Notice>: Trying to create CR directory structure as root
Nov 12 12:24:57 iPad CommCenter[83] <Notice>: #I FBSDisplayLayoutUpdateHandler: update start
Nov 12 12:24:57 iPad CommCenter[83] <Notice>: #I ActivationObserver: notifyAboutFrontAppChange : app: <private>; pid: 0; net: 0
Nov 12 12:24:57 iPad CommCenter[83] <Notice>: #I FBSDisplayLayoutUpdateHandler: 5. app got notification state: new counter=70
Nov 12 12:24:57 iPad dmd[479] <Notice>: Update foreground bundle identifiers
Nov 12 12:24:57 iPad SpringBoard(SpringBoard)[510] <Notice>: Begin requiring home screen content for reason 'SBUIHomeScreenActiveContentRequirementReason'
Nov 12 12:24:57 iPad SpringBoard(UIKitCore)[510] <Notice>: No longer tracking: <FBScene: 0x280afed60; sceneID: sceneID:com.REDACTED-default; valid: YES>
Nov 12 12:24:57 iPad CommCenter[83] <Notice>: #I <private> request: <private>, expects reply.
Nov 12 12:24:57 iPad CommCenter[83] <Notice>: #I <private> reply to request '<private>'.
Nov 12 12:24:57 iPad wifid(WiFiPolicy)[49] <Notice>: App state params {    IO80211IsInHomeScreen = 1;
IO80211IsLatencySensitiveAppActive = 0;
}
Nov 12 12:24:57 iPad wifid(WiFiPolicy)[49] <Notice>: WiFiDeviceSetProperty: ERROR: Setting reg entry key IO80211AppState failed e00002d8
Nov 12 12:24:57 iPad wifid(WiFiPolicy)[49] <Notice>: BG Application: Not Present, BG Daemon: Present. Daemons: apsd  Cloud Clients:
Nov 12 12:24:57 iPad wifid(WiFiPolicy)[49] <Notice>: WiFiDeviceManagerReset: type=SpringBoard
Nov 12 12:24:57 iPad wifid(WiFiPolicy)[49] <Notice>: WiFiManagerGetUserAutoJoinState: user auto join state 1
Nov 12 12:24:57 iPad wifid(WiFiPolicy)[49] <Notice>: AlwaysOnWiFi: Disabled
Nov 12 12:24:57 iPad runningboardd(RunningBoard)[31] <Notice>: Acquiring assertion targeting 796 from originator [daemon<com.apple.SpringBoard>:510] with description <RBSAssertionDescriptor| "FBSceneSnapshotAction:sceneID:com.REDACTED-default" ID:31-510-1703 target:796 attributes:[  <RBSRunningReasonAttribute| runningReason:17>,
    <RBSGPUAccessGrant>,
    <RBSCPUAccessGrant| role:NonUserInteractive>,
    <RBSJetsamPriorityGrant| priority:Background>,
    <RBSPreventIdleSleepGrant>
    ]>
Nov 12 12:24:57 iPad SpringBoard(RunningBoardServices)[510] <Error>: Error acquiring assertion: <Error Domain=RBSAssertionErrorDomain Code=2 "Specified target process does not exist" UserInfo={NSLocalizedFailureReason=Specified target process does not exist}>
Nov 12 12:24:57 iPad SpringBoard(SpringBoard)[510] <Notice>: SBMainWorkspaceApplicationSceneLayoutElementViewController-sceneID:com.REDACTED-default did end transition to visible NO
Nov 12 12:24:57 iPad wifid(WiFiPolicy)[49] <Notice>: __WiFiManagerSetEnableState: state TRUE, manager->enable.setting TRUE, manager->unlockedSinceBoot TRUE
Nov 12 12:24:57 iPad wifid(WiFiPolicy)[49] <Notice>: __WiFiDeviceManagerResetRetryIntervals called by __WiFiManagerDeviceManagerApplier
Nov 12 12:24:57 iPad wifid(WiFiPolicy)[49] <Notice>: __WiFiDeviceManagerAutoAssociate called by __WiFiManagerDeviceManagerApplier
Nov 12 12:24:57 iPad wifid(WiFiPolicy)[49] <Notice>: Auto association attempt canceled because device is not powered.
Nov 12 12:24:57 iPad wifid(WiFiPolicy)[49] <Notice>: WiFiMetricsManagerSubmitAutoJoinSessionRecordsMetric: interface en0 has 10 AJ records to submit...
Nov 12 12:24:57 iPad wifid(WiFiPolicy)[49] <Notice>: -[WiFiManagerAnalytics prepareMessageForSubmission:withData:andReply:] Received call to prepare message with identifier: 0x9004d
Nov 12 12:24:57 iPad wifid(WiFiPolicy)[49] <Notice>: Copy current network requested by "bluetoothd"
Nov 12 12:24:57 iPad wifid(WiFiPolicy)[49] <Notice>: Copy current network requested by "rapportd"
Nov 12 12:24:57 iPad wifid(WiFiPolicy)[49] <Notice>: Copy current network requested by "sharingd"
Nov 12 12:24:57 iPad wifid(WiFiPolicy)[49] <Notice>: Copy current network requested by "rapportd"
Nov 12 12:24:57 iPad wifianalyticsd[170] <Notice>: -[WAIOReporterMessagePopulator persistCachedMessage]::712:Didn't find new channels, not updating file <private>
Nov 12 12:24:57 iPad wifid(WiFiPolicy)[49] <Notice>: Copy current network requested by "sharingd"
Nov 12 12:24:57 iPad locationd[64] <Notice>: {"msg":"#CLIUA Marking change", "clientKey":"com.REDACTED", "reason":"Process state from RunningBoard", "assertionLevel":5, "coming":0}
Nov 12 12:24:57 iPad wifianalyticsd[170] <Notice>: -[WAIOReporterMessagePopulator persistCachedMessage]::712:Didn't find new channels, not updating file <private>
Nov 12 12:24:57 iPad SpringBoard(SpringBoard)[510] <Notice>: End pending app suggestions update because Transitioning
Nov 12 12:24:57 iPad SpringBoard(SpringBoard)[510] <Notice>: SBIdleTimerGlobalCoordinator - _setIdleTimerWithDescriptor:<SBIdleTimerDescriptor: 0x2832ff390; timerMode: Automatic; sampleInterval: 4.0s; quickUnwarnInterval: 102.0s; warnInterval: 100.0s; totalInterval: 120.0s> reason:"SBHomeScreen"]
Nov 12 12:24:57 iPad wifianalyticsd[170] <Notice>: -[WAIOReporterMessagePopulator persistCachedMessage]::712:Didn't find new channels, not updating file <private>
Nov 12 12:24:57 iPad SpringBoard(SpringBoard)[510] <Notice>: 0x2827e6200 reconfigured attention timeouts:(    "<ITIdleTimeout: 0x283ccce00; identifier: 1; duration: 100.0s>",
"<ITIdleTimeout: 0x283ccdd20; identifier: 2; duration: 102.0s>",
"<ITIdleTimeout: 0x283cce560; identifier: 3; duration: 120.0s>"
)
Nov 12 12:24:57 iPad backboardd(AttentionAwareness)[61] <Notice>:                 RemoteClient.m:603 :   10381.73903:  Info: reset attention lost timeout for com.apple.springboard.GlobalBacklightIdleTimer at   10381.73903
Nov 12 12:24:57 iPad wifianalyticsd[170] <Notice>: -[WAIOReporterMessagePopulator persistCachedMessage]::712:Didn't find new channels, not updating file <private>
Nov 12 12:24:57 iPad backboardd(AttentionAwareness)[61] <Notice>:                 RemoteClient.m:334 :   10381.73916:  Info: updated config <AWRemoteClient: 0x12be18a20> (identifier: com.apple.springboard.GlobalBacklightIdleTimer samplingInterval:       4.00000 samplingDelay:      84.00000 sampleWhileAbsent: false attentionLostTimeouts: 100, 102, 120 notificationMask NONE mask AttentionLost|Button|Keyboard|Digitizer|Pointer|GameController|FaceDetect|MesaTouch|GenericGesture attentionLostEventMask AttentionLost|Button|Keyboard|Digitizer|Pointer|GameController|MesaTouch|GenericGesture tagIndex 114), old config <AWRemoteClient: 0x12be18a20> (identifier: com.apple.springboard.GlobalBacklightIdleTimer samplingInterval:       4.00000 samplingDelay:      84.00000 sampleWhileAbsent: false attentionLostTimeouts: 100, 102, 120 notificationMask NONE mask AttentionLost|Button|Keyboard|Digitizer|Pointer|GameController|FaceDetect|MesaTouch|GenericGesture attentionLostEventMask AttentionLost|Button|Keyboard|Digitizer|Pointer|GameController|MesaTouch|GenericGesture tagIndex 113)
Nov 12 12:24:57 iPad SpringBoard(IdleTimerHosting)[510] <Notice>: <0x2827e5740> - reconfigure attention client with configuration:<AWAttentionAwarenessConfiguration: 0x28167c9a0> (identifier: com.apple.springboard.GlobalBacklightIdleTimer samplingInterval:       4.00000 samplingDelay:      84.00000 sampleWhileAbsent: false attentionLostTimeouts:     102.00000,     100.00000,     120.00000 notificationMask NONE mask Button|Keyboard|Digitizer|Pointer|GameController|FaceDetect|MesaTouch|GenericGesture attentionLostEventMask Button|Keyboard|Digitizer|Pointer|GameController|MesaTouch|GenericGesture tagIndex 114 (tag <ITAttentionAwarenessContext: 0x283ff9ba0>))
Nov 12 12:24:57 iPad SpringBoard(SpringBoard)[510] <Notice>: removing status bar settings assertion after 20.021586 seconds: <SBAppStatusBarSettingsAssertion: 0x2831f7db0> {    settings = <SBAppStatusBarSettings: 0x283f87780; alpha: 0>;
level = app switcher;
reason = kSBMainAppSwitcherStatusBarReason;
}
Nov 12 12:24:57 iPad wifianalyticsd[170] <Notice>: -[WAIOReporterMessagePopulator persistCachedMessage]::712:Didn't find new channels, not updating file <private>
Nov 12 12:24:57 iPad SpringBoard(SpringBoard)[510] <Notice>: removing floating dock behavior assertion: <SBFloatingDockBehaviorAssertion: 0x282707c80> {    pinned = NO;
animated = YES;
gesture possible = YES;
visible progress = 0.000000;
level = in app;
reason = in app;
timestamp = 2020-11-12 17:24:37 +0000;
}
Nov 12 12:24:57 iPad wifianalyticsd[170] <Notice>: -[WAIOReporterMessagePopulator persistCachedMessage]::712:Didn't find new channels, not updating file <private>
Nov 12 12:24:57 iPad SpringBoard(SpringBoardFoundation)[510] <Notice>: Pop (wasKey=YES, reason=caller requested): <private>
Nov 12 12:24:57 iPad SpringBoard(SpringBoardFoundation)[510] <Notice>: Evaluate: making new window key: <SBHomeScreenWindow: 0x104484900>, for reason: popped window was key
Nov 12 12:24:57 iPad wifianalyticsd[170] <Notice>: -[WAIOReporterMessagePopulator persistCachedMessage]::712:Didn't find new channels, not updating file <private>
Nov 12 12:24:57 iPad SpringBoard(SpringBoard)[510] <Notice>: updateKeyboardFocusDeferringRules: app focus pid:796 token:(null)
Nov 12 12:24:57 iPad wifianalyticsd[170] <Notice>: -[WAIOReporterMessagePopulator persistCachedMessage]::712:Didn't find new channels, not updating file <private>
Nov 12 12:24:57 iPad backboardd(BackBoardHIDEventFoundation)[61] <Notice>: new deferring rules for pid:510: [    <environment: system> -> <pid: 510; token: 0x15718FD7> reason: "1-deferDiscrete: systemGestures",
<environment: keyboardFocus; display: builtin> -> <pid: 510; token: 0x5D484C4> reason: "132-deferDiscrete: Key Window event focus deferral",
<environment: keyboardFocus; display: builtin> -> <pid: 796> reason: "133-deferDiscrete: SpringBoardToApp",
<environment: keyboardFocus; display: builtin; token: 0x5D484C4> -> <pid: 796> reason: "134-deferDiscrete: SpringBoardToAppCompatibility",
<environment: keyboardFocus; display: builtin> -> <pid: 510; token: 0xA872C3A8> reason: "135-deferDiscrete: Key Window event focus deferral"
]
Nov 12 12:24:57 iPad wifianalyticsd[170] <Notice>: -[WAIOReporterMessagePopulator persistCachedMessage]::712:Didn't find new channels, not updating file <private>
Nov 12 12:24:57 iPad wifid(WiFiPolicy)[49] <Notice>: -[WiFiManagerAnalytics submitMessage:] Received call to submit message with key: MMAJS, original classname: AWDWiFiMetricsManagerAutoJoinSession and identifier: 589901
Nov 12 12:24:57 iPad runningboardd(RunningBoard)[31] <Notice>: Invalidating assertion 31-510-1701 (target:[daemon<com.apple.SpringBoard>:510](UIScene:com.apple.frontboard.systemappservices::com.apple.springboard)) from originator [daemon<com.apple.SpringBoard>:510]
Nov 12 12:24:57 iPad accessoryd(System)[150] <Notice>: Posting application state change {    ACCPlatformApplicationStateDisplayIDKey = "com.REDACTED";
ACCPlatformApplicationStateKey = 1;
ACCPlatformApplicationStateProcessIDKey = 796;
}
Nov 12 12:24:57 iPad SpringBoard(SpringBoard)[510] <Notice>: Front display did change: (null)
Nov 12 12:24:57 iPad SpringBoard(SpringBoard)[510] <Notice>: 0x2827e6200 reconfigured attention timeouts:(    "<ITIdleTimeout: 0x283ce98a0; identifier: 1; duration: 100.0s>",
"<ITIdleTimeout: 0x283ce9ec0; identifier: 2; duration: 102.0s>",
"<ITIdleTimeout: 0x283cea0e0; identifier: 3; duration: 120.0s>"
)
Nov 12 12:24:57 iPad backboardd(AttentionAwareness)[61] <Notice>:                 RemoteClient.m:603 :   10381.74962:  Info: reset attention lost timeout for com.apple.springboard.GlobalBacklightIdleTimer at   10381.74962
Nov 12 12:24:57 iPad backboardd(AttentionAwareness)[61] <Notice>:                 RemoteClient.m:334 :   10381.74973:  Info: updated config <AWRemoteClient: 0x12be18a20> (identifier: com.apple.springboard.GlobalBacklightIdleTimer samplingInterval:       4.00000 samplingDelay:      84.00000 sampleWhileAbsent: false attentionLostTimeouts: 100, 102, 120 notificationMask NONE mask AttentionLost|Button|Keyboard|Digitizer|Pointer|GameController|FaceDetect|MesaTouch|GenericGesture attentionLostEventMask AttentionLost|Button|Keyboard|Digitizer|Pointer|GameController|MesaTouch|GenericGesture tagIndex 115), old config <AWRemoteClient: 0x12be18a20> (identifier: com.apple.springboard.GlobalBacklightIdleTimer samplingInterval:       4.00000 samplingDelay:      84.00000 sampleWhileAbsent: false attentionLostTimeouts: 100, 102, 120 notificationMask NONE mask AttentionLost|Button|Keyboard|Digitizer|Pointer|GameController|FaceDetect|MesaTouch|GenericGesture attentionLostEventMask AttentionLost|Button|Keyboard|Digitizer|Pointer|GameController|MesaTouch|GenericGesture tagIndex 114)
Nov 12 12:24:57 iPad accessoryd[150] <Notice>: handling app state change notification {    ACCPlatformApplicationStateDisplayIDKey = "com.REDACTED";
ACCPlatformApplicationStateKey = 1;
ACCPlatformApplicationStateProcessIDKey = 796;
}
Nov 12 12:24:57 iPad SpringBoard(IdleTimerHosting)[510] <Notice>: <0x2827e5740> - reconfigure attention client with configuration:<AWAttentionAwarenessConfiguration: 0x281608e00> (identifier: com.apple.springboard.GlobalBacklightIdleTimer samplingInterval:       4.00000 samplingDelay:      84.00000 sampleWhileAbsent: false attentionLostTimeouts:     102.00000,     100.00000,     120.00000 notificationMask NONE mask Button|Keyboard|Digitizer|Pointer|GameController|FaceDetect|MesaTouch|GenericGesture attentionLostEventMask Button|Keyboard|Digitizer|Pointer|GameController|MesaTouch|GenericGesture tagIndex 115 (tag <ITAttentionAwarenessContext: 0x283f8c2a0>))
Nov 12 12:24:57 iPad SpringBoard(SpringBoard)[510] <Notice>: activity is unchanged, still disabled
Nov 12 12:24:57 iPad SpringBoard(SpringBoard)[510] <Notice>: Begin requiring home screen content for reason 'SBUIHomeScreenActiveContentRequirementReason'
Nov 12 12:24:57 iPad SpringBoard(SpringBoard)[510] <Notice>: Enabling home screen icon rotation for reason: SBAppToAppWorkspaceTransaction
Nov 12 12:24:57 iPad SpringBoard(SpringBoard)[510] <Notice>: Nudging home screen window orientation because icon rotation changed.
Nov 12 12:24:57 iPad SpringBoard(SpringBoard)[510] <Notice>: Root transaction complete: <SBAppToAppWorkspaceTransaction: 0x10d9be9b0>
Nov 12 12:24:57 iPad SpringBoard(SpringBoard)[510] <Error>: tried to remove an assertion that was never added: <SBFloatingDockBehaviorAssertion: 0x282707c80> {    pinned = NO;
animated = YES;
gesture possible = YES;
visible progress = 0.000000;
level = in app;
reason = in app;
timestamp = 2020-11-12 17:24:37 +0000;
}
Nov 12 12:24:57 iPad wifianalyticsd[170] <Notice>: -[WAAWDMessageSubmitter submitMessage:]::131:Successfully submitted message with key: <private>
Nov 12 12:24:57 iPad SpringBoard(SpringBoard)[510] <Notice>: didSelectKeyboardFocusProcess:(null) token:(null)
Nov 12 12:24:57 iPad SpringBoard(SpringBoard)[510] <Notice>: updateKeyboardFocusDeferringRules: SpringBoard gets focus for reasons:(noKeyboardFocusProcess)
Nov 12 12:24:57 iPad SpringBoard(SpringBoard)[510] <Notice>: Process exited: <FBApplicationProcess: 0x1047b0da0; application<com.REDACTED>:796(v871)> -> <FBProcessExitContext; watchdog ("watchdog provision violated")>
Nov 12 12:24:57 iPad ReportCrash[797] <Notice>: Parsing corpse data for pid 796
Nov 12 12:24:57 iPad SpringBoard(SpringBoard)[510] <Notice>: reconfigured lock button: <SBMutableHardwareButtonGestureParameters: 0x2827075c0; maximumPressCount: 2; longPressTimeInterval: 0.40s; multiplePressTimeInterval: 0.40s>
Nov 12 12:24:57 iPad ReportCrash[797] <Notice>: osa_update: Pid 796 'REDACTED' CORPSE: Parsing KCData
Nov 12 12:24:57 iPad SpringBoard(SpringBoard)[510] <Notice>: Application process state changed for com.REDACTED: (null)
Nov 12 12:24:57 iPad ReportCrash[797] <Notice>: osa_update: Pid 796 'REDACTED' CORPSE: Extracting
Nov 12 12:24:57 iPad backboardd(BackBoardHIDEventFoundation)[61] <Notice>: new deferring rules for pid:510: [    <environment: system> -> <pid: 510; token: 0x15718FD7> reason: "1-deferDiscrete: systemGestures",
<environment: keyboardFocus; display: builtin> -> <pid: 510; token: 0xA872C3A8> reason: "135-deferDiscrete: Key Window event focus deferral"
]
Nov 12 12:24:57 iPad backboardd(BackBoardHIDEventFoundation)[61] <Notice>: new resolutions for pid:510 (    <display: builtin; environment: keyboardFocus; pid: 510; token: 0xA872C3A8>,
<display: null; environment: system; pid: 510; token: 0x15718FD7>,
<display: builtin; environment: cameraButton; pid: 510>
)
Nov 12 12:24:57 iPad CommCenter[83] <Notice>: #I FBSDisplayLayoutUpdateHandler: update start
Nov 12 12:24:57 iPad CommCenter[83] <Notice>: #I ActivationObserver: notifyAboutFrontAppChange : app: <private>; pid: 0; net: 0
Nov 12 12:24:57 iPad CommCenter[83] <Notice>: #I FBSDisplayLayoutUpdateHandler: 5. app got notification state: new counter=71
Nov 12 12:24:57 iPad SpringBoard(UIKitCore)[510] <Error>: Error creating the CFMessagePort needed to communicate with PPT.
Nov 12 12:24:57 iPad CommCenter[83] <Notice>: #I <private> request: <private>, expects reply.
Nov 12 12:24:57 iPad CommCenter[83] <Notice>: #I <private> reply to request '<private>'.
Nov 12 12:24:57 iPad CommCenter[83] <Notice>: #I <private> request: <private>, expects reply.
Nov 12 12:24:57 iPad CommCenter[83] <Notice>: #I <private> reply to request '<private>'.
Nov 12 12:24:57 iPad sharingd[531] <Notice>: SystemUI changed: 0x0 -> 0x10
Nov 12 12:24:57 iPad ReportCrash[797] <Notice>: osa_update: Pid 796 'REDACTED' CORPSE: Symbolicating
Nov 12 12:24:57 iPad sharingd[531] <Notice>: SystemUI changed: 0x10 -> 0x10
Nov 12 12:24:57 iPad symptomsd(SymptomEvaluator)[123] <Notice>: com.REDACTED: Foreground: false
Nov 12 12:24:57 iPad contextstored(BiomeStreams)[57] <Notice>: Received connection request for BMFileAccessService from pid 57
Nov 12 12:24:57 iPad symptomsd(SymptomEvaluator)[123] <Notice>: Failed to find process for com.REDACTED
Nov 12 12:24:57 iPad symptomsd(WiFiAnalytics)[123] <Notice>: -[WAClient _wakeUpNotificationForThisClientReceived:]_block_invoke::974:XPC: Received 'wake up' notification, but this client has no indication the connection is dead (daemonConnectionValid == true). Not starting connection recovery
Nov 12 12:24:57 iPad contextstored(CoreDuetContext)[57] <Notice>: CDUserContext: Remove object matching predicate <private> => <private>
Nov 12 12:24:57 iPad ReportCrash[797] <Notice>: osa_update: Pid 796 'REDACTED' CORPSE: Symbolicating2
Nov 12 12:24:57 iPad ReportCrash[797] <Notice>: <private>: [<private>] '(null)'
Nov 12 12:24:57 iPad symptomsd(WiFiAnalytics)[123] <Notice>: -[WAClient _wakeUpNotificationForThisClientReceived:]_block_invoke::974:XPC: Received 'wake up' notification, but this client has no indication the connection is dead (daemonConnectionValid == true). Not starting connection recovery
Nov 12 12:24:57 iPad dmd[479] <Notice>: Update foreground bundle identifiers
Nov 12 12:24:57 iPad dasd[113] <Notice>: Trigger: <private> is now [<private>]
Nov 12 12:24:57 iPad dasd[113] <Notice>: Foreground apps changed\M-b\M^@\M^T-<private>
Nov 12 12:24:57 iPad runningboardd(RunningBoard)[31] <Notice>: [daemon<com.apple.SpringBoard>:510] Ignoring jetsam update because this process is not memory-managed
Nov 12 12:24:57 iPad runningboardd(RunningBoard)[31] <Notice>: Calculated state for daemon<com.apple.SpringBoard>: running-active (role: UserInteractiveNonFocal)
Nov 12 12:24:57 iPad runningboardd(RunningBoard)[31] <Notice>: [daemon<com.apple.SpringBoard>:510] Ignoring suspend because this process is not lifecycle managed
Nov 12 12:24:57 iPad runningboardd(RunningBoard)[31] <Notice>: [daemon<com.apple.SpringBoard>:510] Ignoring GPU update because this process is not GPU managed
Nov 12 12:24:57 iPad homed(HomeKitDaemon)[478] <Notice>: Received app state change: <RBSProcessStateUpdate| process:[daemon<com.apple.SpringBoard>:510] oldState:<RBSProcessState| task:running-active debug:none endowments:[  com.apple.frontboard.visibility
    ] rbAssertions:[
    <RBSProcessAssertionInfo| type:1 reason:0 name:"Custom" domain:"(null)" expl:"FBSystemApp-PreventIdleSleep">,
    <RBSProcessAssertionInfo| type:2 reason:0 name:"Domain" domain:"com.apple.underlying:UnderlyingDarwinRoleUI" expl:"RB Underlying Assertion">,
    <RBSProcessAssertionInfo| type:1 reason:0 name:"Custom" domain:"(null)" expl:"injecting inherited from "UIScene:com.apple.frontboard.systemappservices::com.apple.springboard" to 510<UIScene:com.apple.frontboard.systemappservices::com.apple.springboard>">,
    <RBSProcessAssertionInfo| type:1 reason:0 name:"Custom" domain:"(null)" expl:"injecting inherited from "UIRootWindow:0x10460eb30" to 510<UIScene:com.apple.frontboard.systemappservices::com.apple.springboard>">,
    <RBSProcessAssertionInfo| type:1 reason:0 name:"Custom" domain:"(null)" expl:"creating 510<UIRootWindow:0x10462a340> visibility">,
    <RBSProcessAssertionInfo| type:1 reason:0 name:"Custom" domain:"(null)" expl:"creating 510<UIRootWindow:0x10460eb30> visibility">,
    <RBSProcessAssertionInfo| type:1 reason:10005 name:"Custom" domain:"(null)" expl:"FBSystemShell">
    ]> newState:<RBSProcessState| task:running-active debug:none endowments:[
    com.apple.frontboard.visibility
    ] rbAssertions:[
    <RBSProcessAssertionInfo| type:1 reason:0 name:"Custom" domain:"(null)" expl:"creating 510<UIRootWindow:0x10460eb30> visibility">,
    <RBSProcessAssertionInfo| type:2 reason:0 name:"Domain" domain:"com.apple.underlying:UnderlyingDarwinRoleUI" expl:"RB Underlying Assertion">,
    <RBSProcessAssertionInfo| type:1 reason:0 name:"Custom" domain:"(null)" expl:"FBSystemApp-PreventIdleSleep">,
    <RBSProcessAssertionInfo| type:1 reason:10005 name:"Custom" domain:"(null)" expl:"FBSystemShell">,
    <RBSProcessAssertionInfo| type:1 reason:0 name:"Custom" domain:"(null)" expl:"injecting inherited from "UIRootWindow:0x10460eb30" to 510<UIScene:com.apple.frontboard.systemappservices::com.apple.springboard>">,
    <RBSProcessAssertionInfo| type:1 reason:0 name:"Custom" domain:"(null)" expl:"creating 510<UIRootWindow:0x10462a340> visibility">
    ]> exitEvent:(null)>
Nov 12 12:24:57 iPad homed(HomeKitDaemon)[478] <Notice>: <HMDProcessInfo, Identifier: 510, Name: SpringBoard, Application Identifier: com.apple.springboard, State: foreground, Monitored: YES, Application: <__HMDApplicationInfo, Bundle Identifier: com.apple.springboard, Vendor Identifier: <[36] {length = 8, bytes = 0x3239453141414543} ... {length = 8, bytes = 0x3345394446463939}>>, Connections: (    "<HMDXPCClientConnection, Name: SpringBoard, Entitlements: com.apple.developer.homekit>",
"<HMDXPCClientConnection, Name: SpringBoard, Entitlements: com.apple.developer.homekit>"
)> back into foreground
Nov 12 12:24:57 iPad homed(HomeKitDaemon)[478] <Notice>: Processing change of state for <HMDProcessInfo, Identifier: 510, Name: SpringBoard, Application Identifier: com.apple.springboard, State: foreground, Monitored: YES, Application: <__HMDApplicationInfo, Bundle Identifier: com.apple.springboard, Vendor Identifier: <[36] {length = 8, bytes = 0x3239453141414543} ... {length = 8, bytes = 0x3345394446463939}>>, Connections: (    "<HMDXPCClientConnection, Name: SpringBoard, Entitlements: com.apple.developer.homekit>",
"<HMDXPCClientConnection, Name: SpringBoard, Entitlements: com.apple.developer.homekit>"
)>
==========  Nov 12, 2020 at 12:24:58 PM  ==========
Nov 12 12:24:58 iPad ReportCrash[797] <Notice>: osa_update: Pid 796 'REDACTED' CORPSE: Capture Complete
Nov 12 12:24:58 iPad ReportCrash[797] <Notice>: Formulating fatal report for corpse[796] REDACTED
Nov 12 12:24:58 iPad ReportCrash(OSAnalytics)[797] <Notice>: loading MetricKitSource
Nov 12 12:24:58 iPad ReportCrash[797] <Notice>: MK: <private> isn't a client
Nov 12 12:24:58 iPad ReportCrash(libsystem_containermanager.dylib)[797] <Notice>: container_system_group_path_for_identifier: success
Nov 12 12:24:58 iPad ReportCrash(ManagedConfiguration)[797] <Notice>: Got system group container path from MCM for systemgroup.com.apple.configurationprofiles: /private/var/containers/Shared/SystemGroup/systemgroup.com.apple.configurationprofiles
Nov 12 12:24:58 iPad ReportCrash(OSAnalytics)[797] <Notice>: C1. request '109' report service via XPC/osanalyticshelper
Nov 12 12:24:58 iPad osanalyticshelper[554] <Notice>: starting prolongation transaction timer
Nov 12 12:24:58 iPad osanalyticshelper[554] <Notice>: S1. helper service invoked for '<private>' report creation on behalf of <private>
Nov 12 12:24:58 iPad osanalyticshelper[554] <Notice>: S2. helper service creating file
Nov 12 12:24:58 iPad osanalyticshelper[554] <Notice>: S3. helper service utilizing back-channel with file descriptor for payload
Nov 12 12:24:58 iPad ReportCrash(OSAnalytics)[797] <Notice>: C3. private back-channel connection established
Nov 12 12:24:58 iPad ReportCrash(OSAnalytics)[797] <Notice>: C4. write payload using file descriptor (4)
Nov 12 12:24:58 iPad ReportCrash[797] <Notice>: osa_update: Pid 796 'REDACTED' CORPSE: Persisting
Nov 12 12:24:58 iPad ReportCrash(libMobileGestalt.dylib)[797] <Notice>: Cache loaded with 4644 pre-cached in CacheData and 50 items in CacheExtra.
Nov 12 12:24:58 iPad CommCenter[83] <Notice>: #I New CTServerConnection from pid 797 (conn=0x103e1d770)
Nov 12 12:24:58 iPad CommCenter[83] <Notice>: #I  -- connection has entitlements: <private>
Nov 12 12:24:58 iPad CommCenter[83] <Notice>: #I <private> request: <private>.
Nov 12 12:24:58 iPad CommCenter[83] <Notice>: #I CTServerConnection from pid 797[<private>] is named '<private>'.
Nov 12 12:24:58 iPad CommCenter[83] <Notice>: #I <private> request: <private>, expects reply.
Nov 12 12:24:58 iPad CommCenter[83] <Notice>: #I <private> reply to request '<private>'.
Nov 12 12:24:58 iPad ReportCrash(libMobileGestalt.dylib)[797] <Notice>: _CTServerConnectionCopyFirmwareVersion: CommCenter error: 1:45 (Operation not supported)
Nov 12 12:24:58 iPad CommCenter[83] <Notice>: #I CTServerConnection from pid 797 has closed (conn=0x103e1d770)
Nov 12 12:24:58 iPad ReportCrash(OSAnalytics)[797] <Notice>: C5. payload writing complete, return status 1
Nov 12 12:24:58 iPad osanalyticshelper[554] <Notice>: S5. helper service recieved back-channel payload write result: 1
Nov 12 12:24:58 iPad osanalyticshelper(OSAnalytics)[554] <Notice>: Saved type '109(<private>)' report (4 of max 25) at /private/var/mobile/Library/Logs/CrashReporter/REDACTED-2020-11-12-122458.ips
Nov 12 12:24:58 iPad osanalyticshelper[554] <Notice>: S6. helper service complete with final result 1
Nov 12 12:24:58 iPad ReportCrash(OSAnalytics)[797] <Notice>: C6. report request completed: <private>
Nov 12 12:24:58 iPad ReportCrash(CoreAnalytics)[797] <Notice>: Sending event: com.apple.stability.crash {"appVersion":"5.10","bundleID":"com.REDACTED","exceptionCodes":"UNKNOWN_0x32 at 0x000000010ae347d8","incidentID":"85EF67A7-3377-40A7-83F4-BBE960B8638C","logwritten":1,"process":"REDACTED","terminationReasonExceptionCode":"0x8badf00d","terminationReasonNamespace":"SPRINGBOARD"}
Nov 12 12:24:58 iPad analyticsd[102] <Notice>: Setting new client connection handler. 86 active connections
Nov 12 12:24:58 iPad analyticsd[102] <Notice>: Received event: com.apple.stability.crash {"appVersion":"5.10","bundleID":"com.REDACTED","exceptionCodes":"UNKNOWN_0x32 at 0x000000010ae347d8","incidentID":"85EF67A7-3377-40A7-83F4-BBE960B8638C","logwritten":1,"process":"REDACTED","terminationReasonExceptionCode":"0x8badf00d","terminationReasonNamespace":"SPRINGBOARD"}
Nov 12 12:24:58 iPad analyticsd[102] <Notice>: Aggregated. Transform: StabilityCrashNumerator3 Dirty: 1 Event: com.apple.stability.crash {"appVersion":"5.10","bundleID":"com.REDACTED","exceptionCodes":"UNKNOWN_0x32 at 0x000000010ae347d8","incidentID":"85EF67A7-3377-40A7-83F4-BBE960B8638C","logwritten":1,"process":"REDACTED","terminationReasonExceptionCode":"0x8badf00d","terminationReasonNamespace":"SPRINGBOARD","timestamp":1605201898115319}
Nov 12 12:24:58 iPad analyticsd[102] <Notice>: Aggregated. Transform: StabilityCrashNumerator3WithIncidentID Dirty: 1 Event: com.apple.stability.crash {"appVersion":"5.10","bundleID":"com.REDACTED","exceptionCodes":"UNKNOWN_0x32 at 0x000000010ae347d8","incidentID":"85EF67A7-3377-40A7-83F4-BBE960B8638C","logwritten":1,"process":"REDACTED","terminationReasonExceptionCode":"0x8badf00d","terminationReasonNamespace":"SPRINGBOARD","timestamp":1605201898115319}
Nov 12 12:24:58 iPad analyticsd[102] <Notice>: Persisted Transform: StabilityCrashNumerator3 Dirty: 1
Nov 12 12:24:58 iPad analyticsd[102] <Notice>: Persisted Transform: StabilityCrashNumerator3WithIncidentID Dirty: 1
Nov 12 12:24:58 iPad analyticsd[102] <Notice>: [TransformManager::checkpoint] 14 transforms persisted. 0 failures.
Nov 12 12:24:58 iPad ReportCrash(CoreAnalytics)[797] <Notice>: Received configuration update from daemon (initial)
Nov 12 12:24:58 iPad locationd[64] <Notice>: {"msg":"reduceFreePages", "path":"\134/var\134/root\134/Library\134/Caches\134/locationd\134/sensorRecorder_encryptedC.db", "page_count":16, "freelist_count":0, "loadFactor":"1.000000"}
Nov 12 12:24:58 iPad locationd[64] <Notice>: {"msg":"reduceFreePages", "event":"elapsed", "begin_mach":249174919330, "end_mach":249174957402, "elapsed_s":"0.001586333"}
Nov 12 12:24:58 iPad useractivityd(Sharing)[512] <Notice>: client process changing types to scan for to Handoff, CopyPaste, Boosted
Nov 12 12:24:58 iPad SpringBoard(UserActivity)[510] <Notice>: notifyBestAppsChanged:(null) UASuggestedActionType=0 <private>/<private> opts=(null) when=Thu Nov 12 12:24:58 2020 confidence=1 from=<private>/<private>  (and 18446744073709551615 more best app suggestions)
Nov 12 12:24:58 iPad sharingd[531] <Notice>: Skipping request for enabled: YES, state: PoweredOff, shouldStart: YES, scanForCopyPaste: YES, scanForHandoff: YES
Nov 12 12:24:58 iPad duetexpertd(AppPredictionInternal)[568] <Notice>: Trigger received
Nov 12 12:24:58 iPad locationd[64] <Notice>: {"msg":"Incoming message", "event":"activity", "name":"kCLConnectionMessageMotionActivityQuery", "this":"0x1026e3580", "registrationReceived":0}
Nov 12 12:24:58 iPad locationd[64] <Notice>: os_transaction created: (<private>) <private>
Nov 12 12:24:58 iPad locationd[64] <Notice>: os_transaction releasing: (<private>) <private>
Nov 12 12:24:58 iPad duetexpertd(ProactiveContextClient)[568] <Notice>: Current motion activities: <private>
Nov 12 12:24:58 iPad duetexpertd(CoreLocation)[568] <Notice>: {"msg":"CLLocationManager", "event":"activity", "_cmd":"location", "self":"0x102b199b0"}
Nov 12 12:24:58 iPad locationd[64] <Notice>: {"msg":"client getting effective client name", "bundleId":"", "bundlePath":"\134/System\134/Library\134/PrivateFrameworks\134/CoreParsec.framework"}
Nov 12 12:24:58 iPad duetexpertd(ProactiveContextClient)[568] <Notice>: Querying GPS location now, requesting with precise location: NO
Nov 12 12:24:58 iPad duetexpertd(CoreLocation)[568] <Notice>: {"msg":"CLLocationManager", "event":"activity", "_cmd":"setDesiredAccuracy:", "self":"0x102b199b0", "accuracy":"100.000000"}
Nov 12 12:24:58 iPad duetexpertd(CoreLocation)[568] <Notice>: {"msg":"state transition", "event":"state_transition", "state":"LocationManager", "id":"0x102b199b0", "property":"desiredAccuracy", "old":"100.000000", "new":"100.000000"}
Nov 12 12:24:58 iPad duetexpertd(CoreLocation)[568] <Notice>: {"msg":"CLLocationManager", "event":"activity", "_cmd":"requestLocation", "self":"0x102b199b0"}
Nov 12 12:24:58 iPad duetexpertd(CoreLocation)[568] <Notice>: {"msg":"state transition", "event":"state_transition", "state":"LocationManager", "id":"0x102b199b0", "property":"requestingLocation", "old":0, "new":1}
Nov 12 12:24:58 iPad locationd[64] <Notice>: {"msg":"Incoming message", "event":"activity", "name":"kCLConnectionMessageLocation", "this":"0x1022cc9c0", "registrationReceived":1}
Nov 12 12:24:58 iPad locationd[64] <Notice>: Client /System/Library/PrivateFrameworks/CoreParsec.framework (0x1022cc9c0) is subscribing to notification kCLConnectionMessageLocation
Nov 12 12:24:58 iPad locationd[64] <Notice>: Client /System/Library/PrivateFrameworks/CoreParsec.framework (0x1022cc9c0) is subscribing to notification kCLConnectionMessageLocationUnavailable
Nov 12 12:24:58 iPad locationd[64] <Notice>: client '/System/Library/PrivateFrameworks/CoreParsec.framework' authorized for location; starting shortly
Nov 12 12:24:58 iPad locationd[64] <Notice>: client '/System/Library/PrivateFrameworks/CoreParsec.framework' authorized for location; starting now, desiredAccuracy, 100.0, distanceFilter, -1.0, operatingMode 0, dynamicAccuracyReductionEnabled 0, allowsAlteredAccessoryLocations 0, activityType 0
Nov 12 12:24:58 iPad locationd[64] <Notice>: @ClxClient, register, /System/Library/PrivateFrameworks/CoreParsec.framework, accuracy, 100.0
Nov 12 12:24:58 iPad locationd[64] <Notice>: #Warning Denying process assertion to <private>
Nov 12 12:24:58 iPad locationd[64] <Notice>: os_transaction created: (<private>) <private>
Nov 12 12:24:58 iPad locationd[64] <Notice>: @ClxClient, accuracy, 0, 1, 0, level, Fine, reg?, 1
Nov 12 12:24:58 iPad locationd[64] <Notice>: {"msg":"Sending location to client", "client":"\134/System\134/Library\134/PrivateFrameworks\134/CoreParsec.framework", "location":<private>}
Nov 12 12:24:58 iPad locationd[64] <Notice>: {"msg":"#sbim client arrow state changed", "clientKey":"com.apple.locationd.bundle-\134/System\134/Library\134/PrivateFrameworks\134/CoreParsec.framework", "entityClass":"SystemService", "oldArrowState":"RequestingLocationInformation", "newArrowState":"ReceivingLocationInformation", "dueToDeauthorization":0}
Nov 12 12:24:58 iPad locationd[64] <Notice>: {"msg":"#sbim entity class arrow state changed", "entityClass":"SystemService", "oldArrowState":"RequestingLocationInformation", "newArrowState":"ReceivingLocationInformation", "dueToDeauthorization":0}
Nov 12 12:24:58 iPad locationd[64] <Notice>: {"msg":"#Stream Client interest changed", "notification":"CLLocationProvider_Type::kNotificationLocationFine", "is interested":1}
Nov 12 12:24:58 iPad locationd[64] <Notice>: {"msg":"#Stream Starting location for source", "source":"CLStreamingAwareLocationProviderStateMachine::kLocationSourceLocal", "notification":"CLLocationProvider_Type::kNotificationLocationFine", "include motion":0}
Nov 12 12:24:58 iPad locationd[64] <Notice>: @ClxProvider, start, wifi, desiredAccuracy, 100.0
Nov 12 12:24:58 iPad locationd[64] <Notice>: WlpReg, 1, loccontroller
Nov 12 12:24:58 iPad locationd[64] <Notice>: @ClxProvider, start, simulated, desiredAccuracy, 100.0
Nov 12 12:24:58 iPad locationd[64] <Notice>: #techstatus,signalling
Nov 12 12:24:58 iPad locationd[64] <Notice>: @WifiLogic, entry, register, notification, Location, lsb, 1, 1, 1
Nov 12 12:24:58 iPad locationd[64] <Notice>: os_transaction created: (<private>) <private>
Nov 12 12:24:58 iPad locationd[64] <Notice>: #techstatus,posting notification
Nov 12 12:24:58 iPad locationd[64] <Notice>: @WifiLogic, handleInput, Client::Registration
Nov 12 12:24:58 iPad symptomsd(CoreLocation)[123] <Notice>: {"msg":"CLCopyTechnologiesInUse", "event":"activity"}
Nov 12 12:24:58 iPad locationd[64] <Notice>: #techstatus,enquired,sz,2,gpsClientActive,0,gpsHwActive,0
Nov 12 12:24:58 iPad aggregated(CoreLocation)[70] <Notice>: {"msg":"CLCopyTechnologiesInUse", "event":"activity"}
Nov 12 12:24:58 iPad locationd[64] <Notice>: #techstatus,enquired,sz,2,gpsClientActive,0,gpsHwActive,0
Nov 12 12:24:58 iPad locationd[64] <Notice>: {"msg":"CLWifi1SystemLogic::apply", "event":"elapsed", "begin_mach":249179491734, "end_mach":249179547495, "elapsed_s":"0.002323375", "event":"Client::Registration", "now_s":"626894698.451622009"}
Nov 12 12:24:58 iPad locationd[64] <Notice>: @WifiFlow, outcome, nofix
Nov 12 12:24:58 iPad locationd[64] <Notice>: @ClxWifi, Fix, 0, ll, N/A
Nov 12 12:24:58 iPad locationd[64] <Notice>: os_transaction releasing: (<private>) <private>
Nov 12 12:24:58 iPad locationd[64] <Notice>: {"msg":"#Stream Received notification", "notification":"CLLocationProvider_Type::kNotificationLocationUnavailable"}
Nov 12 12:24:58 iPad locationd[64] <Notice>: {"msg":"#Stream Source no longer available", "source":"CLStreamingAwareLocationProviderStateMachine::kLocationSourceLocal"}
Nov 12 12:24:58 iPad locationd[64] <Notice>: {"msg":"#Stream Starting location for source", "source":"CLStreamingAwareLocationProviderStateMachine::kLocationSourceLocal", "notification":"CLLocationProvider_Type::kNotificationLocationFine", "include motion":0}
Nov 12 12:24:58 iPad wifid(CoreLocation)[49] <Notice>: {"msg":"#CLLocationManager invoking #delegate - location unavailable", "self":"0x131e12900", "delegate":"0x131e12d60", "selector":"locationManager:didFailWithError:"}
Nov 12 12:24:58 iPad wifid(WiFiPolicy)[49] <Notice>: -[WiFiLocationManager locationManager:didFailWithError:]: error: Error Domain=kCLErrorDomain Code=0 "(null)"
Nov 12 12:24:58 iPad destinationd(CoreLocation)[209] <Notice>: {"msg":"#CLLocationManager invoking #delegate - location unavailable", "self":"0x101204190", "delegate":"0x101106200", "selector":"locationManager:didFailWithError:"}
Nov 12 12:24:58 iPad navd(CoreLocation)[599] <Notice>: {"msg":"#CLLocationManager invoking #delegate - location unavailable", "self":"0x10020fa20", "delegate":"0x10020fe10", "selector":"locationManager:didFailWithError:"}
Nov 12 12:24:58 iPad navd[599] <Error>: <private> failed while leeching with error: <private>

@kodejack thanks for the logs! First quick look there's nothing in or out process that clearly explain why the process has not launched inside the 20 seconds limit.

@dalexsoto did mention to me that loaded libraries are arm64e even if the process itself is arm64. Not sure if that's an issue or just an updated way to show the information.

0x102b4c000 - 0x10557ffff REDACTED.Mobile.iOS arm64  <ce7bc43f91e83838925615408c5813fc> /var/containers/Bundle/Application/ACDDB724-517E-4FC1-B07E-DEAEE9FE213A/REDACTED.Mobile.iOS.app/REDACTED.Mobile.iOS
0x105ebc000 - 0x105f2bfff dyld arm64e  <a5f65ef3bd32370b9821b3e9cda294d2> /usr/lib/dyld
...

sorry I mean @mlancione above.

Looking again at the forum post ot seems to affect only newer phones, i.e. those with arm64e CPU. I would guess there's a bug, on Apple side, where the app is _optimized_ for an unsupported architecture. If you have not already I would file a feedback issue with Apple so they can confirm this.

We have posted an issue to Apple as well, I'll pass on the comment about arm64e. I'll get logs from the device directly.

@spouliot and @kodejack - Same issue with us, and same information recorded in the crash dump about arm64 / arm64e architecture:

Binary Images:
0x104338000 - 0x105faffff REDACTED.Mobile.iOS **arm64**  <60fc0967b84d315cba71ce474a67af15> /var/containers/Bundle/Application/258A589B-591B-4E47-B78F-D99BFD40508C/REDACTED.Mobile.iOS.app/REDACTED.Mobile.iOS
0x106580000 - 0x1065effff dyld **arm64e**  <a5f65ef3bd32370b9821b3e9cda294d2> /usr/lib/dyld
0x1855eb000 - 0x18562dfff libdispatch.dylib **arm64e**  <3277bf1eb99436099b30e0186bbf3c25> /usr/lib/system/libdispatch.dylib
... etc

@mlancione unfortunately, we tried the "Offload App" workflow that you suggested, and this didn't fix the issue. Our app still crashes.

@stewart-rae thanks for confirming! Multiple, consistent reports are helpful, otherwise we might end up investigating the wrong things :-)

I know you are aware @spouliot but just to avoid duplicate issues, there is also an one opened on Xamarin.Forms

@spouliot Not sure if it helps: I'm working at Microsoft and have 2 customer apps affected by this. In both cases the apps are built by Microsoft. So it is easy to give you access to the full apps and source code internally.

None of the apps are using a MDM SDK.
One app is reading AppConfig, the other not.
The only libaries in common are Xamarin.Forms and Xamarin.Core.
Both apps use sqlite but different libs: SQLitePCLRaw.bundle_e_sqlite3 and SQLitePCLRaw.bundle_green
I have the impression that the app crashes before any Xamarin.Forms, SQlite or AppConfig code is invoked.

Tried the "Offload App" workflow too did not seem to fix this issue.

I have attached the crash log for the App @kodejack and I are working on:
LogOfiOSAppCrash142MDM.txt

I have redacted the app name and bundle id with REDACTED.APP.NAME and REDACTED.BUNDLE.ID if you want to search the log.

Here are some more details for the app:

  • Using native Xamarin.iOS we are not using Xamarin.Forms - not sure if this is important
  • The App is deployed from various environments and then uploaded to MDM (UAT, SIT, Pre-Prod) - these all work
  • The difference with this app and the others is it the AppStore version and has been uploaded to TestFlight first then MDM, this is used to get automatic updates from MDM - this is where I think the issue lies

I confirm we are running into this issue as well, or at least a customer is. Again this is an app normally deployed via App Store but they are using MDM. Our list of binary images echoes those above, in that our app is arm64 whereas others loaded appear to be arm64e.

The symptoms are the same: iOS kills our app after 20 seconds of not doing anything. The symbollicated stack trace shows it never really gets anywhere, sitting in mono code:

Thread 0 name: tid_407 Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 ??? 0x0000000102034018 0 + 4328734744
1 AppNameRedacted 0x0000000100fd5e40 wrapper_runtime_invoke_object_runtime_invoke_dynamic_intptr_intptr_intptr_intptr + 272
2 AppNameRedacted 0x0000000101aa3848 mono_jit_runtime_invoke + 18593864 (mini-runtime.c:3165)
3 AppNameRedacted 0x0000000101b60640 mono_runtime_try_invoke + 19367488 (object.c:3161)
4 AppNameRedacted 0x0000000101b5f310 mono_runtime_class_init_full + 19362576 (object.c:552)
5 AppNameRedacted 0x0000000101a76b9c init_method + 18410396 (aot-runtime.c:4712)
6 AppNameRedacted 0x0000000101a8a1c4 mini_llvm_init_method + 18489796 (llvmonly-runtime.c:797)
7 AppNameRedacted 0x0000000101048194 mono_aot_mscorlib_init_method + 64
8 AppNameRedacted 0x00000001010ab030 mscorlib_System_SystemException__ctor_string + 8138800 (SystemException.cs:24)
9 AppNameRedacted 0x00000001010bf038 mscorlib_System_OutOfMemoryException__ctor_string + 8220728 (OutOfMemoryException.cs:32)
10 AppNameRedacted 0x0000000100fd5e40 wrapper_runtime_invoke_object_runtime_invoke_dynamic_intptr_intptr_intptr_intptr + 272
11 AppNameRedacted 0x0000000101aa3848 mono_jit_runtime_invoke + 18593864 (mini-runtime.c:3165)
12 AppNameRedacted 0x0000000101b5ed24 mono_runtime_invoke_checked + 19361060 (object.c:3220)
13 AppNameRedacted 0x0000000101afa798 create_exception_two_strings + 18950040 (exception.c:207)
14 AppNameRedacted 0x0000000101afa5f4 mono_exception_from_name_two_strings_checked + 18949620 (exception.c:266)
15 AppNameRedacted 0x0000000101acacf0 create_domain_objects + 18754800 (appdomain.c:247)
16 AppNameRedacted 0x0000000101aca330 mono_runtime_init_checked + 18752304 (appdomain.c:354)
17 AppNameRedacted 0x0000000101aa30d8 mini_init + 18591960 (mini-runtime.c:4391)
18 AppNameRedacted 0x0000000101a8504c mono_jit_init_version + 18468940 (driver.c:2875)
19 AppNameRedacted 0x0000000101c35ec0 xamarin_main + 20242112 (monotouch-main.m:428)
20 AppNameRedacted 0x000000010090c18c main + 147852 (main.m:66)
21 libdyld.dylib 0x00000001882bf6c0 0x1882be000 + 5824

Thread 1:
0 libsystem_pthread.dylib 0x00000001d0e03754 0x1d0df9000 + 42836

Thread 2 name: SGen worker
Thread 2:
0 libsystem_kernel.dylib 0x00000001b4efd1ac 0x1b4ed5000 + 164268
1 libsystem_pthread.dylib 0x00000001d0dfe458 0x1d0df9000 + 21592
2 AppNameRedacted 0x0000000101c020d4 thread_func + 20029652 (sgen-thread-pool.c:196)
3 libsystem_pthread.dylib 0x00000001d0dfab40 0x1d0df9000 + 6976
4 libsystem_pthread.dylib 0x00000001d0e03768 0x1d0df9000 + 42856

I was able to test the deployed build from TestFlight not going through MDM and it doesnt crash on startup, it would appear that something in MDM is causing it to hit the time limit on start up?

I thought it might be a combination of MDM, loading a config and other startup tasks which is causing the issue but an iPhone 6S Plus, which I would assume would take longer to start up the app, does not crash...

Just to note this issue doesnt happen on:
iPhone 6s Plus with iOS 14.2
iPhone 7 Plus with iOS 14.2

This is all very speculative but it would appear that the issue is pointing towards MDM and the arm64e CPU devices?

This bug is extremely critical from my side.
About 4000 devices (iPhone 11 and XR) at one of my customers, who uses Intune to deploy a Xamarin IOS custom app, are affected by this problem.
To replicate, I have referenced my public store apps and ABM custom apps (same Xamarin IOS core as public app) in my Intune portal.
I have successfully deployed these applications on 13.x and 14.1 devices.
I then migrated the devices to 14.2 and reproduced the problem: The splash screen is displayed for a few seconds, then the application dies.
Iphones 7,8 & X are not affected. I reproduced on 11 and XR.
You can test with my main app: https://apps.apple.com/app/sociabble/id1003844345

Link to issue reported on Apple's dev forums:
https://developer.apple.com/forums/thread/666399

Everyone Please file a feedback ticket with Apple with your specific information.

Also make sure to link this https://feedbackassistant.apple.com/feedback/8895585 ticket (in the text) so they can all be seen as a single issue.

Thanks!

@spouliot : We had raised a ticket with Apple's Developer Technical Support and shared all this info.

This is the reply from Apple's DTS engineer :

Us:

One thing we have noticed is, the main process is 'arm64', but the
rest of the libraries are all 'arm64e'. Is this significant at all?

Apple's reply
arm64e binaries are valid as long as they are Apple loaded binaries, which yours are.
arm64e binaries are only an issue if you are creating your app with this architecture, which you are not.

We shared these logs :

8 (null) in plcrash::MS::async::dwarf_cfa_state_iterator

long long, long long>::next+ 27004828 (unsigned int,
plcrash::MS::async::plcrash_dwarf_cfa_reg_rule_t
, unsigned long
long*) ()

9 (null) in plcrash::MS::async::dwarf_cfa_state_iterator

long long, long long>::next+ 26881808 (unsigned int,
plcrash::MS::async::plcrash_dwarf_cfa_reg_rule_t
, unsigned long
long*) ()

10 (null) in xamarin_release_block_on_main_thread ()

11 (null) in plcrash::MS::async::dwarf_cfa_state_iterator

long long, long long>::next+ 412676 (unsigned int,
plcrash::MS::async::plcrash_dwarf_cfa_reg_rule_t
, unsigned long
long*) ()

12 (null) in 0x18562e000 ()

Apple's reply : First, it does look like you are using xamarin here, "xamarin_release_block_on_main_thread," if I am correct I should let you know that DTS does not support Xamarin and this is something you would have to contact the vendor about.

Our App and many users are impacted by this issue. Is there any solution to this ?

Hi! We are wondering the same as above. Thousands of users can be affected. Is the rootcause found? We follow this thread for updates :)

Similar issues on iOS 14.2 here as well. We have customers with MDM deployments and most have a similar issue: The app hangs during startup and closes after 15 seconds (which implies the OS kills the app due to the 15 second startup limit). The logs indicate a hang on wrapper_runtime_invoke_object_runtime_invoke_dynamic_intptr_intptr_intptr_intptr (same as earlier logs shared in this issue).

So far the MDM environments where this issue occurs are:
-MobileIron
-Microsoft Intune
-VMWare Workspace ONE

The issue can seemingly occur on multiple kinds of iOS devices (we have received reports from customers running into issues on the iPhone 7, 2nd gen iPhone SE, iPhone XR and iPhone 11).
There have been cases where within a single MDM environment some iOS 14.2 users could open the app while some couldn't, we haven't been able to establish a pattern there. (It turns out the pattern was ARM64e devices)

Running our app in these MDM environments on iOS 14.1 (and earlier) still works as expected.

@leonluc-dev so far you are the only one reporting this issue happening on earlier arm64 CPU. Other reports are on newer phones only, with arm64e CPU. Please make sure to mention that on the feedback you supply to Apple and don't forget to link to our own ticket https://feedbackassistant.apple.com/feedback/8895585

From this Apple forum thread it appears that NativeScript apps may also be experiencing this issue:
https://developer.apple.com/forums/thread/666045?answerId=646229022&page=1#646340022

This NativeScript thread describes a similar iOS 14 issue (but not specifically iOS 14.2):
https://github.com/NativeScript/NativeScript/issues/8665

In that thread it is pointed out that the Apple iOS 14 Release Notes has this "Third Party App" Known Issues warning (https://developer.apple.com/documentation/ios-ipados-release-notes/ios-ipados-14-release-notes):

Apps using the NativeScript framework might quit unexpectedly on launch. NativeScript performs an unsafe operation to determine if an arbitrary pointer is an Objective-C object pointer. You can temporarily resolve this issue by using object_getClass(_:) instead of reading the isa directly; however, update this code to avoid checking whether arbitrary pointers are Objective-C object pointers. (62913064)

Is this at all relevant to our issue?

@spouliot Apologies. It seems the iPhone 7 report was a report mixup. So far we've been able to confirm the issue at customers using the 2nd gen iPhone SE, iPhone XR or iPhone 11 (all of them ARM64e devices)

@mlancione that's recent but not new in 14.2. AFAIK this should not be an issue but we'll be double-checking this. Thanks!

We are seeing this issue with the following MDMs as well:

  • Airwatch

We are seeing this issue on an AirWatch MDM deployed xamarin app to an iPhone XR running iOS 14.2.

Our app works fine when not deployed via AirWatch MDM (downloaded straight from app store).

Our app works fine when deployed via AirWatch MDM to iphone XR running iOS 14.1 and below.

Same problem here and this is very critical for us (we are using Intune as MDM)

I can confirm that the app crash also happens in iOS 14.3 beta 1.

Is everyone experiencing the app crash also using the SkiaSharp library?

@mlancione : We are not using SkiaSharp library in our app but still experiencing the issue

@mlancione : No we are not using SkiaSharp and having the same problem.

Only for curiosity:

  • Did your crash reporting work on the issue? Ours did not as it is initialized in the 1st line of our main method, which is not executed at all ;-) I had to ask our customers to send crash reports from their iPad Pro manually, really nasty bug.

@onyx00

  • Did your crash reporting work on the issue? Ours did not as it is initialized in the 1st line of our main method, which is not executed at all ;-) I had to ask our customers to send crash reports from their iPad Pro manually, really nasty bug.

Our crash reporting (AppCenter) doesn't work either since no code is executed in the DidFinishLaunching method.

We also do not use SkiaSharp.
The only image processing library we use in the affected app is SixLabors.ImageSharp.

We are also experiencing the same problem

If your app is published as a Custom App (as most of ours are) and therefore not visible on the App Store, using redemption codes from Apple Business Manager (versus relying on Managed Licenses) also allows the app to launch. This may be a temporary option for business users that have already upgraded to iOS 14.2 and cannot launch apps distributed via MDM using Managed Licenses.

@rbanker I believe your workaround only works if the MDM configuration has allowed the device access to the App Store app. If the App Store app is restricted the user is displayed an Alert asking them to tap the "Show in App Store" button which does nothing.

@rbanker I believe your workaround only works if the MDM configuration has allowed the device access to the App Store app. If the App Store app is restricted the user is displayed an Alert asking them to tap the "Show in App Store" button which does nothing.

Entirely possible. Just adding what was working in our scenario. We have a large BYOD customer-base and my experience is that in BYOD environments, it's not common to lock users out of the App Store. YMMV.

The app crash also happens in iOS 14.3 beta 2.

We know it's something that Apple does to the binaries.

  1. Installing an application locally works (side load);
  2. Installing an application from the AppStore works;
  3. Installing an application using "Apple Configurator 2" does not work (unsupervised device, so not really/strictly MDM)

In both 2 and 3 the application is given to Apple, modified on their servers before being sent back into devices. That process is out of our control but we were able to get the binary returned from 3.

We are independently trying to figure out (reverse engineering) what Apple did to our binaries while waiting for replies from Apple.

If you have not already please file your own feedback (or DTS) issue with Apple. Make sure to link this https://feedbackassistant.apple.com/feedback/8895585 ticket (in the text) so they can all be seen as a single issue. Thanks!

Apple asked us to create an IPA of our app for ad-hoc distribution and deployed via Apple Configurator 2 with MDM profile on a targeted device, which worked and didn't produce any crash.

So, as per this test, we didn't go via the App store. We added an ad-hoc IPA to Apple Configurator 2 and that worked.

After these results, Apple asked us to create a bug report.

@spouliot : I have added https://feedbackassistant.apple.com/feedback/8895585 in my bug report as well.

@akashvashisht thanks! It seems you have to use "Apple Configurator 2" to install an app downloaded from the App Store to duplicate the problem.

IOW I also did not have problem to use Configurator to install applications that I built myself. The app must go thru Apple's servers to misbehave - but only for MDM like scenarios as normal/AppStore installation is also fine.

@spouliot That’s correct !

If you have not already please file your own feedback (or DTS) issue with Apple. Make sure to link this https://feedbackassistant.apple.com/feedback/8895585 ticket (in the text) so they can all be seen as a single issue.

Done, and linked to this ticket and the feedback number. Our clients in multiple countries have been hit by this issue in the last 24 hours when they updated to iOS 14.2.

Hi! We have also reported to Apple feedback. https://feedbackassistant.apple.com/feedback/8907155, and referred to above listed ticket and this one.

I have submitted a ticket to Apple as well, referring to the master ticket above.

https://feedbackassistant.apple.com/feedback/8907917

We also have thousands of clients experiencing the same issue using several different MDMs. After some internal testing we were able to find:

  • iPhone XR - fail on startup
  • iPhone 11- fail on startup
  • iPhone 6S - works

All devices running iOS 14.2.

Hope we can find a workaround or a solution for this soon!

We have been trying different things also, with no luck. Has anyone tried Xcode 12.3 Beta from Apple's Dev site? or is this uncharted territory?

To add to our earlier findings, we can also reproduce this using "Apple Configurator 2" on an iPhone 12 Mini. We've opened a ticket on the Apple Feedback site mentioning the issue linked by @spouliot as suggested.

We are experiencing the issue with one Xamarin app. We have tickets open with Microsoft and Apple. We have used this app for many years so something notable had to change in 14.2. 14.3 beta 2 also has the issue. I am curious if this could be related. https://www.macstories.net/linked/ios-14-2-jit-and-emulation-at-full-performance/

Having the same problem. 3000 users experiencing this issue. The MDM used is VMWare AirWatch, don't know if that helps. As people said here, only on iOS 14.2 onward.
I have reported the issue on the Feedback Assistant: https://feedbackassistant.apple.com/feedback/8915470

Hope this is solved soon.

I am curious if this could be related. https://www.macstories.net/linked/ios-14-2-jit-and-emulation-at-full-performance/

@jpsweet it's unlikely since

  • we do not JIT on device, it's all AOT (or interpreted if you enabled that); and
  • it's supposed to be a relaxed check

That being said there's a bunch of unlikely things that were/are being investigated, we have run out obvious a while ago.

Are Apple assisting in any way? I presume they could debug this quite easily if they chose to.

@davidhedley - we have had complete radio silence from Apple for a number of days now.
We have recently recompiled our app with Xcode 12.2 (now available in the MS build agent) and shall try releasing it, but we are skeptical as to whether this will fix the issue.
In the mean-time, how is everyone else going with this problem? Any insights?

We have found that reverting to the store version has resolved the issue as well. We have not tried to recompile/resign the app yet.

Has anyone else tried recompiling with Xcode 12.2 (or 12.3 beta) and releasing their app through the App Store?

@davidhedley - we have had complete radio silence from Apple for a number of days now.
We have recently recompiled our app with Xcode 12.2 (now available in the MS build agent) and shall try releasing it, but we are skeptical as to whether this will fix the issue.
In the mean-time, how is everyone else going with this problem? Any insights?

We are still waiting on the community/Apple/Xamarin to provide guidance on next steps. Our users are still impacted

@stewart-rae

Has anyone else tried recompiling with Xcode 12.2 (or 12.3 beta) and releasing their app through the App Store?

We recently had to fix an unrelated bug and released a Xcode 12.2 based version of our app. It did not fix this MDM deployment issue.
Haven’t tested 12.3 beta yet.

For now we just recommended our users to download the app directly from the App Store and avoid MDM deployments.
It’s absolutely not ideal (impossible even in certain restricted enterprise environments our customers have) but currently I know of no other workaround.

@leonluc-dev thanks for letting us know. We figured it was a long shot.

We have our own feedback and DTS issue with Apple. We have been providing data and answering Apple's questions. We did not get any actionable answers or hints so far. Our own investigation is being done separately - but, like all developers, we are unable to debug apps that have been processed by the App Store.

Has anyone else tried recompiling with Xcode 12.2 (or 12.3 beta)

Xcode 12.2 has been used extensively.

Xcode 12.3 is currently in beta and can't be used to submit to App Store (only TestFlight, if enabled). We do know that iOS 14.3 beta (1 and 2) has the same issue.

Considering that the change happens between app submission (working .ipa) and the download to devices (bad .ipa) it's _unlikely_ that an update to Xcode would change things.

Mitigation

  • Install app using the App Store
  • Avoid updating to iOS 14.2 (this does not happen on any device using iOS 14.1)
  • Avoid using recent devices with arm64e CPU (or at least avoid updating them to 14.2)
  • Downgrade affected devices to iOS 14.1 - warning: potential for data-loss

If you have not done so please file feedback with Apple. This show how widespread the issue is and help its prioritization. Whenever you do please make sure to link your feedback with our own (https://feedbackassistant.apple.com/feedback/8895585), so it can be seen as a single issue, affecting many applications and multiple end-users. Thanks!

Thanks for the update @spouliot !

Has anyone tried to replicate this issue with an Enterprise signed Xamarin app deployed from MDM?

Yes. App works fine this way. Only an issue when coming from app store

via MDM for me. 

Our customers had no success with the offloading-workaround. Distribution with an enterprise certificate seems to work for us as well. Filed a report to Apple last week but got no reply yet.

Filed a report to Apple last week but got no reply yet.

As did we, and no response. A note in the feedback tool says they're unavailable until Monday November 30 for Thanksgiving, which is - quite frankly - unacceptable.

Hi, we get this error also, when we DSYM'd our logs we got this stacktrace:

wrapper_runtime_invoke_object_runtime_invoke_dynamic_intptr_intptr_intptr_intptr (in Redacted.iOS) + 272
mono_jit_runtime_invoke (in Redacted.iOS) (mini-runtime.c:3165)
mono_runtime_invoke_checked (in Redacted.iOS) (object.c:3220)
create_exception_two_strings (in Redacted.iOS) (exception.c:207)
mono_exception_from_name_two_strings_checked (in Redacted.iOS) (exception.c:266)
create_domain_objects (in Redacted.iOS) (appdomain.c:247)
mono_runtime_init_checked (in Redacted.iOS) (appdomain.c:354)
mini_init (in Redacted.iOS) (mini-runtime.c:4391)
mono_jit_init_version (in Redacted.iOS) (driver.c:2875)
xamarin_main (in Redacted.iOS) (monotouch-main.m:428)
main (in Redacted.iOS) (main.m:218)

That is good example of why I asked about the JIT changes in iOS 14.2.

"mono_jit_runtime_invoke"

JIT is not normally used but that is now possible in iOS 14.2 so maybe there is code path that is mistakenly firing.

@spouliot thoughts?

In addition to the developer feedback my customer opened a ticket at AppleCare Enterprise Customer Support. They got a response within a few hours that Apple Engineering is aware of the issue and received several similar reports. According to the response "Engineering is currently actively investigating these reports and working with the 3rd party teams involved to identify a root cause". We will see how long "actively" takes. But the fact that they are working on it sounds promising.

On the developer feedback tickets we have not gotten any response, too.

anyone have an update? it's been over 2 weeks that our company is having this issue.

Our company has been in contact with Microsoft who in turn has been in contact with Apple. They've been giving us almost daily updates but haven't made any real progress. Both are aware of the issue, have reproduced, and are actively engaged in figuring out cause and fix.

Microsoft actually referenced this thread in one of their communications.

Not much of an update but that's all I have.

Thanks @bjenkins12

The issue persists on iOS 14.3 Beta 3.

Microsoft actually referenced this thread in one of their communications.

Could you give us a link or a reference? It might help us reassure our customers for whom the situation has become very complicated. Thank-you.

Hi everybody.

I just found this issue. I think we are also facing this problem with our app.
The difference though - there is not always an MDM involved.

We're partly working with Intune and Meraki, but many of our freelance workers use their own devices and are getting the app directly from the store. It still crashes.

Unfortunately I don't have a test device where this issue occurs until next week when my colleague will be back in the office.
I'm also not that experienced to be honest, maybe someone could have a look at the attached log. As far as I see it looks more or less like the same issue. An excerpt from the attached log:
"termination" : {"flags":6,"code":2343432205,"namespace":"SPRINGBOARD","description":"SPRINGBOARD, <RBSTerminateContext| domain:10 code:0x8BADF00D explanation:process-launch watchdog transgression: application<REDACTED>:2333 exhausted real (wall clock) time allowance of 20.00 seconds | ProcessVisibility: Background | ProcessState: Running | WatchdogEvent: process-launch | WatchdogVisibility: Foreground | WatchdogCPUStatistics: ( | \"Elapsed total CPU time (seconds): 29.310 (user 8.880, system 20.430), 24% CPU\", | \"Elapsed application CPU time (seconds): 19.979, 17% CPU\" | ) reportType:CrashLog maxTerminationResistance:Interactive>"},

UPDATE
I just called my colleague again - and guess what: he reinstalled the App from the store and out of the sudden it is working again.
I have no idea why this is. We changed nothing, it is the exactly same App version as before.
(we already tried reinstalling last week when the issue occured first - it did not help then)

Not sure if this helps anyone, if I can do anything please let me know.

crashlog.txt

A recent post on the Apple Developer Forum (https://developer.apple.com/forums/thread/666399?answerId=650653022#650653022) indicates that a cause has been found related to security and memory management in iOS and that this change will require a fix in Xamarin.iOS. It goes on to say that Microsoft has a root cause and is actively testing a fix. Is anybody from Microsoft able to chime in and confirm/deny this? Thanks!

We are now fairly sure the root issue is identified (testing is ongoing). IOW the information that Apple shared with us does match what people describe in this thread.

Context

Xamarin.iOS depends on small pieces of machine code called trampolines for a variety of functions. The runtime uses some low-level code to support an _infinite_ (dynamic) number of trampolines. This is the piece that stopped working.

In older versions of Xamarin.iOS (think MonoTouch) the AOT compiler used a fixed number for each type of trampolines. Going back to the old behaviour solve the issue. This can be done by using the --aot=nopagetrampolines option (but continue reading).

The main problem is that apps can run out of trampolines and crash/abort with a message like:

Ran out of trampolines of type %d in '%s' (limit %d)

The AOT compiler cannot know how many, of each type, of trampoline will be needed (it's known at runtime) and generating trampolines increases the executable size, so using extremely large numbers of them is not a good solution.

Suggested Workaround

Add the following options to the Additional mtouch arguments inside your application options.

--aot=nopagetrampolines,ntrampolines=40960,nrgctx-trampolines=40960,nrgctx-fetch-trampolines=256,ngsharedvt-trampolines=4096,nimt-trampolines=4096

UPDATE You might already have some additional arguments. Make sure you're appending the ones above and that you have a space between any existing and new ones. IOW the --aot= options are comma separated but mtouch options are space separated.

Screen Shot 2020-12-03 at 10 15 56 AM

Those options should be added to all (Debug/Release/...) project configuration for device builds, which is where the AOT compiler is being used. IOW it's not needed for simulator builds.

Testing

Once you produce a build you must re-test your application. Running out of trampolines happens at runtime and will crash (abort) the application. The console (Console.app) logs will show something like:

Ran out of trampolines of type X

If this happens you need to increase the amount for the mentioned type (X) of trampoline. You can try to double the existing amount (suggested above).

Trampoline types vs option names

  • normal trampolines (type 0) -> ntrampolines=X
  • rgctx trampolines (type 1) -> nrgctx-trampolines=X
  • imt trampolines (type 2) -> nimt-trampolines=X
  • gsharedvt arg trampolines (type 3): ngsharedvt-trampolines=X
  • unbox arbitrary trampolines (type 5): nunbox-arbitrary-trampolines=X
  • rgctx fetch trampolines -> nrgctx-fetch-trampolines=X

Example

Ran out of trampolines of type 2 (limit 4096)

  • Trampoline 2imtnimt-trampolines
  • Change the option from nimt-trampolines=4096 to nimt-trampolines=8192
  • Rebuild and re-test the application

We're aware this information is a bit raw and not very easy to consume. The goal was to get the information, including a workaround, out fast. Expect this post to be edited/refined until more appropriate documentation becomes available.

Big thanks to @vargaz who wrote most of this post. All mistakes are mine :-)
Also a huge thanks to everyone, here in this post, at Apple and Microsoft, who help to diagnose, debug and find a solution.

@spouliot — thanks for all the info, but how does the whole MDM vs App Store deployment aspect fit into this trampoline issue?

I believe @spouliot is saying there was a bug in Xamarin related to the trampoline logic that appeared in the MDM case that was exposed when JIT restrictions were removed in 14.2. He also stated the fix requires app devs to make a change to impacted apps as noted in article, then test and republish.

@sebrichards short story: You give Apple an app.ipa but what gets into the actual devices goes thru different (hardening) processes (no clue how many possibilities exists). In this case what you download from the App Store or thru an MDM (like using Apple Configurator 2) is different - at least if the device is running iOS 14.2 on an arm64e.

@jpsweet no, it's not a bug in Xamarin, it's a behavioural change from Apple. Believe me I wish it was a bug because it would mean we could fix it (and not fall back to the older code). It's also totally unrelated to any JIT restrictions removal (it's an additional restriction) that people mentioned were part of iOS 14.2

@spouliot thanks for the explanation and workaround, we are about to try it.

One question: does the trampoline limit tuning have to be done on an affected device (iOS 14.2, MDM, iPhone XS/XR & newer), or does swapping to static trampoline limits expose those limits being exceeded irregardless of those conditions? We are particularly interested in the MDM factor as running it through MDM for every iteration will be a slow slog.

@arevellfraedom if you build with the suggestion options then all your builds will use the "static" trampolines. IOW you don't need to submit or use the MDM to find out if your app works fine with the limits.

However different configuration (debug/release, linker, AOTing with mono/llvm) can have some impact on the number of trampolines required. You better test using a release builds (the config you're planning to archive/submit to Apple).

@arevellfraedom if you build with the suggestion options then all your builds will use the "static" trampolines. IOW you don't need to submit or use the MDM to find out if your app works fine with the limits.

However different configuration (debug/release, linker, AOTing with mono/llvm) can have some impact on the number of trampolines required. You better test using a release builds (the config you're planning to archive/submit to Apple).

Fantastic, thank you

Why is it only AppStore builds via MDM on iOS 14.2 on arm64e supporting devices?

I assume once the fix is finalized we'll see a package hotfix? I appreciate the work-around but it seems to be quite involved and prone to risk.

I assume once the fix is finalized we'll see a package hotfix? I appreciate the work-around but it seems to be quite involved and prone to risk.

Doesn't sound like it - read spouliot's reply earlier: https://github.com/xamarin/xamarin-macios/issues/10086#issuecomment-738279753

Xamarin.iOS depends on small pieces of machine code called trampolines for a variety of functions. The runtime uses some low-level code to support an infinite (dynamic) number of trampolines. This is the piece that stopped working.

Thanks for the update. Is this piece something that Apple plans to fix in a future release or is this actually a "behavior" change going forward?

It looks like a permanent behavior change.

@spouliot @vargaz Thank you for this information! I’d like to better understand the risks involved with this workaround. Can you provide any insight into what areas of risk are most important to consider when re-testing to tune the trampoline limits? Would different device architectures or OS versions potentially crash at different limits? Could the size of the data set our application is working against have an impact on the limits needed? Would there be any specific areas of an application that may be more prone to running into the trampoline limits than others? I am assuming the crash would not necessarily happen when the application is launched and that our QA team would need to test the new version thoroughly after we find limits that seem to work, but I am not sure where to tell them to focus their testing for this beyond our standard regression testing.

@spouliot
Thanks for sharing the workaround. Is there a fix coming from Xamarin as part of Xamarin.IOS/Mono/VS upgrades or we have to use this workaround in long term?
I would like to know the plan so that I can well inform my users, customers and management

If this is an intended behaviour change from Apple then it seems odd that it would only manifest itself in very specific deployment circumstances. Does this mean that we are just "lucky" that the apps continue to work when deployed by other means, and that in some future iOS update the app downloaded directly from the App Store will also fail in the same way?

It is sounding suspiciously like a bug in Apple's "hardening" process that they are unwilling to admit to or fix.

@spouliot - Do you consider the issue is closed now and this is the proposed solution? Or are you still trying to find another solution? If this is the final solution then this comment asks some very pertinent questions. I, for one, have no idea what consumes trampolines and therefore what parts of our application are likely to exhaust the pools.

A quick scan of stackoverflow shows many Xamarin issues in the past with trampolines being exhausted and questions about what to do about it, which is presumably why a dynamic method was developed. We would not want to willing move back to a situation where the app can fail at any time with what should be an avoidable error.

Trampolines are used by many other languages, including Objective C, so it seems likely there are other "Apple approved" mechanisms of achieving the same results.

Trampolines are just a name we use for some of our implementation techniques, they are probably not the same as objc trampolines.

Thanks for the information and the workaround.

While the workaround works for now we hope a Xamarin SDK (or Apple) based solution will release in the future, since this is a lot of potential extra maintenance and testing for any future builds of our apps.

We shared the workaround _early_ because we wanted to unblock you and your customers as soon as possible. The investigation is still ongoing, both on our and Apple sides. Things might change and we will update this issue if/when it does.

it seems odd that it would only manifest itself in very specific deployment circumstances.

We don't have all the details. However this was raised several times, as we wanted to be sure this was the right/only issue, and we got a (high-level) picture detailed enough to understand why it affects MDM (and not AppStore) deployed apps. The different processes match the facts we are seeing.

Do you consider the issue is closed now

No. I removed the need-info label but did not close the issue.

and this is the proposed solution?

This is the only known solution at the moment.
It's too early to talk about if/when a different solution will become available.

Testing

@vargaz feel free to correct me / expand on the subject

Trampolines are code related. If you run more code (not code more often) then you'll need more of them (at least never less). So ideally a tester would, inside a single execution session, ensure the maximum of the code has executed.

It is possible your existing test plans already include scenarios that would cover this. Or maybe they will need to be executed serially without restarting the application.

We are running our own tests to see if this expose any other issue or if the proposed numbers does not work. Initial results looks good.

We already have mtouch arguments specified, recommended to us from back in the MonoTouch days:

-aot "nimt-trampolines=512"

We have never received a notice that this argument is no longer necessary. It sounds like perhaps it hasn't been necessary for some time, and since we are running into this thread issue, that we should adopt the workaround arguments instead.

Is it safe to say our existing arguments do nothing to help us here?

Is it safe to say our existing arguments do nothing to help us here?

I'm fairly sure they were ignored unless nopagetrampoline is used. @vargaz ?

Hello again,

When I try the workaround with my app, I get a cannot AOT compile error when trying to build. Strangely, sometimes it seems to work, and sometimes it doesn't. At first, I thought it might because I was horribly behind in Forms versions as far as NUGET goes, but after updating all of my packages across all of my projects I'm still getting the error.

Unfortunately, the build logs aren't terribly helpful, either:
MTOUCH : error MT3001: Could not AOT the assembly '/Users/runner/work/1/s/App/appname.iOS/obj/iPhone/Release/mtouch-cache/3-Build/appname.iOS.exe' [/Users/runner/work/1/s/App/appname.iOS/appname.iOS.csproj]

I'm producing this build using AppCenter, so I don't think it's related to bin/obj folders or anything like that, because on AppCenter those are generated from scratch every build.

Removing the argument to MTOUCH removes this error as far as I can tell.

@Alex6511 an MT3001 error means the AOT compiler did not output anything (it likely crashed). Can you

  • Add "-v -v -v -v" to the Additional mtouch arguments (along with the --aot ones). This will increase the build logs verbosity
  • Attach the build log to a new issue (so it's not confused with the current discussion)
  • Add a link back to this issue (for extra context)

Thanks!

@Alex6511 an MT3001 error means the AOT compiler did not output anything (it likely crashed). Can you

* Add "-v -v -v -v" to the **Additional mtouch arguments** (along with the `--aot` ones). This will increase the build logs verbosity

* Attach the build log to a **new** issue (so it's not confused with the current discussion)

* Add a link back to this issue (for extra context)

Thanks!

So adding -v -v -v -v fixed it. Guess that works.

@spouliot We are beginning to apply and test the suggested workaround in our app.

Our app is very data intensive and makes heavy use of interfaces, generics and dynamic Linq objects. We are concerned if the static profiling will be able to give us a reliable count for trampolines used by the app, and setting a static trampoline limit seems too risky (and trial and error).

I have following additional questions:

  • Is it possible to profile the count of trampolines used by an app at runtime? (maybe log it on the device or somehow make a low level system call)
  • Since this issue is specific to apps running on arm64e devices, is there a way to conditionally apply this workaround only for arm64e target architecture? We would rather avoid impacting our customers not using MDM or arm64e devices with this workaround, if possible.

@spouliot is the value 40960 in your example a typo? Should this be 4096 as per some of the other values or were these just arbitrary numbers you had tried. I'm looking for a reasonable starting point and 40960 seemed high.

--aot=nopagetrampolines,ntrampolines=**40960**,nrgctx-trampolines=**40960**,nrgctx-fetch-trampolines=256,ngsharedvt-trampolines=4096,nimt-trampolines=4096

I am getting the following error after adding the arguements :

--aot=nopagetrampolines,ntrampolines=40960,nrgctx-trampolines=40960,nrgctx-fetch-trampolines=256,ngsharedvt-trampolines=4096,nimt-trampolines=4096,gsharedvt=true,-v -v -v -v

Could not AOT the assembly '/Users/aboonstra/Library/Caches/Xamarin/mtbs/builds/XUnexusClient.iOS/8f92a0059b1c0104f5b3bbfec58678a7cf40be45250d8efa96f2af61d8adaee7/obj/iPhone/AppStore/mtouch-cache/64/3-Build/xxx.iOS.exe'

@truecaller12 please see above comment https://github.com/xamarin/xamarin-macios/issues/10086#issuecomment-738968014

@kodejack not a typo. Trampolines for normal method calls are much more common than the one used for shared generic value types.

We have rebuilt, tested and re-released our apps with the workaround and everything is now working.

@spouliot Thanks!

I am getting the following error by adding the arguements

--aot=nopagetrampolines,ntrampolines=40960,nrgctx-trampolines=40960,nrgctx-fetch-trampolines=256,ngsharedvt-trampolines=4096,nimt-trampolines=4096,gsharedvt=true,-v -v -v -v
ErrorLog.txt

are these arguments specific to ARM64 arch via MDM download... Will this impact if we add these arguments for other arch downloading via MDM or not?

@truecaller12 please file a separate issue for compilation errors. This way this (already long) thread can stay focused on a single issue and avoid potential confusion from having several discussions.

are these arguments specific to ARM64 arch via MDM download...

No, the build options, including the AOT options, are for the application being built.

There is no way at build time to know (and adapt) for apps coming from the AppStore or an MDM. You submit once to Apple and the apps are modified based depending on conditions that are out of our control.

We have been implementing these changes and generally things have gone well.

We have found that after 10+ minutes of exhaustive app usage (at the setting suggested above), we do get crashes due to trampoline exhaustion. If we double every value, this does not occur. So far, so good.

However, in an attempt to make a more refined change than "double everything", we are having trouble getting any output of the form Ran out of trampolines of type X.

Instead we get the following stack trace (this is being obtained via Appcenter but matches crash report extracted via XCode too):

libsystem_kernel.dylib
__pthread_kill
libsystem_c.dylib
abort
XXX.iOS log_callback(char const*, char const*, char const*, int, void*) runtime.m:1193
XXX.iOS monoeg_g_logv_nofree goutput.c:151
XXX.iOS monoeg_g_log goutput.c:173
XXX.iOS get_numerous_trampoline aot-runtime.c:5796
XXX.iOS mono_aot_get_imt_trampoline aot-runtime.c:6133
XXX.iOS mono_vtable_build_imt_slot object.c:1509
XXX.iOS mini_resolve_imt_method mini-trampolines.c:220
XXX.iOS common_call_trampoline mini-trampolines.c:474
XXX.iOS mono_vcall_trampoline mini-trampolines.c:856
XXX.iOS generic_trampoline_vcall
XXX.iOS XXXX.cs:95

Looking at the source code for get_numerous_trampoline (in https://github.com/mono/mono/blob/master/mono/mini/aot-runtime.c#L5916), it is clear this is where Ran out of trampolines of type.. is meant to be logged, but for whatever reason it steps into monoeg_g_logv_nofree instead.

In our case, we are going to use the fact that mono_aot_get_imt_trampoline is the calling method to deduce it must be type MONO_AOT_TRAMP_IMT which corresponds to nimt-trampolines above. So it is this one we will double and test.

But we thought this information might be useful to others too, especially if they are getting similar crash logs or unknown crashes running the default values. Note we are using Xamarin Forms, which _might_ need higher nimt-trampolines in general.

@truecaller12 please file a separate issue for compilation errors. This way this (already long) thread can stay focused on a single issue and avoid potential confusion from having several discussions.

are these arguments specific to ARM64 arch via MDM download...

No, the build options, including the AOT options, are for the application being built.

There is no way at build time to know (and adapt) for apps coming from the AppStore or an MDM. You submit once to Apple and the apps are modified based depending on conditions that are out of our control.

Thank you... i placed the arguments without space... it builds fine...

We have been implementing these changes and generally things have gone well.

We have found that after 10+ minutes of exhaustive app usage (at the setting suggested above), we do get crashes due to trampoline exhaustion. If we double every value, this does not occur. So far, so good.

However, in an attempt to make a more refined change than "double everything", we are having trouble getting any output of the form Ran out of trampolines of type X.

Instead we get the following stack trace (this is being obtained via Appcenter but matches crash report extracted via XCode too):

We will investigate this to make sure the message is correctly logged.

@vargaz / @spouliot : Would it be possible to post a progress update on the "final" fix at all? We are trying to plan our app releases and would like to know if a "final" fix is likely at all, and if so when it might be available (days, weeks, months, never etc)? If it's looking like days/weeks then we might hold off implementing the workaround. If it's looking like months/never then we'll have to plan to roll out the workaround with associated testing etc.

Thanks

@vargaz, @spouliot I would like to know as well what the timeline for this looks like potentially.

@spouliot
I am using xamarin.forms. I have used workaround as you suggested.

--aot=nopagetrampolines,ntrampolines=40960,nrgctx-trampolines=40960,nrgctx-fetch-trampolines=256,ngsharedvt-trampolines=4096,nimt-trampolines=4096

My app opened with out any problem but after few minutes my app crashed. I got the below exception.

System.Exception: CurrentDomainOnUnhandledException ---> Foundation.MonoTouchException: Objective-C exception thrown. Name: NSInvalidArgumentException Reason: -[_NSInlineData isFileURL]: unrecognized selector sent to instance 0x282279cc0
Native stack trace:
0 CoreFoundation 0x00000001ad76088c AF3F8E01-C130-3464-AD40-C5532D273483 + 1202316
1 libobjc.A.dylib 0x00000001c1cb6c50 objc_exception_throw + 60
2 CoreFoundation 0x00000001ad66795c AF3F8E01-C130-3464-AD40-C5532D273483 + 182620
3 CoreFoundation 0x00000001ad763444 AF3F8E01-C130-3464-AD40-C5532D273483 + 1213508
4 CoreFoundation 0x00000001ad765740 _CF_forwarding_prep_0 + 96
5 MyAppOS 0x000000010085e248 MyAppiOS + 614984
6 Foundation 0x00000001aead13c8 5C24EE4A-3447-36BD-9910-6F4D9616D692 + 1409992
7 libdispatch.dylib 0x00000001ad35324c 3277BF1E-B994-3609-9B30-E0186BBF3C25 + 8780
8 libdispatch.dylib 0x00000001ad354db0 3277BF1E-B994-3609-9B30-E0186BBF3C25 + 15792
9 libdispatch.dylib 0x00000001ad35c10c 3277BF1E-B994-3609-9B30-E0186BBF3C25 + 45324
10 libdispatch.dylib 0x00000001ad35cc5c 3277BF1E-B994-3609-9B30-E0186BBF3C25 + 48220
11 libdispatch.dylib 0x00000001ad366d78 3277BF1E-B994-3609-9B30-E0186BBF3C25 + 89464
12 libsystem_pthread.dylib 0x00000001f6b78804 _pthread_wqthread + 276
13 libsystem_pthread.dylib 0x00000001f6b7f75c start_wqthread + 8

--- End of inner exception stack trace ---

I didnt even get the device log as

Ran out of trampolines

even i tried double the values of mtouch arguments, but get the same exception. Please help me to found where wrong

@Aruna-CEGB that's not a problem that can be solved by increasing any number of trampolines, something else is going on. Check if you can reproduce the crash locally without adding the --aot arguments. If you can't, please create a test project we can use to reproduce the crash, and file a new issue attaching the test project, so that we can have a look at it (and please file a _new_ issue so that we don't end up with a lot of things going on here at the same time, because that ends up being confusing for everybody).

Hi again! Like @davidhedley is writing above, it would be nice with information about how you think and plan regarding a "formal fix" since it seems like there might be scenarios with challenges with the workaround as well. Several of our customers postponed the upgrade of the users iOS with 90 days from the date this was reported, according to our advice how to avoid the problem. In 90 days means in the middle of february. They are not willing to postpone it even more because och security patches from Apple in iOS that are missed out. We need to make a decision next week which way to choose to be able to release in time. Thanks in advance!

We are in the same situation as the colleagues above; we have a huge deployment planned for the beginning of the year with one of our new clients. Not being able to deploy is going to be a huge problem for us too.

We have also tried implementing the suggested workaround. We have found that we are seeing app crashes due to trampoline exhaustion with the recommended values. We have only been able to resolve this issue by drastically increasing the number of trampolines available, by a factor of 8. For example, we have "ntrampolines=327680" rather than "ntrampolines=40960". The only change to this build is the mtouch arguments. Otherwise the build has been fully tested.

Using values so much larger than the suggested numbers has us a little uncomfortable. Is there an upper limit to these values? What is a maximum reasonable number of trampolines to use? Can we expect any negative consequences?

Just want to clarify... without switching to fixed number of trampolines, is the startup crash present only when installing via MDM or does it also happen for AppStore installs?
Also is the issue present on both iPhones and iPads?

I don't think anyone has seen this issue on AppStore installs.

@rsmith-cbt

Is there an upper limit to these values?

Not really. The number of required trampolines at runtime does not change by using the options. The exact number is related to the code you execute.

What is a maximum reasonable number of trampolines to use?

There's no maximum. Larger apps will need larger amounts of trampolines.

Can we expect any negative consequences?

Trampolines will be pre-allocated at build time (instead of copied in memory). This will have some impact on the (disk/download) size of your application. This is why you do not want to use insanely huge numbers.

@gabors

is the startup crash present only when installing via MDM or does it also happen for AppStore installs?

Apple's process for the AppStore is different. This only affects app deployed with MDM.

Also is the issue present on both iPhones and iPads?

It's only on newer devices (both iPhones and iPads) that use an arm64e CPU. Older devices with an arm64 CPU do not have the issue.

Apple has told us "a fix" will be coming in a TBD release. We do not know when and we do not know its exact scope. When released two scenarios could happen:

Scenario 1: Apple update fixes the API we need and automatic trampoline allocations works again.

This would be the best case scenario: _Status quo ante bellum_

Scenario 2: Apple update does NOT fix the API

This is the current (or a similar) situation. It means automatic trampoline allocations does not work and must be done manually, pre-allocated with the arguments.

There _might_ be future updates, from Microsoft, to ease this situation but finding an alternative solution will take time. We share the same problem that we cannot reproduce this crash without submitting an app to the App Store. Also we cannot debug the Apple-processed app, part of the hardening process removes the ability to debug applications. This makes each iteration a very long, multi-day, process. Finding alternative solutions will take time.

Considering the unknowns you should plan (and test) to use the manual arguments if you want to support MDM scenarios in the next several months. We’ll post more details when we have them.

@spouliot - Thank you very much for the information, that is very helpful.

We will plan to use the workaround in the short term and hope that either Microsoft or Apple can produce a fix in the medium-long term.

Thanks for the details @spouliot

What makes the startup process different with regard to trampolines if the app comes from AppStore vs MDM?

Its not related.

This issue has been open since Nov 11, anyway this can be pushed to a higher priority. A lot of companies use MDMs and they cannot use any xamarin based apps.

This issue has been open since Nov 11, anyway this can be pushed to a higher priority. A lot of companies use MDMs and they cannot use any xamarin based apps.

The work around works - we are in production with it now. Not sure what you are expecting, given Microsoft is now waiting on an Apple fix

I was hoping that we could fix it without having to wait on apple

I was hoping that we could fix it without having to wait on apple

You can, if you apply to above recommended work around

I'd like to add that we tried the work around and it appears to be successful, no crashes due to trampoline exhaustion yet.

Just received confirmation from one of our customers that the workaround does indeed fix the problem. No reports of crashes as of yet.

Workaround was tried by our customers and ourselves and works. Thanks alot!

All,
How did you all try the workaround before releasing the app to the field again?
What staging setup was used to confirm that , app crashes without workaround and app does not crash with workaround?
Was the workaround directly released to the field without a staging test?

Also what ( if any) are known side effects of this workaround other than increasing the size of the ipa ?

Do we need to perform any additional regression test as a result of applying this workaround?

Thanks

On Dec 15, 2020, at 6:06 AM, Pontus Svedman notifications@github.com wrote:


Workaround was tried by our customers and ourselves and works. Thanks alot!


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

Submitting as B2B app to customers who have Apple Business Manager and MDM is one option.

14.3 has been released, has anyone tried updating to see if this issue has been fixed by apple?

@sankar12345 we did a full coverage pass of our application after applying the work around, if you have an application crash then you have to increase one of the trampoline settings as stated above and do a full coverage pass again. Then we pushed to the store and had our customer test it. But it would appear the B2B option would work from @jpsweet.

Thank you Paul and @jpsweet for providing details.

Thanks

On Dec 15, 2020, at 8:13 AM, paul-kiar notifications@github.com wrote:


@sankar12345 we did a full coverage pass of our application after applying the work around, if you have an application crash then you have to increase one of the trampoline settings as stated above and do a full coverage pass again. Then we pushed to the store and had our customer test it. But it would appear the B2B option would work from @jpsweet.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

@jpsweet I can confirm that even custom B2B apps also experience the crash when deployed via MDM without the trampolines workaround. The only exception I have found that does not experience the crash is signing the ipa with an Enterprise certificate and deploying the .ipa via MDM and not from the app store (either public app store or private Custom B2B app store).

The workaround is working for us so far. The app is privately deployed automatically via Apple Business Manager to Mobileiron MDM. I would very much doubt if iOS 14.3 has a fix for this, it was already in beta when this happened.

Has anyone received a response from Apple about when they will fix the issue?

I can confirm that after applying the workaround detailed on this thread, packaging our app and releasing it via the Apple App Stores, this has resolved the issue for our app.

Our app is now successfully deployed via MDM on devices in the field running both iOS 14.2 and 14.3, and no longer crashes on startup.

Good job, and a HUGE THANK YOU to all the engineers that have been looking into this issue.

To app developers that are currently facing this issue, please note that Apple has a shutdown period where app submissions will not be processed, beginning December 23rd - something to be mindful of if you are experiencing this problem and wish to have it resolved before the end of the year.

We have the same problem with MobileIron and iOS >=14.2. When our app is Launching MDM via AppConnect, it fails and black screen is the result. After around 20 seconds, our app is crashing

Anybody have any idea about the underlying issue behind all this? I have a Nativescript app that has nothing to do with Xamarin but has the same problem when installed via MDM (Intune). I build the app with XCode so the above workaround doesn't help me. Any help would be much appreciated.

@OvidiuGuta Did you check this post? https://github.com/xamarin/xamarin-macios/issues/10086#issuecomment-728163814

@OvidiuGuta Did you check this post? #10086 (comment)

Yes. But the thing is our app works just fine when downloaded from AppStore. It's just when installed through an MDM that it crashes on startup. My problem is that it's a customer's MDM setup so I can't even debug on that. I was hoping for a generic fix/workaround that would magically solve my issue.

We implemented the suggested workaround and at least one of our major US hospitals is reporting that the app is still crashing on startup.
They attempted to delete the app and install fresh via AppStore that works.
Then deleted and installed via MDM and it crashes.

@gabors so far all other reports have been positive.

Please double check that the build configuration you archived and submitted (to Apple) was built with the extra arguments we supplied. Without the arguments the app will work in all, but this MDM, scenario.

@OvidiuGuta I do not know the internals of NativeScript. However the workaround mentioned in this issue is very specific to Xamarin and won't be of any help to you.

Your best bet is to file an feedback and DTS issue with Apple and ask the NativeScript developers to do the same. Cross-linking them (and also the one mentioned in this issue) should also help.

@gabors so far all other reports have been positive.

Please double check that the build configuration you archived and submitted (to Apple) was built with the extra arguments we supplied. Without the arguments the app will work in all, but this MDM, scenario.

@spouliot yes I was surprised too that they are reporting the exact same crash.
I double checked that I archived with the proper args, here they are:
--nosymbolstrip=ZBarReaderControllerResults,--aot=nopagetrampolines,ntrampolines=81920,nrgctx-trampolines=81920,nrgctx-fetch-trampolines=512,ngsharedvt-trampolines=8192,nimt-trampolines=8192

That initial bit was there before. Maybe the comma is the problem and I need to use a different separator?

Maybe the comma is the problem and I need to use a different separator?

Likely, mtouch arguments are space separated.
The --aot= arguments, since there can be multiple, are comma-separated
Having a comma there means the aot arguments are given has instructions not to strip some binaries.

If you want to be sure the settings are applied you can try very small values for the trampolines, e.g. ntrampolines=1024m, and the app should crash (could be at startup) on your development phones. The console logs will mention the trampolines.

Thanks @spouliot !

Can I test these arguments on a debug build? Simulator? or has to be device?

@gabors the simulator uses the JIT, not the AOT, compiler so this won't help. But you can use the same aot arguments in your device debug builds.

Merci beaucoup @spouliot just trying this on a device debug build.

@spouliot yup mthouch needs spaces as argument separator.
So for debug device build

this would run
--nosymbolstrip=ZBarReaderControllerResults --aot=nopagetrampolines,ntrampolines=81920,nrgctx-trampolines=81920,nrgctx-fetch-trampolines=512,ngsharedvt-trampolines=8192,nimt-trampolines=8192

and this would crash on startup
--nosymbolstrip=ZBarReaderControllerResults --aot=nopagetrampolines,ntrampolines=100,nrgctx-trampolines=81920,nrgctx-fetch-trampolines=512,ngsharedvt-trampolines=8192,nimt-trampolines=8192

14.3 has been released, has anyone tried updating to see if this issue has been fixed by apple?

I tried 14.3 yesterday and no dice for us... still crashes.

@spouliot yup mthouch needs spaces as argument separator.
So for debug device build

this would run
--nosymbolstrip=ZBarReaderControllerResults --aot=nopagetrampolines,ntrampolines=81920,nrgctx-trampolines=81920,nrgctx-fetch-trampolines=512,ngsharedvt-trampolines=8192,nimt-trampolines=8192

and this would crash on startup
--nosymbolstrip=ZBarReaderControllerResults --aot=nopagetrampolines,ntrampolines=100,nrgctx-trampolines=81920,nrgctx-fetch-trampolines=512,ngsharedvt-trampolines=8192,nimt-trampolines=8192

@gabors Was the second one (the one that crashes as startup) supposed to have a comma between ZBarReaderControllerResults and --aot? Maybe my eyes are deceiving me, but those look identical.

We are now fairly sure the root issue is identified (testing is ongoing). IOW the information that Apple shared with us does match what people describe in this thread.

Context

Xamarin.iOS depends on small pieces of machine code called trampolines for a variety of functions. The runtime uses some low-level code to support an _infinite_ (dynamic) number of trampolines. This is the piece that stopped working.

In older versions of Xamarin.iOS (think MonoTouch) the AOT compiler used a fixed number for each type of trampolines. Going back to the old behaviour solve the issue. This can be done by using the --aot=nopagetrampolines option (but continue reading).

The main problem is that apps can run out of trampolines and crash/abort with a message like:

Ran out of trampolines of type %d in '%s' (limit %d)

The AOT compiler cannot know how many, of each type, of trampoline will be needed (it's known at runtime) and generating trampolines increases the executable size, so using extremely large numbers of them is not a good solution.

Suggested Workaround

Add the following options to the Additional mtouch arguments inside your application options.

--aot=nopagetrampolines,ntrampolines=40960,nrgctx-trampolines=40960,nrgctx-fetch-trampolines=256,ngsharedvt-trampolines=4096,nimt-trampolines=4096

UPDATE You might already have some additional arguments. Make sure you're appending the ones above and that you have a space between any existing and new ones. IOW the --aot= options are comma separated but mtouch options are space separated.

Screen Shot 2020-12-03 at 10 15 56 AM

Those options should be added to all (Debug/Release/...) project configuration for device builds, which is where the AOT compiler is being used. IOW it's not needed for simulator builds.

Testing

Once you produce a build you must re-test your application. Running out of trampolines happens at runtime and will crash (abort) the application. The console (Console.app) logs will show something like:

Ran out of trampolines of type X

If this happens you need to increase the amount for the mentioned type (X) of trampoline. You can try to double the existing amount (suggested above).

Trampoline types vs option names

  • normal trampolines (type 0) -> ntrampolines=X
  • rgctx trampolines (type 1) -> nrgctx-trampolines=X
  • imt trampolines (type 2) -> nimt-trampolines=X
  • gsharedvt arg trampolines (type 3): ngsharedvt-trampolines=X
  • unbox arbitrary trampolines (type 5): nunbox-arbitrary-trampolines=X
  • rgctx fetch trampolines -> nrgctx-fetch-trampolines=X

Example

Ran out of trampolines of type 2 (limit 4096)

  • Trampoline 2imtnimt-trampolines
  • Change the option from nimt-trampolines=4096 to nimt-trampolines=8192
  • Rebuild and re-test the application

We're aware this information is a bit raw and not very easy to consume. The goal was to get the information, including a workaround, out fast. Expect this post to be edited/refined until more appropriate documentation becomes available.

Big thanks to @vargaz who wrote most of this post. All mistakes are mine :-)
Also a huge thanks to everyone, here in this post, at Apple and Microsoft, who help to diagnose, debug and find a solution.

So, based on the suggested workaround what error would be thrown if app runs out of nrgctx-fetch-trampolines? (it does not have a type associated with it)

It wouldn't run out of those, just would use a slower code path, but with the suggested value of 512, thats very unlikely.

Does anyone experience this issue on iOS 14.2 devices in case device is managed by MDM and app downloaded directly from AppStore?

@Yfedo Yes, we have an app that was released to the public App Store, and also used against an MDM. We had to use the same work around to get the MDM services working again.

Have any of you ran into a situation where you needed to increase the trampoline count to more than what is specified here ?
Below is from a previous post .
So wondering if anybody ran into a situation where this count was not enough and had to configure a higher number.

aot=nopagetrampolines,ntrampolines=40960,nrgctx-trampolines=40960,nrgctx-fetch-trampolines=256,ngsharedvt-trampolines=4096,nimt-trampolines=4096

Thanks

On Dec 17, 2020, at 5:53 PM, bhoppeman notifications@github.com wrote:


@yfedo Yes, we have an app that was released to the public App Store, and also used against an MDM. We had to use the same work around to get the MDM services working again.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

We had to increase them by quite a lot. I think two of the trampoline
types ended up around 400,000 and another ended up close to 100,000 for
us. Our app is fairly large though and has quite a bit of code. It
probably took us several hours of development trial and error to come up
with those numbers and then a testing session of several hours to confirm
them.

If you are going to release an app version with this workaround then you
really need to do what was suggested and thoroughly test your app with your
trampoline numbers in a single testing session to make sure that they are
sufficient.

On Fri, Dec 18, 2020, 4:49 PM sankar12345 notifications@github.com wrote:

Have any of you ran into a situation where you needed to increase the
trampoline count to more than what is specified here ?
Below is from a previous post .
So wondering if anybody ran into a situation where this count was not
enough and had to configure a higher number.

aot=nopagetrampolines,ntrampolines=40960,nrgctx-trampolines=40960,nrgctx-fetch-trampolines=256,ngsharedvt-trampolines=4096,nimt-trampolines=4096

Thanks

On Dec 17, 2020, at 5:53 PM, bhoppeman notifications@github.com wrote:


@yfedo Yes, we have an app that was released to the public App Store,
and also used against an MDM. We had to use the same work around to get the
MDM services working again.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/xamarin/xamarin-macios/issues/10086#issuecomment-748356538,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AALXVANPVD4HYLZS45HNQILSVPMBJANCNFSM4TSLR3KA
.

Thanks jpeters5392 for that feedback and sharing your experience.

When you say “ test your app thoroughly in a single session “, you mean test the app for various functionalities in a single instance of the app without swipe killing it, so summation of all those tests will reveal if trampolines are near to getting exhausted or not?

Has anyone had a chance to test app running for multiple days and impact of trampoline availability when app was used for multiple days?

Thanks

On Dec 18, 2020, at 4:56 PM, jpeters5392 notifications@github.com wrote:


We had to increase them by quite a lot. I think two of the trampoline
types ended up around 400,000 and another ended up close to 100,000 for
us. Our app is fairly large though and has quite a bit of code. It
probably took us several hours of development trial and error to come up
with those numbers and then a testing session of several hours to confirm
them.

If you are going to release an app version with this workaround then you
really need to do what was suggested and thoroughly test your app with your
trampoline numbers in a single testing session to make sure that they are
sufficient.

On Fri, Dec 18, 2020, 4:49 PM sankar12345 notifications@github.com wrote:

Have any of you ran into a situation where you needed to increase the
trampoline count to more than what is specified here ?
Below is from a previous post .
So wondering if anybody ran into a situation where this count was not
enough and had to configure a higher number.

aot=nopagetrampolines,ntrampolines=40960,nrgctx-trampolines=40960,nrgctx-fetch-trampolines=256,ngsharedvt-trampolines=4096,nimt-trampolines=4096

Thanks

On Dec 17, 2020, at 5:53 PM, bhoppeman notifications@github.com wrote:


@yfedo Yes, we have an app that was released to the public App Store,
and also used against an MDM. We had to use the same work around to get the
MDM services working again.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/xamarin/xamarin-macios/issues/10086#issuecomment-748356538,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AALXVANPVD4HYLZS45HNQILSVPMBJANCNFSM4TSLR3KA
.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

Correct, try to execute as close to 100% of your code as you can without
swiping your app closed. Our QA did leave our app running overnight after
finishing the tests to make sure, but from the descriptions in some of the
posts the number of times methods are called doesn't matter as much as
whether they are ever called.

On Fri, Dec 18, 2020, 5:04 PM sankar12345 notifications@github.com wrote:

Thanks jpeters5392 for that feedback and sharing your experience.

When you say “ test your app thoroughly in a single session “, you mean
test the app for various functionalities in a single instance of the app
without swipe killing it, so summation of all those tests will reveal if
trampolines are near to getting exhausted or not?

Has anyone had a chance to test app running for multiple days and impact
of trampoline availability when app was used for multiple days?

Thanks

On Dec 18, 2020, at 4:56 PM, jpeters5392 notifications@github.com
wrote:


We had to increase them by quite a lot. I think two of the trampoline
types ended up around 400,000 and another ended up close to 100,000 for
us. Our app is fairly large though and has quite a bit of code. It
probably took us several hours of development trial and error to come up
with those numbers and then a testing session of several hours to confirm
them.

If you are going to release an app version with this workaround then you
really need to do what was suggested and thoroughly test your app with
your
trampoline numbers in a single testing session to make sure that they are
sufficient.

On Fri, Dec 18, 2020, 4:49 PM sankar12345 notifications@github.com
wrote:

Have any of you ran into a situation where you needed to increase the
trampoline count to more than what is specified here ?
Below is from a previous post .
So wondering if anybody ran into a situation where this count was not
enough and had to configure a higher number.

aot=nopagetrampolines,ntrampolines=40960,nrgctx-trampolines=40960,nrgctx-fetch-trampolines=256,ngsharedvt-trampolines=4096,nimt-trampolines=4096

Thanks

On Dec 17, 2020, at 5:53 PM, bhoppeman notifications@github.com
wrote:


@yfedo Yes, we have an app that was released to the public App Store,
and also used against an MDM. We had to use the same work around to
get the
MDM services working again.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<
https://github.com/xamarin/xamarin-macios/issues/10086#issuecomment-748356538
,
or unsubscribe
<
https://github.com/notifications/unsubscribe-auth/AALXVANPVD4HYLZS45HNQILSVPMBJANCNFSM4TSLR3KA

.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/xamarin/xamarin-macios/issues/10086#issuecomment-748361769,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AALXVALVH73QEEQHUECLMHLSVPNWHANCNFSM4TSLR3KA
.

Hello all, can someone shed some light on these

  1. Does the workaround have any impact on the final IPA size for example?
  2. How about loading/startup time?

@spouliot

  1. Any way to perform this condtionally for example to perform this per architecture to target only affected devices rather than implement this for all ?

@all

  1. Any info on adding extra optimizations that are not part of the default optimizations that Mono applies while JITing to the -aot flag ?

Hi everyone! Does anyone have thoughts about why this seems to happen more when the application is distributed through MDM?

Hi @spouliot - based on your communication with Apple, will the actual fix for this issue be included in a future iOS release (e.g. 14.4) or in a future Xamarin.iOS release?

@spouliot without actually getting the app into the app store to be launched by the MDM, how are you testing this? Testflight won't work as testflight is what is installed by the MDM, not my app.

We found no way of testing this fix without releasing a new version of our app through the Apple App Store. Fortunately, the fix described was able to address the issues our clients who use MDMs were reporting without any adverse effects to the rest of the userbase. Incorporating the increased trampolines added about 1MB to our overall app size.

Any way to perform this condtionally for example to perform this per architecture to target only affected devices rather than implement this for all ?

@alvynfash no, it's not _really_ architecture related - at least not at build time, since the issue happens after hardening (so after you submitted the app).

You could create a different application for your MDM users but that comes with it's own set of problems... and won't reduce the amount of testing required.

will the actual fix for this issue be included in a future iOS release (e.g. 14.4) or in a future Xamarin.iOS release?

@cosminstirbu the exact nature of the fix is not known to us. It might be unrelated to an iOS release, e.g. if the fix is done on the hardening process after App Store submission.

without actually getting the app into the app store to be launched by the MDM, how are you testing this?

@jmarshallzoll sadly we can't. The app needs to be submitted to Apple's App Store. It will be modified there, by Apple, before you install it thru your MDM software.

@spouliot Aside from increasing app size, are there any other implications or potential issues with increasing trampoline counts that we should test for?

Was this page helpful?
0 / 5 - 0 ratings

Related issues

rolfbjarne picture rolfbjarne  ·  4Comments

sharmashiv picture sharmashiv  ·  4Comments

jzeferino picture jzeferino  ·  3Comments

ormaa picture ormaa  ·  3Comments

juepiezhongren picture juepiezhongren  ·  3Comments