iOS 17.2 sync is broken

Ran into this issue again today (iPhone 15 on 17.2.1, 14" MBP on 14.2.1). Did not find the MDCrashReportTool process or anything similar running. Restarting Finder did not help. However, logging out and back in again allowed the sync to go through. So my hunt for the process causing this baloney continues…

1 Like

mdcrashreporttool is started by step 3 of 5 (regardless if you skip backups). that’s where sync always hangs for me. it appears to reliably (apologise for the curious use of the word “reliably”) be the cause of the problem.

other sites, including the normally worthless apple support forums appear to agree that it’s the cause of this sync failure. apparently afflicting windows systems as well as apple.

2 Likes

Confirming that finding and force-quitting an active MDCrashReportTool process will allow sync’ing (Step 3 of 5) to continue.

FYI, it can be awkward to actually find that process. Start Activity Monitor and click on the CPU tab, then search for MDCrash. When you see a line showing the process, double-click on it to get a popup with some options, including Quit and Force Quit. Click on Force Quit.

I’m now wondering if it’s on the Mac (in Sonoma 14.2.1 and possibly earier versions?) rather than iOS 17.2 where there’s a bug causing MDCrashReportTool (and thus the sync process) to hang.

2 Likes

there are lots of complaints on various forums that you have to kill mdcrashreporttool.exe to sync your phone to windows machines. apparently some lousy coder in cupertino busted the process for both windows and osx.

question is: will they fix it before the heat death of the universe? my cynical vote (based on past form) is no they won’t cuz it doesn’t affect their services revenue.

2 Likes

Hey, thanks all! Can confirm that killing MDCrashReportTool works. Now to hack up a launchd job to automate doing this regularly, so my syncs just happen and I don’t walk out the door to find my latest audiobooks haven’t synced again …

Turning on iCloud backups makes the passcode prompt go away, yes, because local backup only triggers when iCloud Backup is off and the passcode prompt appears before every single backup. And in a sane world this would count as a bug and not a feature. To be clear, encrypted backups are streamed directly from the phone; an attacker can’t decrypt an intercepted phone backup when encrypted backups are already turned on, unless the password is weak. Apple could solve the problem of a weak password easily by requiring the user to confirm the password on both sides when they are set up, and by requiring passwords to have a guaranteed minimum entropy. But they don’t, because iCloud. Sigh. I can only speculate, but I think it’s pretty clear the shareholders have something to do with this, and that Apple are much more afraid of them than their own users. There might be scope for arguing that users can be coerced into setting up backup (think abusive partner), and these things are not to be dismissed, but it’s still a grubby move, for all that, and like I said, there’s no reason Apple can’t fix that with changes to iOS.

1 Like

I’ve also experienced this problem for maybe 5+ years now (on Macs), and IIRC, killing MDCrashReportTool has been the “fix” since the beginning…sigh…

1 Like

So I just had USB sync refuse to run again. “iPhone 15 cannot be found, error 50” or similar.

And just as I reported last time, this time again there was no MDCrashReporterTool listed as a process to force quit. There’s just nothing like that around on this Sonoma M1 MBP.

Relaunching Finder didn’t fix it either. In order to get syncing to start working again, I ended up having to log out and back in again. I sure wish I knew what process I could nuke to just get USB syncing to work again.

2 Likes

being deathly ill with the dread lurgi, i was asleep at the switch the last two times i sync’d my phone. both times, sync completed without needing to sandbag MDCrashReportTool. i’d even started activity monitor to administer the chop.

phone is updated to 17.3. perhaps something was fixed in that update?

are others successfully syncing these days or am i again an outlier?

cheers!

Just gets uglier every time I try…

This happened to me last week on MacStudioUltra.
Switched to different USB cable and didn’t make a difference.
Switched to different USB-C port and it worked.
Don’t have any idea why.

Hmm…just been meaning to try that. I’ve got a Studio Ultra too. I’ve been using USB-A ports, all of which worked in Monterey (even the Echo 15 dock and my DAS keyboard), because it was the cable that came w/ my iPhone 12 mini. Coincidentally found a USB-C-to-Lightning cable in my wife’s desk this weekend…hmm, indeed.

Yeah, I think they’ve fixed this. I was using Wi-Fi sync exclusively, resisted the urge to run my script to kill MDCrashReportTool, and it worked; I watched the entire sync from the moment I hit the Sync button and it was on step 3 of 4 in under five seconds. This was just after triggering a backup (and entering the passcode, sigh) which went absolutely perfectly and very fast. I was strangely impressed. As this was also affecting Windows users, I suspect Apple changed something that broke in their device sync support.

Swapping cables and ports didn’t help here. Still massive corruption when syncing under Sonoma.

Exact same issue today again.

On a whim, I took the exact same USB cable and just plugged it into another port on my 14" MBP. And voila, it synced just like that. Go figure. :laughing:

1 Like

reported a while back that sync was working without intervention. if only. it maybe worked twice. every time since, have to sandbag MDCrashReportTool.

Truthfully not been having issues for a while now, over Wi-Fi at least where I most want it to work. If there are separate issues to the MDCrashReportTool issues, I never ran into those. Bummer for those still affected; I can only really suggest trying Wi-Fi syncing.

Wifi syncing used to be a lot more valuable when you could initiate it from your iPhone. There used to be a toggle for that under Settings > General. But then Apple removed it (around iOS 13?) and now you actually need to walk up to your Mac to initiate a sync because you can only control sync from the Mac end. :frowning:

1 Like

unfortunately, wifi is a whole other world of pain in my setup.

i’ll be moving to a new house that’ll be thoroughly wired with cat6. may end some of my pain and suffering although i’m sure the -er- boffins at apple will manage to break something else that i depend on for happy computing.

@Sebby, you said you had a script for nuking MDCrashReportTool? if so, could you share it?

Nice. If it’s not already in-place when you move in, my recommendation for such a house is:

  • Install a Gigabit or better Ethernet switch in or near your wiring closet where all the jacks come together. Make sure it’s big enough for all the rooms. I suspect a 16-port switch will be big enough. Hopefully not too expensive for your budget.

    Since this will be what ties all the rooms together, this should be the fastest switch in the house. If you plan on using something faster than gigabit and can’t afford switches at that speed everywhere, you should put the fastest switch here.

  • Install smaller switches in any room where you will have more than one wired device. A 4- or 8-port switch will probably be good enough for most rooms.

  • If you want to set up a Wi-Fi mesh system, connect the nodes to this Ethernet backbone (using an Ethernet switch if you will be putting other wired devices in the same location). So they won’t be forced to use your wireless bandwidth to pass data to each other.

2 Likes

@Simon Yes, tragic loss. Nowadays Wi-Fi sync is just a convenience, at best it saves you from having to connect actual cables, and it might save you from forgetting because a sync should trigger when you put down your device to charge. And ultimately that’s good enough to make sure that my latest tunes/audiobook has synced over to my phone by the time I actually leave the flat with it.

@henry.crun I don’t have it anymore, but it was literally a tight loop in a shell script, something like this …

#!/bin/sh
while true; do
killall -9 MDCrashReportTool >/dev/null 2>&1
sleep 5
done

I was going to run this from launchd, but I never got around to making the plist, so I just left the script in my home folder and launched it whenever syncing stalled for any reason. You could presumably do something even simpler with KeyboardMaestro, or FastScripts, or even embed the script into an Automator workflow; I have shortcuts in VoiceOver to launch arbitrary apps/scripts with a key so that’s what I used. I hope it helps.