How to fix Device Disconnected error during iOS 10.3.3 backups

Since iOS 10.3.3 was released, we've been seeing more and more reports of users unable to back up their devices because of a recurring disconnection error. Further investigations revealed that the error happens both with iMazing and iTunes, and is the consequence of a subtle bug in iOS 10.3.3's handling of specific non english characters in file names.

We'll first cover how to diagnose and fix the issue, and will then go into a bit more detail into the underlying reasons behind this APFS related bug.

Are you affected?

You are affected if all the following statements are true:

• Your device is running iOS 10.3.3.
• Your cable is not faulty - backing up with another cable results in the same error.
• The disconnection error is systematic and happens at the same point in the backup process.
• You use a language which contains accents or other special characters, or an app which may contain file names with accents or special characters.

What to do if you are affected?

Erasing the device completely and restoring from an iCloud backup may take care of the problem, but it is a time consuming procedure which isn't always applicable.

The other solution is to identify the file or files which are causing the bug. To do this, you will need to install iMazing and use its device console while backing up your device. You do not need to purchase a license: the free trial will work just fine.

1. Download and install iMazing on your PC or Mac from https://imazing.com/download
2. Launch iMazing and connect your device
3. Select your device in the left sidebar, and click Show Device Console in the actions list: Note: you may have to scroll down in the actions list to find the Show Device Console button.
4. In the Device Console's search field, enter No operation found for path
5. Leave the Device Console window open, and back to the top of the actions list, click Back Up and follow the wizard to launch a backup of your device.
6. When the backup error happens, you should see a message in the Console window that should look like this:

   Aug 7 12:52:05 Greg-iPhone BackupAgent2(CoreFoundation)[328] : *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'No operation found for path: /var/mobile/Containers/Data/Application/9944C65F-F8E5-4CA5-951B-7B6AF0A40D1D/Documents/File-Name-With-Special-Characters'

The path displayed is that of the guilty file. If you can identify in which app it is stored, you can simply rename it in the app in question, directly on your device. Choose a name with english standard characters only to be sure to avoid the bug. At this point, it's also a good idea to rename other potentially problematic files at the same location.

Now, back up again in iMazing, with the Device Console open: if there are any more problematic files, the backup will fail again and you'll need to repeat the procedure.

If you can't identify the app in question

In the example log above, 9944C65F-F8E5-4CA5-951B-7B6AF0A40D1D is the app's GUID. You can use iMazing's capabilities to export advanced info from your phone to a text file, that text file will contain a list of installed apps along with their GUID.

1. Connect your device to iMazing and load Apps (click on the Apps button)
2. Follow this guide to learn how to export advanced info to a .txt file with iMazing. It's very easy!

If you still cannot identify the location of the problematic file on your device, you can contact us and we'll do our best to help! Don't forget to send us the Console log of the error.

Note: the GUID of apps is only exported by iMazing Mac 2.4 upwards, or iMazing Windows 2.3 and upwards. iMazing Windows 2.3 is scheduled for release on the 19th of September, along with iOS 11.

Going further: why is this happening?

The problem has its roots in APFS, Apple's new file system introduced in iOS 10.3.0. To summarize, some special characters have 2 distinct Unicode representations: the Spanish ñ for example has a precomposed variant (Unicode U+241) and a decomposed variant (Unicode U+110:n and U+771:̃).

Before APFS, it was not possible for 2 filenames which look identical but are encoded with different variants to coexist. The file system was normalization insensitive. On the other hand, in iOS 10.3.0, APFS is normalization sensitive, which led to quite a few issues, some of which we covered at the time here: https://imazing.com/blog/ios-10-3-broke-itunes-file-sharing-on-windows

Now, iOS 10.3.3 is supposed to take care of the issue by re-introducing Unicode normalization of file names:

• If upgrading from a previous version, runtime normalization is applied
• If restoring after an erase, native normalization is applied (APFS runs in normalization insensitive mode)

Source: https://developer.apple.com/library/content/documentation/FileManagement/Conceptual/APFS_Guide/FAQ/FAQ.html

The bug we describe here only occurs after an upgrade. We hypothesize that runtime normalization is not consistent enough: probably the Backup Agent on the device uses non-normalizing low level POSIX functions to list files, but higher level APIs handling paths and file system operations do normalize, resulting in the crash we notice in the console.

Computer side, Apple Mobile Backup simply detects a disconnection: indeed, it has been disconnected from the crashed backup process iOS side.