Excel 2007 calculation bug fix released after two weeks

A fix for the Excel 2007 calculation bug affecting results around 65535 and 65536 has been released in the last few hours. The Excel team blog post says:

As of today, fixes for this issue in Excel 2007 and Excel Services 2007 are available for download…We are in the process of adding this fix to Microsoft Update so that it will get automatically pushed to users running Excel 2007 or Excel Services 2007.  Additionally, the fix will also be contained in the first service pack of Office 2007 when it is released (the release date for SP1 of Office 2007 has not been finalized).

Microsoft knowledgebase article KB943075 discusses the fix and gives the usual details for what versions and sizes the updated files should have after the fix. The version number of Excel.exe is altered from 12.0.6024.5000 to 12.0.6042.5000. Now read that again – yes, easy to miss the difference from ’24’ to ’42’ if you look too quickly. (NB: you may have a different version, mine is at 12.0.6024 after installing the security update as per KB936509, as far as I can tell.)

The download for the fix for Excel 2007 (33Mb exe file) is linked from the Excel team blog as well as from the KB article. The blog post also has links for Excel Services 2007, both 32 bit and 64 bit.

6 Responses to Excel 2007 calculation bug fix released after two weeks

  1. Adam Vero says:

    David Overton has some interesting points to make about the apparent lack of effort by Microsoft (my words, not his) to make sure their users and potential users knew about this bug.

  2. Thaddeus says:

    I just loaded the hot fix, I think there is still an error.
    Prior listings at http://blogs.msdn.com/excel/archive/2007/09/25/calculation-issue-update.aspx?CommentPosted=true#commentmessage
    warned aboout =dec2hex(850*77.1)returning fffe,
    when it should return ffff.
    The hot fixed excel returns fffe for the calculated value of (850*77.1).

    Do the following:
    a1 =850*77.1 (65535)
    b1 =dec2hex(a1) (fffe)
    c1 =hex2dec(b1) (65534)
    d1 =sqrt(850*77.1)^2 (65535)
    e1 =dec2hex(d1) (ffff)
    now I can see b1 is not equal to e1

  3. James Hopes says:

    Here is an interesting post that talks about the defect and provides an autopsy!

  4. Adam Vero says:

    As you say, this has been previously misreported as being a bug. It has also been previously explained, for example in the Google Groups thread on the subject of the bug which I previously linked to. DEC2HEX is explicitly documented as taking an integer as input, and if you give it anything other than an integer, it simply ignores everything after the decimal point.
    As has also been explained ad nauseam, all versions of Excel (and most other spreadsheet programs) use some form of floating point arithmetic. So 850*77.1 is not exactly equal to 65535, but to 65534.99999999999272404239. Normally Excel takes the decision to display this as if it was equal to 65535, and many functions do similar ‘intelligent’ processing before using an argument (TRUNC or ROUNDDOWN, for example, will give 65,535 as you would hope). DEC2HEX simply does not do this, it takes the value as it stands and ignores the decimal part.
    Now – how often do people actually use DEC2HEX in real life? And how often is this used on input values which are based on floating point calculations? Maybe a new function ROUND2HEX is needed which is equivalent to DEC2HEX(ROUND(foo,0))

    Thanks for the comment. I had previously read the post you link to, but it only gives a very sketchy view of the problem and a couple of trivial examples – hardly an autopsy. There is no discussion of the seriousness of the bug and how it affects ‘real’ values, nor any mention in the comments or a follow up post about the availability of the fix.

  5. Jason Hicks says:

    Seems Excel has issues importing csv with numbers of more than 15 digits as well. when you open the CSV it shows the number in scientific format and when you convert to number format it all digits above 15 are turned to 0.

    seems that ramifacations of the problem will pop up in many locations.

  6. Adam Vero says:

    Thanks for that, Jason. I have not seen that one myself but it does make sense that it should have a problem since 15 digits is Excel’s limit. If you type more than 15 significant digits, the last ones get dropped, so it’s not just from CSV.
    It would be much better if it just dropped the least significant part though, rather than dropping to zero, that’s just disastrous.

%d bloggers like this: