Brandon Watson Opens Up On Walshied Phones

There’s been a ton of discussion about Walshied Windows Phone. Those are phones that used a workaround to force an update. And to be clear, Microsoft is unclear on whether those of us who forced the update by using the Hungarian method are in the same boat or not as they haven’t tested it yet, but we’ll all know soon enough as the 7392 update is pushed out. Regardless, this is an interesting read as it explains why Walshied phones are not in the same state as officially updated phones and it provides some open commentary on the issue and confirms that the Chevron guys are working with MS on a workaround to fix this. I actually find it hard to complain that MS isn’t throwing a ton of resources at this issue but they clearly are taking it seriously and assisting the Chevron guys to test their fix. Here’s the post in full and shout out in the comments:

Yesterday, Eric announced that there would be a new update for Windows Phone. You can read his post to see what all is included, but I wanted to focus on a specific issue: phones “updated” using any unofficial mechanisms.

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.

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.

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.

When we test our update process, we test against a known state machine. Further, as a health protection mechanism, the phone will always try to recover from an error state (as in an incomplete update), and will begin doing things to solve for the fact that it is in an unknown state. This is the reason why phones started downloading OEM updates after forcing the update via this unofficial tool. It’s also the reason why people who used the unofficial tool to get to 7390 reported that their phones later updated to 7390 via the Zune PC software. The state machine looked more like pre-7390 than it did 7390. However, because of the existence of some of the 7390 bits on the phone, and the fact that the 7390 update process was not intended to run against this a priori unknown state machine, the result was an incomplete 7390 update.

If you have a phone that was updated using this unofficial tool, and you attempt to update to 7392 from the Zune software, you will get the error code 80180048. Zune is the only official way to update the operating system on the phones. The mobile operators purchase Windows Phones from the manufacturers, and they are the ones who are authorized to flash phones for the mobile operator. The mobile operator store locations are not capable of flashing phones on-site with an original OS image, which means that you will most likely have to return to a store and submit your phone for a manufacturing return. However, because of this known error code, it is up to the mobile operators as to what they want to do with your phone.

We understand that this isn’t ideal. Unfortunately, our engineering priorities are focused on improving the process by which updates get to Windows Phone, issuing the security update you just got and working to getting Mango to market. Undoing this specific problem was not in our schedule.

However, the creators of the unsupported tool are a clever bunch, and wanted to get a timely fix created for customers who have put their phones into this state. They believe they have created a way to get these phones back on the officially supported path. We will work with them to validate their solution and applaud the team for taking responsibility to do this.

I personally feel really bad for customers who find themselves with phones which are now stuck. Again, I can’t promise a fix right now, but if you want to share your experience and let us know how your phone is behaving as a result of this external tool impacted my email is brwatson@microsoft.com. I only ask that you please be constructive.