(Partially) Recovering From a Bizarre iTunes Error Turned Catastrophic

In order of priority of intent, this is a post for me to reflect, for this error to show up in Google, and then — somewhere in the distance — for you, dear reader. As selfish as that may be, parts of this may interest you.

Last night as I popped my iPhone into its dock to sync, iTunes returned an “unknown error”, with code 1723. These code-based errors are unhelpful as-is, but the explanation and fix is usually a Google search away. For this one, though, there’s almost nothing documented. According to this list, error 1723 signifies “errAEAccessorNotFound: Accessor proc matching wantClass and containerType or wildcards not found”, whatever that means.

It’s a particularly bad error to be undocumented, too: it results in a fatal error during syncing. While a backup will be created, no further synchronization will occur. And, so, I dedicated some time to fixing this problem — quite a lot of time, as it turns out.

I started with the usual, simple stuff: restarting both OS X and my iPhone, reinstalling iTunes, reinstalling iOS (using the upgrade method, not restore), changing USB cables as this guy suggests, and so forth. All of these methods failed. I checked the standard OS X Console and saw no errors. While Xcode, on the other hand, displayed a far more verbose console, I saw no obvious errors. However, in the interest of this problem being fixed, I captured a few of these logs and submitted them to Apple.1

It was time to pull out the big guns and restore the iPhone. Unfortunately, a restore to a backup restored the mysterious error, so a clean restore was necessary, and that’s when everything went wrong for one simple reason: I encrypt my iPhone backups.

Encrypting your backups is generally considered a smart move. Not only is it more secure than a standard backup, it also includes all of your WiFi passwords. And, in an ideal world, the fact that all of the data is locked down isn’t ever a problem. Except when it is.

The good news is that a clean restore did fix this perplexing error. The bad news is that any document which existed only on the iPhone — that is, any document which didn’t sync to a cloud service — was now locked in an encrypted state. Despite my Google prowess and the legal grey-area predilections of various Cyrillic-filled websites, I couldn’t find a tool which would reliably extract an encrypted iOS backup or, if the tool did exist, it was Windows-only.

But that’s until I stumbled across Andrew Neitsch’s fantastic post on Stack Overflow. It’s a step-by-step guide to using a super easy Python script to extract an encrypted backup. And it worked.

So, keeping in mind that this is more for me and those who will find this via Google, here’s what I learned:

  1. Encryption isn’t a bad thing, but be well aware of what can happen if something does go horribly wrong.
  2. Keep multiple backups of your backups. Before attempting a restore, back up your iOS device, and copy that backup folder (located in ~/Library/Application Support/MobileSync/Backups/long-UDID-string) to a thumb drive or something. Because iTunes uses the UDID for the “name” of the backup, this folder will be overwritten when that device reboots and backs up for the first time, so you may potentially lose a lot of data.
  3. iTunes syncing and iTunes errors are still a real shitter in the Apple user experience landscape.
  4. Even if you can recover your messages, voicemails, call log, and so forth, restoring these files to the iPhone is nearly impossible.
  5. While some people advocate deleting local copies of apps to save space, keeping them around significantly sped up the restore process. I would have spent far more time with this restore had I been required to re-download each app.

One final twist: Vesper and VSCOCam, for example, both keep local non-cloud-synced document databases. After restoring my phone and reinstalling these apps — remember: not from a backup — all of these documents were restored. I’m not sure whether this is something new in iTunes or iOS, but it was a very welcome surprise after an evening of frustration.

  1. Radar number 16106365 if you’re interested, Cupertino-area readers. ↥︎