Anatomy of a Software Bug

re: Anatomy of a Software Bug

Larry Osterman — Wed, 19 May 2004 21:13:00 GMT

So what exactly is the Mac's open file limit?

Windows NT's is in the hundreds of thousands of handles per process (depending on the amount of physical RAM available), I'm surprised you guys didn't notice that the file handle count for Word was getting that high.

Even Win9x had an open file handle limit in the tens of thousands IIRC.

re: Anatomy of a Software Bug

TWR IV — Wed, 19 May 2004 21:35:00 GMT

Thanks for the interesting post. I remember the disk full error with great dismay although happily I haven't seen it in years.

If you want lists of reproducible Word 2004 bugs I'd suggest you put out a blog notice. We've already noticed a few around here, although nothing serious so far.

re: Anatomy of a Software Bug

matthew — Wed, 19 May 2004 21:44:00 GMT

In DOS, I used to set files=20 to save my conventional RAM. I fiddle with this, moving it up and down, as some programs didn't work if it was set too low.

re: Anatomy of a Software Bug

Ryan Gregg — Wed, 19 May 2004 22:05:00 GMT

Great post! It's really nice being able to read information about products I use everyday and what it took to development and resolve there issues.

re: Anatomy of a Software Bug

B.Y. — Wed, 19 May 2004 23:18:00 GMT

I remember reading in a book (by Steve Maguire, I think) saying that Mac and Win Word codebases have been merged. Are they split again ? I can see the reason for GUI code branching, but not internal stuff like undo levels.

re: Anatomy of a Software Bug

David Buxton — Wed, 19 May 2004 23:44:00 GMT

Wasn't this bug in Mac Word related to the classic Mac file open limit of 384 open handles? A fairly well known limit to the classic Mac system. Mac Word 6 and later had a habit of using file handles for fast saves without closing them properly, and at some point a user would hit the max open file limit, hence these problems?

re: Anatomy of a Software Bug

Eric Albert — Thu, 20 May 2004 05:26:00 GMT

A couple questions from above are answered by Apple's <a href="http://developer.apple.com/technotes/tn/tn1184.html">Technote 1184</a>, "FCBs Now and Forever".

The quick summary: Mac OS versions prior to 9.0 were limited to 348 open files or, more correctly, open forks. The limit was actually far lower in very early system software releases, but that's another story. Mac OS 9.0 increased the open file limit to 8169.

Mac OS X, being a Unix-like system, has completely different open file limits.

re: Anatomy of a Software Bug

Nate Friedman — Thu, 20 May 2004 06:46:00 GMT

great article, reminds me of the details, and explanations of those that you'll find at http://www.folklore.org/index.py

re: Anatomy of a Software Bug

Rick Schaut — Thu, 20 May 2004 09:30:00 GMT

Being a BSD derivative, the open file handle limit on OS X is 256. It can be modified, but that's through a native BSD call. The technote is <a href="http://developer.apple.com/qa/qa2001/qa1292.html">here</a>

re: Anatomy of a Software Bug

Rick Schaut — Thu, 20 May 2004 09:42:00 GMT

B.Y. the Mac/Win code bases were the same as of Word 6.0. We forked the code bases as of Office 98.

In theory, you'd think the internals should remain within the same code base, but, in practice, it becomes a source, and quality, control nightmare. Unless you have everyone doing quality checks on both platforms for every code change, you end up with Win developers breaking the Mac product and vice versa.

re: Anatomy of a Software Bug

aellath — Thu, 20 May 2004 13:15:00 GMT

i *knew* there was a reason i assiduously avoided Office! AppleWorks has rarely (in a quick scan of my memory just now, no events occur) screwed up on me.

re: Anatomy of a Software Bug

Chris — Thu, 20 May 2004 15:35:00 GMT

Hmm... seems to me that it would just be easier (and better allocate resources on the machine) if Word would just do a better job of cleaning itself up every now and then to not have so many open files.

re: Anatomy of a Software Bug

Larry Osterman — Thu, 20 May 2004 16:00:00 GMT

Oh my goodness. 256 handles/process? That's obscenely painful. I'm not surprised this showed up on Mac's only.

re: Anatomy of a Software Bug

Eric Hildum — Thu, 20 May 2004 17:28:00 GMT

Thanks for the explanation of the Cut and Paste process. Now I understand a particularly nasty bug affecting the US and Japanese versions of Windows Word that I encountered while working in Japan. Summary of problem: receive a document from the US (made using US Word), cut and paste into Japanese document (using Japanese Word). Upon autosave or save, Japanese document is destroyed in memory and on disk. The delayed copying of the text would explain the behavior perfectly. Apparently, there was a bug in the text copy code executed when documents were saved.

By the way I did try to report the bug via our $500,000+/year global support contract with Microsoft, and was told directly by our Microsoft support representative, and I quote, "I wouldn't know how to file a bug report for that." Never was able to get it addressed, even though I had two good sample documents for reproduction of the problem.

re: Anatomy of a Software Bug

Beth Rosengard — Thu, 20 May 2004 17:48:00 GMT

Fascinating! Thanks, Rick.

re: Anatomy of a Software Bug

John A. — Thu, 20 May 2004 18:26:00 GMT

My God! You mean to say that you couldn't pin this bug for years because you couldn't get to it with the debugger? What about debugging through code manipulation? This isn't Schroedinger's cat.

re: Anatomy of a Software Bug

Kiliman — Thu, 20 May 2004 18:50:00 GMT

One of the things that really bugs me is when you get misleading or unhelpful error messages (like "Unexpected Error").

I'm assuming that since Windows and OS X are completely different platforms, that the "Disk is full" error is coming from Word and not the OS.

Wouldn't it have been possible to instrument Word so it would display the actual error code returned from the OS? I imagine for Windows the underlying error code would be ERR_TOO_MANY_FILES_OPEN.

Kiliman

re: Anatomy of a Software Bug

skeptic — Thu, 20 May 2004 19:13:00 GMT

The part about this story that bothers me is this line: "At this point, we still don’t know that the problem involves the OS’ open file limit. That discovery didn’t happen until this past summer." Well, users had posited this years ago as the explanation of the problem. So why didn't this knowledge filter up to the MacBU? Because there's no way to report it? Because Microsoft is in denial? Also, why doesn't Microsoft just stop spewing these temporary files all over my hard disk? (Remember when they used to be *visible*???) Isn't there anyone at Microsoft who is ready to admit that this architecture sucks?

re: Anatomy of a Software Bug

Rick Schaut — Thu, 20 May 2004 19:44:00 GMT

John, I did leave out a few details in the story. In answer to your question, yes. I wrote almost as much debug-only code trying to track this down as I've written shipping code for some features.

Kiliman, that sounds easy on the surface, but there are several places where a failure in an OS call could result in that error message. Knowing where to instrument is almost as difficult as tracking down the bug itself.

Remember, also, that the key point in this, the discovery about the open undo tracking while header/footer fields were being updated, would never have been caught by an instrumented version. It's also a scenario that can't be duplicated by running a macro to simulate user behavior. The key to getting that down was having the bevy of diagnostic tools available on Mac OS X.

Skeptic, there's a difference between "knowing" the source of a problem and being able to prove it. It's like knowing that someone has committed a crime, but being unable to prove that fact in a court of law. What we couldn't do was prove that this was the source of the problem. A sure way to introduce other bugs that are potentially worse than the one you're trying to fix is to make some change to the code when you can't prove that the change actually fixes the problem.

re: Anatomy of a Software Bug

MacJack44 — Thu, 20 May 2004 21:16:00 GMT

This saga is truly informative (if exhausting), and supports my growing conviction that both OS development (by any company) and software development (by any company) has reached an overload limit.

Notice that in both MS and Apple cases, advancement of the OS has resulted in endless updates, vulnerability discoveries and too much time and money spent by consumer/users just to "keep up." The same applies in "simple" word-processing apps. AppleWorks ported to OS X is buggier, less useful and more annoying than it ever was under OS 9 (for example). Third party T/Es like Nisus Writer have taken ferrrevvverrr to reach full featured useability and suffer from the same kind of "generational bugs" as OS X and AppleWorks.

MS Word and MS Office are a perfect example of trying to "do all, be all" to prospective customer / users. But this is consumer choice, the line of thinking goes, "Better buy the whole hog, might need it some day..." Or the ever-popular: "Gotta have the latest version" muck. When in fact, I'd bet there's a large percentage of users who use only a fraction of MS Office features. And, to "just write a novel" you need only use RichText format.

This nonsense causes real problems: when publishers, for example, demand electronic submissions be in Word format. Why? There's no legitimate reason, other than a kind of mindset prejudice.

Simply put from the consumer / user standpoint: We have committed the sin of expecting too much from our computers. The "computer companies" are only trying to satisfy "Demand" (with a capital "D"). Their efforts (as exemplified by Rick's story) have been heroic, yet there's no end in sight for this kind of problem -- which ultimately falls on the shoulders of end users.

I'm not against "newest and best" but have disciplined myself to use and want "just what I need" to communicate, to enjoy myself and to stay informed. I think it's time that everybody just slowed down a bit.

re: Anatomy of a Software Bug

Ryan Clark — Thu, 20 May 2004 21:48:00 GMT

Wow. As a Mac user, and someone who's been using Word for quite a while, it was fascinating to read about what had been causing the dreaded "disk is full" bug. I used to work as a consultant in our university computer lab and it was incredibly frustrating when people using Word 2001 on the Macs would run into this problem.

re: Anatomy of a Software Bug

John Fisher — Thu, 20 May 2004 22:32:00 GMT

Very well-told story.

I am completely in sympathy with the problem. Its not MS fault that Word
is too large - nobody wants Works though its usually free; its not the developer's fault that Word changes too much and
too often. The problems are endemic to large, complex software with
millions of users. Other Windows software I use is equally buggy, and
frequently has less usable design.

However, I also think there is a near-total lack of two aspects of good
engineering practice at MS: 1) they have never understood trace,
logging, and error messages 2) they do (did) not implement code dumps correctly.

As one commenter pointed out, if they had simply passed through the
actual OS error it would have helped. Better yet the code that failed
should have logged a failure indicating what code failed and why.

If they were able to dump their code correctly, they would be able to
run Word in the debugger, dump it, and sift through the output to find
which code failed, and what the values were at the time it failed. My ( NT4 era ) experience was that the debugger was buggy and symbols did not always align.
Having a power-of-two number for a value would have been a strong hint here.
MS paid support is infamous. We had the same dead-end experience with
fundamental problems with NT4 Wolfpack failover ( in the end it never
worked ) at a company in which MS had some ownership.
Lastly, there should never be 'unlimited' anything. Unlimited Undo is a
marketing standard, not good engineering. Developers should always place
arbitrary limits on repetitive actions to prevent unknowable results
like this. If there had been a limit, and a log entry had then said, "UnDoer reached u_limit" all would have been easily fixed. Their undo function is so complex, that it may not qualify as
'repetitive.' If so, this might be a sign that it is inherently too complex.

re: Anatomy of a Software Bug

RG — Thu, 20 May 2004 22:33:00 GMT

Thanks for the detailed walkthrough ... I would love to see a similar explanation as to why text copied from Word 2004 and pasted into iChat comes out as a black graphic blob. It will paste fine into Mail, TextEdit, etc. (and then copy/paste from there into iChat), but it won't go directly into iChat.

I suspect it's an iChat issue, since it pastes fine elsewhere, but I can't find another Mac program that causes the same iChat behavior...

re: Anatomy of a Software Bug

Paul Berkowitz — Fri, 21 May 2004 00:09:00 GMT

Great story, Rick.

But really only 256 open files in OSX, compared to 8196 in OS 9?? I remember that joy that ensued when 384 increased to 8196. Is there something else in OS X that makes such a minute number of open files feasible? (Such as - do they get closed automatically or something like that?) I have never run into this limit in OS X in any app. Something just doesn't sound right here, Rick. Do you, or anyone, have an idea where to look this up?

re: Anatomy of a Software Bug

Kiyooka — Fri, 21 May 2004 00:42:00 GMT

Fascinating reading about how things work from the inside.

I am looking for a contact in the MacBU Office group. As creator of arguably one of the most successful office add-ins of all time, and now on the mac, I'm interested in writing some add-ins for MacOffice. I sent some email to s sinofsky but he's apparently PC only, as are all my other contacts.

Do you guys have an add-in/office evangelist that you could point towards me? My contact nfo is on my blog site (above).

-gen

re: Anatomy of a Software Bug

OS X file limit — Fri, 21 May 2004 01:05:00 GMT

256 is only the baseline limit in OS X, per process.

In OS 9, I believe the limit was global (but changable by some utilities).

The actual limit in OS X depends on the amount of RAM in the system (more RAM, more file allowed). Also, this limit can be changed by the application. I don't know if there is a fixed upper limit.

Photoshop and Illustrator hit the same limit when porting to OS X (due to an OS bug that left files open after certain API calls).

Betalogue

TrackBack — Fri, 21 May 2004 05:11:00 GMT

Betalogue

re: Anatomy of a Software Bug

SomeRandomGuy — Fri, 21 May 2004 02:33:00 GMT

Larry, the 256 open file limit is a soft limit imposed on processes so that they can't go around eating system resources. In a shell you can use 'ulimit' to increase it, or in an app can use a BSD API to increase it if needed. There is a way to increase the limit globally for all processes, but I don't want to post it since it is a bad idea to ever use it.

The default open file limit for the system is 12288, but this can be increased using the systcl command to increase kern.maxfiles if you really needed to.

re: Anatomy of a Software Bug

SomeRandomGuy — Fri, 21 May 2004 02:36:00 GMT

I didn;t explicitly explain it, so I guess I should say that the 256 limit is per-process. So Word eating 240 files has no effect at all on Photoshop etc. until you get into the 12288 open files range at which point you probably have bigger problems.

re: Anatomy of a Software Bug

JD — Fri, 21 May 2004 11:55:00 GMT

I've dealt with this problem at clients for a long time now and to have a different perspective is helpful. However, I'm still of the opinion that most people would be productive and happy with the equivalent of Word 5.1. There wasn't a lot of extra stuff in the way and one could get a document completed quickly without the "wizards" and "assistants" popping up and needing to be killed one by one.
Take the code from that, port it, sell it for $99-I'd suspect that lots of people would buy it because it would be small, fast, and easy to use.
I'm of the opinion that smaller and more focussed is the way that software should be looking.

Betalogue

TrackBack — Fri, 21 May 2004 16:41:00 GMT

Betalogue

Runtime error logging

Gideon Greenspan — Fri, 21 May 2004 16:23:00 GMT

Rick,

Interesting post. But maybe I'm missing something - surely this would have been tracked down much earlier by some runtime error logging code, switched in and out with a flag? You should be able to flip a header flag, and get *every* error code returned by an OS call or internal function, logged assertion-style in a text file with the source file name, line number and error code. For projects the size of Word, I think this should be built-in from the bottom up. It also lets you send debug builds to your users and then ask them to send back the log - it's been a lifesaver many times with my own programs.

Gideon

re: Anatomy of a Software Bug

Larry Osterman — Sat, 22 May 2004 20:43:00 GMT

On my current Windows XP machine, the handle count for the system is 10509. This isn't just file handles, NT doesn't differentiate between file handles and other kinds of handles.

There are 14 processes with more than 256 handles open, including IE (345), perfmon (314).

I'm surprised that a modern operating system like OSX has hard coded limits of any kind to be honest.

But this is totally off-topic, and irrelevent to a rather remarkable piece of detection.

Btw, for those like Gideon and John A, and Killiman. The fact that the Mac has such a restricted limit and Windows effectively doesn't have a limit drastically reduces the ability to diagnose the problem. With NT processes routinely having hundreds of handles open, Word's having one or two more simply falls out in the noise factor, while on OS X, those two handles could easily be the difference between a trivial resolution and one that requires much more work.

re: Anatomy of a Software Bug

Josh — Sun, 23 May 2004 05:20:00 GMT

Yadda. Yadda. Yadda.

I've got Word v.X and have installed updates 10.1.2, 10.1.4, and 10.1.5. And yet the bug still occurs... specifically when I have been working for hours and have saved the document many, many times. (In other words, only when I've worked really hard, and am really stressed and tired.)

I suppose the most important question now is: is this fixed (finally) in Word 2004?

Sheesh.

re: Anatomy of a Software Bug

Jason — Tue, 25 May 2004 13:03:00 GMT

hi,
i came accross to a software quote on a web site that says something like, vendors create buggy software to be able to sell it. as i remember this is from a famous author, but i lost the address. does anyone know about this quote and its author?
thanks

re: Anatomy of a Software Bug

Benjamin Huot — Thu, 27 May 2004 20:33:00 GMT

I stopped using Word within a year because of it crashing so often. That is what interested me in coding (so I could fix the errors) until I found that there was free software available that had over 90 percent of the functionality. And if there was an error, at least I didn't have to pay hundreds of dollars to call Microsoft or for buying it in the first place. Then when OS X came out, I found that you could buy commercial software from small companies, whose software is much cheaper and their support is much better. A large company should be able to support their products much better and have the money to test it in more conditions for errors, yet they don't. I have a strong suspicion that the bigger the company, the bigger the scam. It is a similar problem to how the US can possibly lose a war when they are at least 20 years ahead of the other most advanced Army in the world (of the technology that isn't classified). You can have overwhelming firepower, but if you don't have the intelligence to focus it at the right place and time, you can be defeated by a much smaller force. I would buy products from Mircosoft if they would certify that they hadn't coded anything on them. People aren't switching to Linux because of the liscences; they are doing it because Microsoft products don't work right. Microsoft's poor quality makes the whole industry look bad and holds back innovation. Why buy new software or a new computer when it doesn't provide any more real value and the support is still unaffordable?

re: Anatomy of a Software Bug

dave rogers — Sat, 29 May 2004 12:17:00 GMT

Rick,

Thanks for your weblog, and for what you do at BU.

I've never been a big fan of MS (just ask Scoble), but you don't deserve the negative comments being left in your weblog.

The point about human beings not being fully debugged is amply demonstrated here.

I hope you keep writing stories like this, and _some_ of the comments have been interesting and useful.

Betalogue

TrackBack — Mon, 31 May 2004 17:35:00 GMT

Betalogue

re: Anatomy of a Software Bug

Julie Krauss — Tue, 01 Jun 2004 23:03:00 GMT

Rick,

Amen! to all Dave Rogers' comments.

Those of us who have been professionals know how hard it can be to figure out the problem. There's even a novel about this exact issue: "The Bug," by Ellen Ullman.

Once again, Rick, thanks for the story. It's fascinating.

re: Anatomy of a Software Bug

Michael — Tue, 22 Jun 2004 17:05:00 GMT

A possible lead:

For a while I was running into the symptoms described very frequently in Word v.X, especially while translating documents with complex formatting (tables, styles, graphics, etc.). I use a translation assistance tool written in VBA called Wordfast (see wordfast.net), which among other things is able to automatically set the language property of translated segments to the desired target language. (Of course, you still have to do the actual translating yourself.)

While working on one job, I started running into the "open files" bug so frequently that I couldn't work properly. I used a tool called Sloth (sorry, I don't have an URL handy) that identifies the actual names and paths of open files for each active application. I didn't take notes at the time, so I no longer have the actual filenames, but I found a very large number of temporary files that were apparently related to spelling and grammar checking in the target language. When I temporarily removed the proofing tools for that language from their standard location, I stopped encountering the "open files" bug every few minutes and was able to continue work. This was several months ago and I don't remember exactly what I did, but I think I probably also turned off the Wordfast feature that sets the language property of target-language segments.

In Search of a Bug

bynkii.com's Mac Matters — Thu, 24 Jun 2004 20:53:00 GMT

Rick Schaut, of the Microsoft Mac BU has written an excellent article on how hard it can be to track down a bug. However, lest one thinks that only big applications like Word can be that hard to troubleshoot, let...

Scripting Word

Buggin' My Life Away — Fri, 25 Jun 2004 10:24:00 GMT

Scripting Word

Buggin' My Life Away — Fri, 25 Jun 2004 10:27:00 GMT

re: Anatomy of a Software Bug

Maireth — Fri, 16 Jul 2004 20:40:00 GMT

http://word.mvps.org/FAQs/WordMac/DiskFullError.htm

I found this helpful. It is a tweak that lets you clear out all the temporary files opened by word so that you can continue working without microsofts "handy" fix of telling you to close every 20 saves. Really, who counts?

Rick, thanks for posting. It was facinating to see this problem so fully disected.

re: Anatomy of a Software Bug

Norman Diamond — Wed, 28 Jul 2004 08:02:00 GMT

5/20/2004 10:28 AM Eric Hildum

> Summary of problem: receive a document from
> the US (made using US Word), cut and paste
> into Japanese document (using Japanese
> Word). Upon autosave or save, Japanese
> document is destroyed in memory and on disk.

Odds are that it didn't matter if one of the source documents had been made using US Word. Microsoft occasionally tested US Word (including but not limited to the case described in this blog entry). Odds are that the bug is either wholly within Japanese Word, or within the combination of Japanese Word and Japanese Windows.

> The delayed copying of the text would
> explain the behavior perfectly. Apparently,
> there was a bug in the text copy code
> executed when documents were saved.

The bug could be anything related to the way Word stores its documents, not necessarily related to copying and pasting. Though it is fortunate that the copy on disk wouldn't get corrupted until you actually did a save.

> By the way I did try to report the bug via
> our $500,000+/year global support contract
> with Microsoft, and was told directly by our
> Microsoft support representative, and I
> quote, "I wouldn't know how to file a bug
> report for that."

Surely your support contact only understood the US. Microsoft's idea of globalization is still pretty much US-centric. If you had a support contract with Microsoft Japan then you would be able to submit a report.

But even if you could get the report submitted, odds are that it would still never get solved. There are quite a lot of things you can see in Japanese versions of Office, and even just Windows without Office, that make it pretty clear that no testing was ever done. Things happen in the Start menu on the first reboot after installation, that could not be missed by anyone except Microsoft. Well, one of the bugs introduced by Windows NT4 SP4 was half-fixed in SP5, but has never been fully fixed in Japanese versions of Windows. In the US it was fixed in Windows 2000 during beta testing, but you expect a fix in US Windows' handling of Japanese to be copied back in to fix Japanese Windows' handling of Japanese, ha, no way.

re: Anatomy of a Software Bug

John J. Rynne — Tue, 03 Aug 2004 11:36:00 GMT

Rick, thanks for the interesting article. So that's what caused me and my company to lose so much work :-(
We ran into this on upgrading to Word 98. Called Microsoft support and got little relief. It would have been very helpful if they had said "Yes, is is a known bug - please do not adjust your set". But the didn't, so I reinstalled the OS and Office, on all machines - and still couldn't fix it.
In fact, a "fix" came out, but we continued to have the problem on and off for a long time.
We resorted to quitting Word every hour or so. Certainly, the problem could be attributed to "saving too often".

Anatomy of a Software Bug

Lee Packham's Corner — Fri, 27 Aug 2004 20:23:00 GMT

Ensight - Jeremy C. Wright » Anatomy of a Microsoft Bug

TrackBack — Fri, 27 Aug 2004 21:36:00 GMT

Ensight - Jeremy C. Wright » Anatomy of a Microsoft Bug

Joakim Andersson's blog » A bug is not always that easy to fix

TrackBack — Sat, 28 Aug 2004 00:11:00 GMT

Joakim Andersson's blog » A bug is not always that easy to fix

skrud.net

TrackBack — Sat, 28 Aug 2004 19:08:00 GMT

skrud.net

Anatomy of a Software Bug

Shaghaghi.net — Sun, 29 Aug 2004 09:25:00 GMT

Anatomy of a Software Bug...

King of the World

TheophileEscargot from Hulver's site — Sun, 29 Aug 2004 13:12:00 GMT

Me. What I'm Not Watching. What I'm Downloading. Cups. What I'm Listening To. What I'm Reading: "Ancient Light" (with SPOILERS and ENDING). Web. <br>
Contains great content EXCLUSIVE to loyal weekend readers!<br>
Plus a super-multipoll! <br>
Me Phew. Definitely need a three day weekend right now: feeling very abraded by the...

Anatomy of a Software Bug -MS Word

Chris Online — Mon, 30 Aug 2004 03:19:00 GMT

Anatomy of a Software Bug

Lee Packham's Corner — Thu, 02 Sep 2004 13:54:00 GMT

Anatomy of a Software Bug

WebMonster blog — Wed, 03 Nov 2004 21:56:00 GMT

diego sevilla's weblog » The Anatomy of a Software Bug

TrackBack — Thu, 04 Nov 2004 02:16:00 GMT

diego sevilla's weblog » The Anatomy of a Software Bug

Bug Links » Undo in Word 6

TrackBack — Fri, 05 Nov 2004 18:59:00 GMT

Bug Links » Undo in Word 6

You Don't Need Word

Buggin' My Life Away — Thu, 23 Dec 2004 19:30:00 GMT

re: The importance of error code backwards compatibility

The Old New Thing — Tue, 18 Jan 2005 21:14:00 GMT

CyraX’s lair » MS Word ‘disk-full’ error

CyraX’s lair » MS Word ‘disk-full’ error — Fri, 21 Apr 2006 07:37:16 GMT

PingBack from http://cyrax.wordpress.com/2006/04/21/ms-word-disk-full-error/

Opportunity Cost

Buggin' My Life Away — Fri, 23 Jun 2006 06:43:48 GMT

Back when I started blogging, I had a go-around with Pierre Igot. I'm not going to rehash it, but I...

Debugando cebolas

How things (should) work — Wed, 26 Jul 2006 02:27:04 GMT

O post é meio antigo, mas eu só li hoje e vale a leitura: Anatomy of a Software Bug
Ele conta como um...

npat's blog - the anatomy of a bug

npat's blog - the anatomy of a bug — Thu, 07 Sep 2006 02:36:25 GMT

PingBack from http://www.livejournal.com/users/npat/32177.html

the anatomy of a bug by npat () | LjSEEK.COM

the anatomy of a bug by npat () | LjSEEK.COM — Thu, 07 Sep 2006 02:36:26 GMT

PingBack from http://www.ljseek.com/the-anatomy-of-a-bug_13142679.html

Portals

Inherent Quality by Ron Richard — Tue, 03 Apr 2007 04:13:10 GMT

Field of dreams… The software and IT industry is a field of dreams. More than ever all can come to the field to offer ideas and contribute to its evolution. One means of doing so is through portals. A ...

Love and light - VIIP, beam it into your step

Love and light - VIIP, beam it into your step — Wed, 12 Sep 2007 17:47:08 GMT

PingBack from http://itknowledgeexchange.techtarget.com/viip/love-and-light/

Software Information » Buggin’ My Life Away : Anatomy of a Software Bug

Software Information » Buggin’ My Life Away : Anatomy of a Software Bug — Mon, 21 Jan 2008 02:33:59 GMT

PingBack from http://softwareinformation.247blogging.info/buggin-my-life-away-anatomy-of-a-software-bug/

Anatomy of a Software Bug

Anatomy of a Software Bug — Thu, 31 Jan 2008 05:18:59 GMT

PingBack from http://www.codenexus.com/BlogEngine/post/Anatomy-of-a-Software-Bug.aspx

College Fun Facts » Buggin’ My Life Away : Anatomy of a Software Bug

College Fun Facts » Buggin’ My Life Away : Anatomy of a Software Bug — Mon, 31 Mar 2008 23:36:12 GMT

PingBack from http://collegefunfactsblog.info/buggin-my-life-away-anatomy-of-a-software-bug/

Famous Peoples Birthdays » Buggin’ My Life Away : Anatomy of a Software Bug

Mon, 28 Apr 2008 16:50:07 GMT

PingBack from http://famouspeoplesbirthdayblog.info/buggin-my-life-away-anatomy-of-a-software-bug/

A Software Tester is...

Eric Hu's Weblog — Wed, 11 Jun 2008 10:30:14 GMT

我是個 Software Tester , 但是我突然發現, 我的 BLOG 裏的 "Test" 這個類別裏的 Post 居然沒有很多, 所以我想我應該多談談 Software Testing. 最近看了一些其它高手的部落格,

Anatomy of a software bug

IWebThereforeIAm — Sat, 14 Jun 2008 16:59:26 GMT

[Anatomy of a software bug] A Microsoft developer explains how a tricky bug in Word's undo stack behavior was tracked down....

Work from home moms.

Top work at home moms. — Fri, 25 Jul 2008 19:34:24 GMT

Work from home moms. Wahm com the online magazine for work at home moms. Moms work from home. Moms work at home.

Schwieb · How to report a bug

Schwieb · How to report a bug — Sun, 07 Sep 2008 21:14:37 GMT

PingBack from http://www.schwieb.com/blog/2008/09/07/how-to-report-a-bug/

the boy in the bubble » Blog Archive » Vom Bug zum Feature

the boy in the bubble » Blog Archive » Vom Bug zum Feature — Sat, 11 Oct 2008 09:52:42 GMT

PingBack from http://3.blogs.23.nu/bubbleboy/2005/04/antville-7349/

Buspar.

Buspar. — Fri, 07 Nov 2008 09:24:44 GMT

Buspar online med. Buspar vs zanax. Buspar.

Word 2004 BUG: Disk full when it is not (OsX 10.4.4) | keyongtech

Word 2004 BUG: Disk full when it is not (OsX 10.4.4) | keyongtech — Thu, 22 Jan 2009 07:52:53 GMT

PingBack from http://www.keyongtech.com/1337528-word-2004-bug-disk-full

Mati Lampu

Mati Lampu — Sun, 01 Feb 2009 13:39:08 GMT

PingBack from http://matilampu.wordpress.com/2009/02/01/14/

Buggin My Life Away Anatomy of a Software Bug | Paid Surveys

Buggin My Life Away Anatomy of a Software Bug | Paid Surveys — Fri, 29 May 2009 20:03:25 GMT

PingBack from http://paidsurveyshub.info/story.php?title=buggin-my-life-away-anatomy-of-a-software-bug

Buggin My Life Away Anatomy of a Software Bug | Uniform Stores

Buggin My Life Away Anatomy of a Software Bug | Uniform Stores — Mon, 01 Jun 2009 16:56:24 GMT

PingBack from http://uniformstores.info/story.php?id=14369

Buggin My Life Away Anatomy of a Software Bug | Wood TV Stand

Buggin My Life Away Anatomy of a Software Bug | Wood TV Stand — Mon, 01 Jun 2009 21:14:53 GMT

PingBack from http://woodtvstand.info/story.php?id=8751

Buggin My Life Away Anatomy of a Software Bug | Insomnia Cure

Buggin My Life Away Anatomy of a Software Bug | Insomnia Cure — Tue, 09 Jun 2009 00:51:30 GMT

PingBack from http://insomniacuresite.info/story.php?id=8252

Buggin My Life Away Anatomy of a Software Bug | Quick Diets

Buggin My Life Away Anatomy of a Software Bug | Quick Diets — Sat, 13 Jun 2009 16:40:52 GMT

PingBack from http://quickdietsite.info/story.php?id=12068

Buggin My Life Away Anatomy of a Software Bug | garden statues

Buggin My Life Away Anatomy of a Software Bug | garden statues — Sun, 14 Jun 2009 14:51:36 GMT

PingBack from http://gardenstatuesgalore.info/story.php?id=1609

Buggin My Life Away Anatomy of a Software Bug | unemployment office

Buggin My Life Away Anatomy of a Software Bug | unemployment office — Tue, 16 Jun 2009 10:58:26 GMT

PingBack from http://unemploymentofficeresource.info/story.php?id=8203

Buggin My Life Away Anatomy of a Software Bug | fix my credit

Buggin My Life Away Anatomy of a Software Bug | fix my credit — Wed, 17 Jun 2009 04:56:28 GMT

PingBack from http://fixmycrediteasily.info/story.php?id=177

Buggin My Life Away Anatomy of a Software Bug | pool toys

Buggin My Life Away Anatomy of a Software Bug | pool toys — Thu, 18 Jun 2009 12:02:54 GMT

PingBack from http://pooltoysite.info/story.php?id=9483

Buggin My Life Away Anatomy of a Software Bug | debt settlement program

Buggin My Life Away Anatomy of a Software Bug | debt settlement program — Fri, 19 Jun 2009 16:39:22 GMT

PingBack from http://edebtsettlementprogram.info/story.php?id=22802

Buggin My Life Away Anatomy of a Software Bug | debt consolidator

Buggin My Life Away Anatomy of a Software Bug | debt consolidator — Fri, 19 Jun 2009 18:37:22 GMT

PingBack from http://mydebtconsolidator.info/story.php?id=7327

Buggin My Life Away Anatomy of a Software Bug | debt solutions

Buggin My Life Away Anatomy of a Software Bug | debt solutions — Fri, 19 Jun 2009 20:31:18 GMT

PingBack from http://debtsolutionsnow.info/story.php?id=3621