Yesterday, I was greeted by the Update Notification for for the 7.0.7392 update for my non carrier branded HTC HD7, which of course updated normally. I then for the sake of it, tried the update process on my HTC Mozart 7, which, in what has now become part of the Windows Phone 7 world’s permanent vocabulary, had been “Walshed”. Both my phones are developer unlocked, and the Mozart had had quite a lot of registry editing done to it, as per this post on Walsh’s Blog, trying to get the VPN trick to work, and this thread at XDA Developers. Somewhere in amongst all the fiddling I’ve been doing, and I think it has to do with the registry hack to debrand the phone, I inadvertently stumbled on the right combination of things to allow my carrier branded Mozart to update without error. Considering the carrier branding, and that Telstra is now only scheduling delivery of the march update, I should not have even gotten a notification for the 7392 update. Testimony to Walsh’s debranding registry edit, I would say.
Others though have not faired so well, having the backup not complete with an error, 80180048, Microsoft warned that there may be a problem using the work around method that Walsh developed, but a lot of us went for it any way.
But my strong advice is: wait. If you attempt one of these workarounds, we can’t say for sure what might happen to your phone because we haven’t fully tested these homebrew techniques. You might not be getting the important device-specific software we would typically deliver in the official update. Or your phone might get misconfigured and not receive future updates
Of course, Walsh pulled the tool from his site, in a very short time of posting it on advice from Microsoft. Again today, Microsoft, Namely Brandon Watson, waded in to the fray, with a post on the Windows Phone Developer Blog. Brandon in his post entitled, “All Updated Windows Phones Are Not Alike”, details more of what Microsoft believe Walsh’s workaround changes in the Windows Phone OS, rendering them unable to be updated.
Despite the fact that many people have claimed that an unofficial update mechanism worked fine for them, we cautioned that phones which were updated via this method were not going to be able to update past build 7390. Unfortunately for those customers out there who acted on information from sources outside of Microsoft, the rubber meets the road today
and it seems for many the rubber hit the road and stayed there! We also get some plain English explanation of what exactly happened
With Windows Phone update build 7392 going out to phones via the official update mechanism, those people who have used the unsupported method of forcing 7390 onto their phones will find that their phones will not update to 7392. With the official update process there is a requirement that the package on the phone also be official in order to update itself.
Phones updated via the unsupported method do not contain an official image and cannot be updated further at this time. Due to scheduling of engineering resources, we did not anticipate having to undue the changes made to phones by these unsupported methods. While we are not ruling out having a fix in the future, for now there is no fix.
Brandon goes on to detail some more technical aspects of why the update, related to unofficially updated phones, would fail.
Since this is a developer blog, let’s get a little technical about what is going on. The best way to think about this is that with regard to updating, the phone is a state machine. When the state machine is in proper working order, updates can happen via the official channel no problem. When an unofficial program uses undocumented APIs to force an update, things can go awry. In this case, the unofficial process performed an incomplete update. As such, the state machine was changed – not updated, changed.
So that’s the bad news, out of the way, apparently the Chevron.Updater performed an incomplete update, which explains why many Windows Phone users that applied Walsh’s tool to obtain the update are having problems. The good news, it seems a fix other than flashing your phone back to an original ROM, performing a hard reset in the process, is on the way.
While Microsoft does not fully support the WP7 homebrew community, it seems they are communicating with Chris Walsh and the other ChevronWP7 developers, and that Chris has developed a tool that will reverse the effects of the initial Chevron.Updater for affected users. In what seems like a step forward, Microsoft are open to having the fix submitted, and validated by their developer staff, which makes me think that some of the best developer potential, for WP7 is not actually in Microsoft’s fold. In a way, the end of Brandon;s post where he says they don’t have time to work on a fix for the problem, because they are working on the next update for WP7, Mango, probably means they are looking for ways to lock down the platform even more from genius intrusions like this. Look forward to the fix from Walsh, and your incremental update, very soon.
I also don’t know whether to assume that if I/You received the official update through the Zune desktop software on a “Walshed” phone, that there is no problem to be patched. Thinking about the cumulative nature of Windows Phone updates, anything that was not in the Chevron.Updater update that you installed, should have been included in the official update that you got to install on your handset without error. What’s next in this story?
