Microsoft Issues Workaround For Zune Freeze 277
UnknowingFool writes "As a followup to the Zune New Year's Eve meltdown, Microsoft has issued a workaround for what some users have correctly guessed was a bug caused by a leap year. To recover from the problem, let the Zune drain the batteries and restart it after noon on January 1, 2009. Many sites are reporting that Microsoft has 'fixed' the issue, but technically all Microsoft has done is to ask users to wait out the conditions that triggered the bug. Unless a software patch comes out, Zunes will suffer the same problem again in four years." Reader ndtechnologies adds, "According to posts in the Toshiba forum at anythingbutipod.com, the same bug that shut down millions of Zune 30's also affects the Toshiba Gigabeat S. The Zune 30 is based off of the Gigabeat S series and was co-developed by Microsoft with Toshiba."
It probably won't last another 4 years (Score:5, Funny)
Re: (Score:2)
After all the hell that people give Microsoft for not supporting a 9 year old OS? Yeah, right.
Besides, I know people who still have first generation iPods.
Re:It probably won't last another 4 years (Score:4, Insightful)
And if they broke, would they expect apple to fix them?
Suppose instead of this being Zune's firmware it was a microwave you bought 5 years ago. Would you have any claim to have it fixed (out of warranty, etc).
Re:It probably won't last another 4 years (Score:5, Insightful)
Re:It probably won't last another 4 years (Score:5, Informative)
My microwave has a firmware bug. After I heat something, if the next button on the keypad I press is anything other than "Reset", it locks up. It's incredibly irritating (since I'm usually putting something else in and trying to enter a new cooking time). That said, the microwave cost under $50...
Re: (Score:3, Insightful)
If I bought a microwave and it did that, I would probably never buy from the manufacturer again. Maybe if they apoligized for making such a crappy product and it was shown they now don't make defective products anymore. Though even then, if it was the exact same product as another mfg with the same chance for defects and such, I would buy the other guy's product.
Your bar is too low. If you bought it as a charity case or because you want to help out local / new businesses I could understand, but putting up
Re: (Score:2)
Why are software defects any different that hardware defects?
If my microwave had a defective gear in the motor that spins the turny-thing (technical term) that broke after warranty, I wouldn't expect it to be fixed. Is a defective line of code somewhere really all that different?
Re: (Score:3, Insightful)
Because software does not wear out?
Re: (Score:2)
The OBD (OnBoard Diagnostics) system on my 1996 Honda Odyssey "Minivan" had its "Engine Misfire" sensor intentionally disabled, which caused the emissions released to violate EPA standards. The EPA sued Honda, and both came to an agreement that gave owners free replacement of the defective components under a "warranty extension". The lawsuit was settled back in 1998, however. Seriously, did you think the same thing would have happened at any time recently under Cheney err, W?
Then there is also the Apple
Re:It probably won't last another 4 years (Score:5, Insightful)
This is software, the fault was there when it was purchased.
Re: (Score:2)
It's sometimes funny how >15 yro devices outlive new products.
Re:It probably won't last another 4 years (Score:5, Informative)
In UK law at least this is a significant difference... you can never tell in the US though.
Re: (Score:2)
Plus, this 'fix' will adversely affect the battery, shortening it's life and/or lessening capacity. Draining a battery to dead flat is never good. Having to do it to 'fix' a bug is like adding insult to injury (to Zune owners).
Re:It probably won't last another 4 years (Score:5, Insightful)
And if you look at the bug in the code [pastie.org] (line 259) it's atrocious. Something a junior programmer would be embarrassed about.
When days is 366 it causes an infinite loop. And also note that simply changing line 263 to use 365 causes a different bug. So the whole approach is wrong. It ought to simply be
while (days > daysInYear(year))
{
days -= daysInYear(year);
year += 1;
}
Re:It probably won't last another 4 years (Score:5, Informative)
It ought to simply be
while (days > daysInYear(year))
{
days -= daysInYear(year);
year += 1;
}
Hey, c'mon now; programmers are almost universally judged by their bosses by the number of lines of code they produce. The (buggy) MS code used 16 lines to do what you did in 5 lines. Therefore, the original (buggy) code is considered more than 3 times better than yours. No programmer interested in a good professional career would write code so simply and obviously correct.
This isn't really a joke. One a project a few years ago, I fixed several bugs by doing rewrites like yours, resulting in fewer lines of code. My record actually had a note indicating that I had negative productivity during that period, and my superiors had a real problem giving me a good review because of it.
Yes, I did find another job soon thereafter. But that wasn't the last time something like that happened.
(And I would probably save the first call of daysInYear(year) in a local variable, which would make the code a bit faster. But I could declare the local on a separate line, incrementing the line count, so it would look good to the line counters. ;-)
Re:It probably won't last another 4 years (Score:4, Informative)
Nah; most code-size measurements exclude comments, on the grounds that comments aren't executed by the computer, and thus aren't code. This puts subtle pressure on the programmers to not write comments, since this just takes time that leads to being behind schedule.
It's hard to imagine any rating system that's more screwed up than the system used in most companies to rate the output of their programmers. If they were consciously trying to sabotage the software, they probably wouldn't come up with any schemes nearly as effective as judging programmers by lines of code produced.
Re: (Score:2, Informative)
They start from 1980. You can see it on line 58. ;-)
And looking at line 59 you can see that there is planned obsolescence(!) for the year 2080. Zune owners should demand a refund
Re: (Score:2)
The Zune was in effect sold with a predictable and correctable flaw (leap years are very predictable), causing it fail out with normal wear and tear, which would class it as defective product.
In UK law at least this is a significant difference... you can never tell in the US though.
Perhaps the existing consumer protection legislation is one reason why it hasn't been sold in the UK?
Re: (Score:3, Funny)
That's ok; since I am an American you could have used grams of fairy dust and it would have meant as much to me as pounds and pence.
Re:It probably won't last another 4 years (Score:5, Insightful)
You can get the microwave (or a tape recorder, or a VCR) fixed by a third party (or do it yourself) depending on what part has broken.
Only Microsoft can fix these firmware issues. If the source code for the firmware was publicly available, someone could fix the problem and distribute the fixed firmware for free or for money, but since it isn't, only MS can patch it.
It probably won't last another 4 downloads. (Score:2)
The source code that's NOT available. [overooped.com]
Re: (Score:2)
Has Microsoft stated they will do the fix or are you just assuming that Microsoft wil
It probably won't last another 4 complaints. (Score:2)
Q: How many 30GB Zune devices are affected? How many Zune 30GB devices were sold?
All 30GB devices are potentially affected.
Q: Will you update the firmware before the next leap year (2012)?
Yes.
http://zuneinsider.com/archive/2008/12/31/30gb-zune-issues-officialupdate.aspx [zuneinsider.com]
Re: (Score:2)
Secondly, they have a detailed FAQ which explains the issue in detail and how they will fix it.
Re: (Score:2)
I have a better FAQ - see my blog [blogspot.com]. Crap code on a monumental scale!
Re:It probably won't last another 4 years (Score:5, Insightful)
Why are consumer electronics any different than any other product? Let's talk about items costing less than a laptop, so less than 2000.
Would you accept if your 5 year old ___ broke , was unfixable, and needed a new replacement?
You get the picture. Why are electronic manufactures exempt from shoddy products that don't have some sort of reasonable lifespan? Not wear and tear or dropping a product, just the product becoming unusable due to the product having some bug/feature to break it outright like the Zune.
As to a microwave, a 5 year old whirlpool oven broke on me and they no longer had replacement circuit boards. Whirlpool expects their products to have at least a 10 year lifespan. They pro-rated my equipment and sold a new unit, installed, for 33% of the cost. Now that's an acceptable solution for shoddy workmanship.
Re:It probably won't last another 4 years (Score:5, Insightful)
Because collectively we accept this. Sad but true.
Re: (Score:3, Interesting)
I think that at least part of the reason we collectively accept this has a lot to do with the idea that these devices are generally obsolete are at least significantly out of date after five years. If refrigerators and bicycles were making the same kind of advances as these other products, most people honestly wouldn't care if they junked out in five years. If your fridge was doubling in performance every 18 months, wouldn't you want to get a new one every six years or so to take advantage of the cost savin
Re: (Score:2)
but mom and pop won't even be able to scratch the surface of their eight core, eight gig RAM system with just office apps and email
Never underestimate the power of bloatware..........
Re: (Score:2)
Where were you able to buy a home furnace that cost you less than 2000? My wife and I got a huge discount on our furnace (she's an architect) and we still paid a fair amount more than that. And our house is not very large. Unless you live in a condo or a small townhouse (or perhaps Florida) you're going to pay a lot more than that for a furnace.
At any rate, I don't think that the standard is all that much lower for consumer electronics in general. Last year my parents finally replaced their TV, which wa
Re: (Score:3, Informative)
If the microwave was only 5 years old and it broke down, you are covered in England and Wales by consumer protection laws if it less than six years old and it break down. Just as long as you can prove it was not accidental damage, your covered for a free repair. :)
Just something for the UK readers here. Covers anything electronic.
It probably won't last another 4 RMAs. (Score:2)
Good thing your post is warrantied for six years.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
In the case of a microwave or similar household appliance (dish washer, washing machine, fridge etc.), if it breaks within only 5 years or even less from mechanical failure I'd never buy that brand again. If it breaks due to what is obviously a (software) design flaw that the manufacturer subsequently refuses to address (at their cost), same story.
Such stu
Re: (Score:2)
I have a 22+ year old microwave that won't die.
Unfortunately, it doesn't work correctly with PlaysForSure, no matter how many times I've called Microsoft.
Place a cup of water in the oven along with the PlaysForSure device to avoid possible problems from excessive standing waves..
Some microwaves do last a very long time. It wasn't that long ago I finally stopped using one that had a mechanical timer. Except for not having a rotating tray, I really liked it.
With no standby power for control electronics I fi
Re: (Score:2)
I hear you. My 1984 Sharp Carousel II Microwave is still alive and kicking just fine, although it is weaker (only 700W I think) than my 1200W new smaller microwave whose controls are much less intuitive than the Sharps. I much prefer the old simpler controls.
I'm not your average joe MS basher (Score:2, Insightful)
But I've got to say: this is just typical.
Re:I'm not your average joe MS basher (Score:4, Insightful)
I'm not your average joe MS basher
True enough; nowadays, the average Slashdot-dwelling MS basher will try to make some kind of reasoned, evidence-backed argument instead of just huffing loudly and saying "this is typical".
Re: (Score:2)
That definitely sounds like the average Microsoft basher. I think I hate Microsoft more than most, and hate Zune as much as you. Even so, I just wish my iPod and Fedora installations would only fuck up one day out of every four years.
Nice! (Score:2)
Re: (Score:2)
Testing!?! (Score:4, Insightful)
You would think that a company the size of Microsoft would have the resources to have a few Zunes in QA with their clocks set ahead. But hey, there were no lessons to be learned from Y2K, right?
Re: (Score:3, Funny)
What's Y2K? Isn't it 1909 now....?
Re: (Score:2)
Clocks set ahead? Leap year is a really well-known edge case. There's no acceptable reason that setting the date to the boundaries in a leap year (including February 29, and the day before, and the day after) shouldn't be part of the standard tests.
Re: (Score:2, Funny)
Well, judging from the number of Zune owners who couldn't listen to music on new years eve, it probably should be.
What, all three of them?
Re: (Score:2)
Re: (Score:2)
I said "setting it to the boundaries." I explicitly included the February case because it's possibly a less obvious boundary.
The boundaries would obviously be Dec 31 on the previous year, Jan 1 on the leap year (though it's hard to envision code on which these would break, they should be tested), Dec 31 of the leap year, and Jan 1 of the next year.
In fact, it might even be reasonable to test the first and last day of every month of the leap year. Addition errors could occur at any point.
Re: (Score:2)
You're assuming that MS has some sort of institutional competence.
Re: (Score:2)
The Source Code (Score:5, Informative)
Re: (Score:2)
Ok, it's been posted on every website and every forum about this issue on the entire Internet...
Is there any verification at all that this is actually the buggy code? Or did someone just pull it out of their ass? (I mean, obviously this code has the same bug, but is it the same code the Zune uses?)
Re: (Score:2)
I did a little googling and came up with this post [zuneboards.com], which claims that the code comes from the Freescale web site. Also a more informative explanation of the bug for those of us not up to analyzing all that C code.
There are two things that have me scratching my head.
First, doesn't anybody at Toshiba or MS do code reviews?
Second, doesn't Windows CE have libraries for converting from one date type to another? Is it not practical to use them in drivers? Or did somebody hand-code this conversion because they cou
Re: (Score:2)
For anyone who's too lazy to search for it, the specific issue is on lines 259-274. (That would of course be in the "loop forever on leap day" function. ;-)
Re:The Source Code (Score:4, Insightful)
Look through the function starting at line 249: this causes the infinite loop.
Assuming proper code management and version control they will probably branch off a release sometime for release in 2007, and in the meantime continue writing the next version, which may have been mostly finished in 2007 already but maybe only pass quality control in 2008 for release then.
And this piece of code had not been tested/reviewed properly apparently.
Re: (Score:2)
The copyright on that code ended in 2007, so the code hasn't been edited since then.
Copyright doesn't 'end'. It's somewhat erroneous even to put a 'until' year into a copyrighted work; just put the start year.
Re: (Score:2)
Re: (Score:2)
Cause of the Zune crash? Third party drivers (Score:2, Informative)
A quote from the ZuneBoards forum:
Amazing.. (Score:5, Funny)
The first step to fix any microsoft problem - reboot.
Re: (Score:2)
You write that as if it was a bad thing.
Instead of bothering with a fix (Score:5, Funny)
Wouldn't it be faster for Microsoft to simply give each of the 8 users a call and walk them through the work-around? If their numbers change in the next four years, they can simply notify Zune support.
Re: (Score:2)
[posting to undo moderation... I chose the wrong post]
Draining battery all the way (Score:3, Insightful)
Can't be good.
I've seen this in laptops leading to drastically decreased storage capacity.
My Experience (Score:5, Funny)
I hadn't turned on the Zune before I read about the problem, so I just left it off and turned it on the morning of Jan 1 and everything worked fine, no need to drain battery or anything.
The above is not an admission that I own a Zune, just what I theoretically would have done and the theoretical results, based on heavy pretend observations.
Zune 80 (Score:2)
Does anyone know why the Zune 80s didn't crash? I assumed they ran the same software and similar hardware.
Re: (Score:3, Informative)
Re:Zune 80 (Score:4, Informative)
Q: Why is this issue isolated to the Zune 30 device?
It is a bug in a driver for a part that is only used in the Zune 30 device.
Out of curiosity... (Score:3, Interesting)
Why does a music player need to know the date or time at all?
Re: (Score:2, Informative)
Why does a music player need to know the date or time at all?
For the DRM to work.
Non-DRM using pirates win again, arrrr!
Re: (Score:2)
DRM has gotta be at the top of that list of reasons..
Re: (Score:3, Interesting)
Re: (Score:3, Informative)
Anything from month-to-month media rental (for example, the Zune Pass) to simply displaying the time like a watch (how many people do you know who pull out their cell phones to check the time? I know at least 4, and it amuses me to no end, but in any case a "current time" display was one of the most-requested features for the Zune 3.0 firmware).
All they've done (Score:4, Interesting)
... all Microsoft has done is to ask users to wait out the conditions that triggered the bug.
And considering that the bug only came to light two days ago, that's pretty good.
I speak from experience. I'm a tech writer, and I've written literally thousands of bug summaries for customer support web sites and release notes. (In 1999, I did almost nothing else.) Finding the problem, identifying a workaround, and getting it out to the public in such a short time is pretty impressive.
Presumably they're working on a patch, but they won't say they anything about it until it's ready to go. It's an ironclad rule that you never talk about these things before they're ready, not if you want avoid vaporware lawsuits. It should be obvious to anybody that creating, testing, and staging a software patch takes a lot longer than writing up a workaround.
Re: (Score:2)
Of course, one can credibly claim that the bug should never have existed in the first place, given that the loop triggering the bug wouldn't have passed a code review in any half-decent software organization.
Re: (Score:2)
I think "credibly claim" is a mild way of putting it. Not only did they neglect the code review, but it doesn't make sense to me that the code even exists. Doesn't Windows CE have libraries for converting data like this? Assuming, of course, the library was properly written. But that's the advantage of using a library instead of coding it yourself — any given bug is likely to bite somebody else before it bites you.
Alas, I've seen bugs even stupider than this. Once I documented a BIOS bug that was a bo
Re: (Score:2)
And considering that the bug only came to light two days ago, that's pretty good.
Actually, it's pretty shitty. Because let's face it, Microsoft has an infrastructure in place for delivering this sort of information already, so releasing it is a non-issue; and all they had to do to find out this worked was pull a Zune battery and reconnect it, and see how the system was. And this is a seriously screwed workaround, because the Zune's battery doesn't want to be completely discharged. In fact, it frowns pretty heavily on that sort of activity. Battery abuse is a terrible, terrible thing. Of
Re: (Score:2)
Actually, it's pretty shitty. Because let's face it, Microsoft has an infrastructure in place for delivering this sort of information already, so releasing it is a non-issue...
Dude, I do this shit for a living. Trust me, two days from first bug report to documented workaround is pretty damned good. Getting the information, writing it up, having it reviewed, staging it on the web site, all this takes time.
That's assuming that you follow proper procedure in creating your documentation. You can always have shortcuts. But it's the shortcuts that create this kind of problem in the first place.
Why does a music player care what day it is? (Score:2)
I can't say what Apple would do. But, this begs the question why a player that merely plays music needs to figure out what day it is. I can understand why something like the iPhone and iPod Touch might have a bug like this. (Actually, I can't because these both use a real OS). But the Zune is similar to my iPod Classic, and my iPod Classic doesn't know the date and time unless I set it.
Re: (Score:2)
Well, for one, the Zune has a clock. For 2, it has an application framework on it that may need date and time stuff (.NET framework, used among other things for XNA...for games...and those often need it). Zunes are somewhere in between the classic Ipod and the Touch, feature wise.
Re: (Score:2)
bah, just realized I read your post too quickly (which is sad considering how short it was). I set the clock on my computer too, doesn't mean it doesn't have an internal one for the rest :). Anyhow, the rest of what i posted still stands. Whoopsies!
Re:Can anyone explain this bug? (Score:5, Funny)
if (year % 400 == 0) hard_crash()
else if (year % 100 == 0) boot()
else if (year % 4 == 0) hard_crash()
else boot()
Re:Can anyone explain this bug? (Score:5, Informative)
Here's the actual buggy code [pastie.org].
The error is infinite loop in ConvertDays(), starting at line 249. The first loop does not cope with "IsLeapYear() == true" when "days == 366"
Re: (Score:3, Insightful)
Re:Can anyone explain this bug? (Score:5, Funny)
Typical MS. They're copying Apple again but this time too literally. :P
Re: (Score:2)
Here's the actual buggy code [pastie.org]. The error is infinite loop in ConvertDays(), starting at line 249. The first loop does not cope with "IsLeapYear() == true" when "days == 366"
Wow, that was pretty cool. Thank you.
Re: (Score:2, Informative)
Re: (Score:2)
That is deeply flawed code. (Why? Left as an exercise to the reader.)
The correct solution, if you want to keep the looping algorithm, is to add "else break;" as the alternate case of the "if (days > 366)" test: The infinite loop case then terminates the loop with the right year and days=366, which is the expected result.
Re: (Score:2)
I have to wonder about calling isLeapYear(year) every single time when if the last year was a leap year you have three guaranteed non-leap years and a leap year except for 3 years out of every 400.
Soooo. If this is the code and the flaw, why were only 30 GB Firmware 3.x Zunes affected?
Re:Can anyone explain this bug? (Score:5, Informative)
The function iteratively converts days into years. If there are more days left in the days variable than there are days in a year (365), then the days in that year are subtracted from the days variable and added as 1 year to the year variable.
It starts with year=1980, because the RTC counts days since 1/1/1980 (inclusive). For normal years, it subtracts 365 days and adds a year. After the first iteration, year is 1981 and days is the number of days since 1/1/1981 (inclusive). If the loop is currently looking at a leap year, then 366 days are subtracted from the days variable and 1 year is added to the year variable. So far the code looks like this:
while (days>365){
if (IsLeapYear(year)){
days-=366;
year+=1;
}else{
days-=365;
year+=1;
}
}
The crazy thing is that someone must have looked at the edge case in that code: The last day of a leap year. On that day, the above code fails by incrementing year once too often, because at the beginning of the last iteration, the loop test indicates that there are more days in the days variable than there are in a year, but there are not, because a leap year has 366 days. That edge case is caught by the second if:
while (days>365){
if (IsLeapYear(year)){
if (days>366){
days-=366;
year+=1;
}
}else{
days-=365;
year+=1;
}
}
The loop goes into the last iteration because of the loop condition which is on day short, then the IsLeapYear test selects the first branch, and instead of blindly incrementing the year and subtracting 366 days, there is an extra check if there are really more days left to make a full year...and then it fails to handle the only case where the code fails without that extra check. It should simply break the loop:
while (days>365){ // days==366 && IsLeapYear(year): end of calculation
if (IsLeapYear(year)){
if (days>366){
days-=366;
}else{
break;
}
}else{
days-=365;
}
year+=1;
}
(Matt's code always reduces the day count by 366. 1980 was a leap year.)
Re: (Score:2)
(Matt's code always reduces the day count by 366. 1980 was a leap year.)
I see that daysInYear is recalculated at the end of each iteration. What is your problem with that?
Moreover, counting years must be a "CS 101 introduction to Jave" level problem. Why are we analyzing this? Look at the MS code, laugh at the programmer and their code review practices and move on!
Re: (Score:2)
Sorry, I overlooked the second daysInYear assignment. That code would actually work, but because of the unexpected code duplication, I would have written it like this:
year = ORIGINYEAR;
while (true) {
daysInYear = IsLeapYear(year) ? 366 : 365;
if (days <= daysInYear) break;
days -= daysInYear;
year += 1;
}
Re:Can anyone explain this bug? (Score:5, Informative)
{
if (IsLeapYear(year))
{
if (days > 366)
{
days -= 366;
year += 1;
}
}
else
{
days -= 365;
year += 1;
}
}
source code that caused the bug.
Re:Can anyone explain this bug? (Score:5, Informative)
In case you can't see how this fails: On December 31st in a leap year, days is counted down to 366 like it's supposed to, and then the IsLeapYear() test is true, but days>366 is not, so the loop body does nothing and the while becomes an infinite loop.
This code can not possibly have been accepted in any kind of code review. Someone would have pointed out that there are O(1) formulas for calendar calculations.
Re:Can anyone explain this bug? (Score:4, Insightful)
For that to happen, MS would have to follow standards. You know where this discussion will go.
Re: (Score:2)
When days == 366 and IsLeapYear() evaluates to true, you loop forever on the while because you never decrement days internally to the loop under that exact condition.
Re: (Score:2)
Was this a contest of making the code as complicated as possible? And it would be even more complicated if the missing line was added.
To a hobby programmer like me, it seems that this code could be simplified considerably:
daysOfYear = 365 + IsLeapYear(year);
while (days > daysOfYear )
{
days -= daysOfYear;
Re: (Score:2)
See the AC above (and six minutes before) you: the bug was in a routine that breaks down a count of days into a days/months/years; it has absolutely nothing to with DRM.
So it wasn't in a new, extremely complicated code written to hide something, but in code that has been implemented thousands of times flawlessly (and more efficient) before - gee, that's a relief.
Re: (Score:2)
So, what we're saying is that Microsoft will ask the appropriate official bodies to redefine core standards so that every manufacturer of processor-based equipment has to ensure their kit runs in an infinite loop on 31st Dec in leap years to conform with Microsoft's operating model?
Re: (Score:2)