Phillip Trelford's Array

POKE 36879,255

Reporting Bugs to Microsoft

Software is a product of humans, humans exhibit defects as do their software. Microsoft software is no different. You can report issues on the Microsoft Connect site or to Microsoft Support directly. My recommendation is that if possible you should do both.

Silverlight

One of the Microsoft frameworks I have been exercising heavily over the last few years is Silverlight. In the process, as with any framework, I have encountered bugs. Several have been minor or easily worked around so have not been reported. Others however have warranted reporting, so far only one out of five has been fixed.

COM Leak

The first major issue I discovered was a Silverlight 4 COM memory leak which I reported back in April 2011. I received this canned response a day later:

We are rerouting this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.

The Silverlight team has not followed-up on this issue. In the end I found a workaround for this. The issue still exists in Silverlight 5.

Disappearing windows

The next serious issue encountered was in the Silverlight 5 native window support. When a borderless window is maximized on a second monitor it disappears off screen. The issue received 17 votes and 12 people reported that they could reproduce the issue. Again no response from the Silverlight team and the issue still exists.

Performance degradation

After not receiving any human feedback from the Silverlight team via the Microsoft Connect site for over a year I reported the next issue directly to Microsoft Support, with mixed results. The issue relates to a serious performance degradation when opening multiple windows in Silverlight 5. It was reported over 10 weeks ago, and relatively quickly it was accepted as a bug in Silverlight by the three Microsoft support engineers that have been investigating it (the first a lucky intern). They did make contact every week or two to let me know that they were still looking at it. Unfortunately reporting the issue solely to the Microsoft Support team has delayed the issue being reported to the Silverlight team by over 10 weeks, as they put off doing this while they looked for workarounds. With hindsight I would have reported the issue on Microsoft Connect at the same time, which I have now done.

Visual Studio 2010 SP1 hangs

After applying SP1 to Visual Studio 2010 the IDE started hanging while debugging Silverlight applications. We encountered the first hang when expanding an F# discriminated union type in the debugger.(the issue however is not isolated to F#). In this case the F# team responded and diagnosed that the issue was a bug in the debugger introduced with SP1. A number of workarounds were offered and the issue has been fixed for Visual Studio 2012.

Context Menus & Child Windows

Not officially part of the Silverlight release the ContextMenu and ChildWindow controls are distributed with the Silverlight Toolkit. Both of these controls have not been updated to support the new Silverlight 5 Mutiple Window feature, so if you open a context menu or child window from a secondary window they will actually appear in the main window. As the Silverlight Toolkit is open source I was able to relatively easily workaround both of these issues, and package up the fixes in another open source project.

WPF

As mentioned at the start, a lot of my work recently has been with Silverlight so this is where I have been finding bugs. Silverlight was originally called WPF/E, and is a subset of WPF. WinRT in Windows 8 is itself derived from Silverlight 3. Some bugs are unique to Silverlight but many are inherited from WPF. for example windows with a black background flash white when first shown. On the pragmatic side, sometimes a workaround for a WPF originated issue can be applied to Silverlight and vice versa, the same may soon apply to WinRT. If you’re interested in hearing the point of view of a WPF developer check out six years of WPF.

Conclusions

Some teams at Microsoft do respond quickly to reported issues, for example I have always had a speedy response from the Visual F# team. Otherwise reporting a bug on a public forum means that not only do the product teams see the issue, so do the community, who may have already found a workaround. Reporting issues to Microsoft Support means you are guaranteed contact with support engineers at Microsoft, but this may also mean it takes longer to be seen by the product team as they look for a workaround, so I’d advise reporting issues on Microsoft Connect too. Hopefully Microsoft will continue to open source more of it’s projects in the future (F# is open source as is the Silverlight Toolkit) so that the community have the chance to fix issues as well.

Update: Microsoft no longer accepts WPF & Silverlight runtime issues, please use the respective forums instead:

Comments (5) -

  • Matthias

    8/9/2012 10:48:46 PM |

    I have made similar experience with google.
    I reported a memory issue in their youtube c# api and got an answer in hours and I reported a problem in their Sites python API and that took months.

  • Gary Wheeler

    8/13/2012 3:32:01 AM |

    Why do you even bother? Every time I've tried to report a bug to Microsoft, they've either ignored it (no response), closed it immediately (practice #1 on Connect), or deleted it immediately (practice #2 on Connect).

  • David

    8/13/2012 11:08:28 PM |

    When I reported a bug on a beta version of Office, they said "it wasn't a bug as the product had not yet been released".

  • SadFace

    8/15/2012 8:12:59 PM |

    Frown This makes me so sad... one would think Microsoft would care about improving their products

  • Doug Turnure

    8/16/2012 2:59:53 PM |

    Hi Phil,

    I am the Feedback and early adoption PM for Visual Studio. I took the role over 2 years ago, and found Connect to be an aged system with a lot of holes in it. It had been passed around a bit, and prior to my arrival was unmanned for 6 months. Not a pretty start, but in the interest of transparency, that's where it was when I started.

    We have a 14 day response window for bugs, meaning I watch every bug that comes in, and press teams to triage first, then respond with what the plans are (when possible).

    A lot of your bugs are with Silverlight, and last year that team moved over to Windows. I realize it's not a useful excuse for you when I say that they are no longer in Developer Division, and thus they do not follow the response window any longer. But the reality is, Windows does not respond to bugs like Visual Studio does. Windows has 500M+ customers, and there's no way they can handle that mass of conversation.

    Again, I'm telling you why the Silverlight bugs were largely unanswered, and I realize that the reason why is not that helpful to your bottom line - you filed a bug and you want a response. You may have noticed that we no longer accept Silverlight bugs in our Connect site. That is purely because this is the Visual Studio site, and they are no longer in our division. The same holds true for WPF.

    Back to the responses - after taking a year to just clean up the mess, I started running a monthly report. In it, I show which teams have stale bugs (14+ days waiting for a response) as well as how we are responding. Thus, for the first time, if a team closes a bunch of bugs as won't fix, it shows up very visibly to our leadership.

    I do run stats on responses, and we reduced our stale bugs by 95% over the last 24 months. The majority of the ones we are still chasing down are Silverlight, so you happen to have filed bugs in one of our problem response areas.

    Gary - if you ever file a bug and get a non-response, ping me directly dougturn - at - microsoft dot com and I'll find it and figure out what's going on with it. Every bug should get a response, even if we know we are not going to fix it.

    SadFace - I assure you we care deeply about improving our products, and I'm slowly and steadily righting the ship around Connect. We've also added UserVoice to the mix, as a better way to handle suggestions.

    Bear with us on this. I'm watching the numbers, and both responses and fix rates are rising. It's just taking time, as there are 21 teams involved in the process, and about 4000 humans.

    thanks,
    Doug Turnure
    Visual Studio PM - Feedback and Early Adoption

Pingbacks and trackbacks (1)+

Comments are closed