Helping people with computers... one answer at a time.

If you find what appears to be a bug in Windows, or any product for that matter, reporting it can be surprisingly difficult. I'll look at why.

In Windows 7 Ultimate x64, open up Notepad. Turn Word Wrap off, and then maximize the Notepad Window. Type a long sentence that runs off the screen by a good amount. Then try to select the text from the right. That is, try to highlight that line from the right. Notepad has a glitch, and will not scroll left for you. If the Notepad window is not maximized, or if you select it from the left instead, it will scroll across for you as you try to select the line. However, when maximized and selecting from the right, it does not.

This is a Windows problem, as I duplicated it on another machine that is running another copy of W7 Ultimate x64. I tried using Microsoft Connect, but they won't take any Notepad or Windows bugs. My only option is to pay to call them and submit this as a support request or do it over the internet - for a charge. I feel it's unfair for me to pay to tell Microsoft about their product problems. Any solutions?

At least one.

I'll describe that as well as the "Microsoft Connect" you refer to.

And then I'll tell you why I wouldn't bother.

A Bug is a Bug Except When It's Not

I'll probably annoy a few people with this, but it's important.

The vast majority of what the general public would want to report as bugs aren't bugs at all. More often than not the software is acting exactly as designed. The person experiencing what they consider to be a bug is typically not using the product properly, or doesn't understand how the software is intended to behave.

In other words it's what I sometimes jokingly refer to as "operator malfunction". The software's working correctly, the user is not.

I know, I've been there. On both sides. (I've had my own "malfunctions" - many, in fact.)

I'm not saying that's the case with the scenario you describe. Not at all.

I'm also not saying that people are incapable of making valid bug reports - many are.

But I have to point it out to show you what the product teams have to deal with on a regular basis, and what you're up against.

So, assuming you've found a legitimate problem with a Microsoft product, what do you do?

Microsoft Connect

Microsoft Connect is a portal through which you can find out which Microsoft products are currently accepting bug reports, and what the requirements are to submit them.

If the product you're experiencing difficulty with is listed, then by all means this is the way to go. These are products whose teams are asking for exactly the kind of feedback you have.

The catch? Well, not all products are always present - the product must presumably be in that stage of development that the team can actually do something about the bugs. That typically means that they're working on the next release.

The other catch? Depending on the product, not just anyone can submit a bug report. Some are open to the public, some require registration, and some are open only to individuals who have been accepted into some sort of test program related to the product.

But as I said, if you have this option available to you, then use it. They're asking for it.

Microsoft Support

There is a toll free number - at least in the United States.

You'll find it here, along with this statement:

Report a Microsoft Product Bug

If you think you have found a bug in a Microsoft product, contact our Microsoft Product Support Services department. (800) XXX-XXXX

At this writing, that number takes you to a phone tree that will presumably get you somewhere where you can make your report. (I removed the number from the quote above in case it changes. It's on this page.)

After that, I've no idea what happens.

But I have a suspicion.

Why I Wouldn't Bother

Remember that I started with the statement that what most people first call bugs aren't bugs at all. My experience, both at Microsoft and here at Ask Leo bears that out to be generally true. People are very quick to blame the software when something goes wrong - only to find out later that it was their own mistake or misunderstanding that actually caused the issue.

Important: I'm not saying that sometimes people aren't right. They are. I'm also not saying that difficult to understand software isn't a "bug" in it's own right. It is. What I am saying is that the vast majority of those reports are simply user error.

So faced with a potential influx of "bug reports" from the general public - many if not most of which are not going to be bugs at all - what's a company to do?

Accept them, but prioritize them low. Work on them as there is time. If there is time.

Prioritize instead those bug reports from trusted sources that are more likely to submit valid reports. Microsoft internal, beta programs, partner programs like TechNet or MSDN subscribers. Potentially prioritize and accept those general bugs only during fixed periods so as to be able to focus on them and fix as many as possible.

Because not all will be fixed.

That's the other harsh reality.

Not All Bugs are Created Equal

As I said, it sounds like you may have a valid bug on your hands there. I could be wrong, there could be something else at play, but all in all it seems like the real deal. At least something worth looking into.

Or is it?

It's fairly obscure. It's hard to get to, the average user may never experience it, it's not a security issue, no data loss occurs as a result of it, and no programs crash. Sounds like something bad might be happening, but the impact of that bug is pretty small.

So even if reported, it may never be fixed.

Problems that are more severe - particularly security issues and bugs that cause actual data loss - are typically prioritized very highly on the "to do" list when working on software, while issues such as this which boil down to cosmetic or behavioral, end up very low on that list.

When the public, press and current users are clamoring for the next release of whatever product this problem might be in, the items on the bottom of the list rarely make it in.

There are almost always more important fish to fry.

(Often when these kinds of issues do get fixed it's because other work was being done "in the area" and the developer or others elected to resolve the issue as a matter of convenience.)

Article C4385 - August 1, 2010 « »

Share this article with your friends:

Share this article on Facebook Tweet this article Email a link to this article
Leo Leo A. Notenboom has been playing with computers since he was required to take a programming class in 1976. An 18 year career as a programmer at Microsoft soon followed. After "retiring" in 2001, Leo started Ask Leo! in 2003 as a place for answers to common computer and technical questions. More about Leo.

Not what you needed?

Recent Comments
15 Comments
Tony
August 4, 2010 11:28 AM

Okay, I can't tell you how to report a bug,but I can tell you there is more than one way to scroll. If you scroll left by holding down the mouse button and moving your hand to the left, you will only be able to select what is actually seen on the screen. Instead,try using the arrow keys on your keyboard. Click to the right of the sentence, hold down the Shift key, and press and hold the left arrow key until the whole sentence is selected or highlighted all the way to the left including what was not previously showing on the screen.

Maybe there is still a "bug" if one method works and not the other, but this solves what Leo calls "operator malfunction". The operator can function again now without having to report the "bug".

James T.
August 5, 2010 8:33 AM

Yes, Glenn P. I posted this question. And yes, it's the end of the world, and I'm reporting bugs in Notepad. You see, it's not the bug that is the problem, I was using Notepad as an IDE for Javascript while VS 2010 was downloading, and the main problem I have is how to report this bug. I mean clearly, it was just looked over when the developers made the new notepad, and I was wondering how it would be possible to let Microsoft know of this. I'll call that number, and see if one day, I can get my solution to this. Yes, people are trying to find cures for cancer, but I'm just finding a cure for a bug in Notepad.

John L Brown
August 5, 2010 7:09 PM

Sometimes "operator error" in certain programs are not so much the result of operator error, but rather the result of confusing, overly complicated, or "incomplete" instructions, or information contained in the help topic, user guide, or instructions, generally. Developers often assume, especially in rather sophisticated programs, that the user has sufficient grounding to understand their instructions, therefore 'skip' certain steps, or explanations judged as rudimentary. In many cases this is understandable. Yet I have encountered numerous cases where developers provided instructions that are, at least in part, seemingly drafted to appeal to fully trained operators within a particular program type. In such scenarios, the 'bug' is actually the failure to provide straight forward instructions. This shortcoming warrants the same need as reporting real bugs. Moreover, if an operator neglects to even read the user information, generally, and specifically if a so-called bug arises, they are not in a position to complain. Often programs have known bug, duly noted within the user information. Further, there are usually associated forums available for review, that may well address relevant issues.

McCabe
May 1, 2011 4:07 AM

Frankly, as someone who's spent quite a long time analyzing, sorting, and passing on bug reports, the idea that an organization as big as Microsoft can't afford to take the time to analyze public bug reports is ludicrous. By limiting what reports come in, yes, you have fewer reports to deal with, but you also miss out on large pain points because your sample is smaller by a large factor than your actual userbase. This makes all reports you receive 1. biased towards specific hardware 2. biased toward specific use cases. Beta users and developers will always use your software differently than average users. 3. biased against usability. People who search for bugs are usually too close to the product spot these, or don't consider them serious issues despite how much they can affect a new user's experience. 4. of a different scope than the actual problem. You can only know how much a bug affects the general public by opening bug reports (keeping tabs on support requests can be a quick and dirty substitute, but you will miss a good deal of useful information).

As always, it's a trade off. By not allowing general users to submit bug reports, you tend to get more repros. But you also tend to produce, on average, buggier and less usable products, as well as one that's slow to respond to user frustrations.

Here's an example of how the Microsoft way will skew your product. It's common knowledge that the new Windows search introduced in Vista is unreliable, and will sometimes fail to find files that the user knows exist. Did someone report this in a Windows beta? Almost certainly. But these are technical-minded users reporting to technical-minded people. They know how to change their indexer settings, how to modify the registry, how to find hidden files, etc. There's little chance Microsoft realized how much an impact an unreliable search would have on the user experience, which is one of the reasons why Vista was such a pain point for people (search has been improved since then, but is still not as reliable as it was under XP and before). Being able to find files on your filesystem is a core component of an Operating System, yet users have no way of telling Microsoft "I can't reproduce this, but you need to keep looking at it!"

Personally, I highly recommend any company interested in improving their product for general users consider setting up a system to handle issues from the public. It's more work--you *will* get a high amount of user errors, as mentioned above--but if quality is an important benchmark for you, the benefits outweight the costs.

McCabe
May 1, 2011 4:15 AM

Ack, that should've been "As always, it's a trade off. By not allowing general users to submit bug reports, you tend to get more repros. But you also tend to produce, on average, buggier and less usable products, as well as ones that're slow to respond to user frustrations."

My mind had already moved from the plural to the singular before my fingers caught up :)

Comments on this entry are closed.

If you have a question, start by using the search box up at the top of the page - there's a very good chance that your question has already been answered on Ask Leo!.

If you don't find your answer, head out to http://askleo.com/ask to ask your question.