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: