Does anyone actually have a story of a Connect issue having even a satisfactory resolution? I know mine have never been and i know of a number of other examples. It just seems like a site set up to pour salt into the wounds of developers. Granted, there's probably no blog posts about happy resolutions, but still...

I think that's little unfair to connect.

That's not internal bug tracking system, so we don't know for a sure that this bug wouldn't be fixed (or maybe escalated to core CLR team)

And we can see that author show full commitment to closing this issue ("I didn't found how to close this ticket, so I left it open. It's not anymore an issue for me.")

And yes, I personally saw connect issues that was successfully resolved!

@Arne,

No - want to hear my "success story" read here: connect.microsoft.com/.../ViewFeedback.aspx

If you can (or want) do something with it, please contact me.

I've reported that & still have the repro for that issue.

executionenginge bugs can well be security holes...

MS (Dis)Connect seems to brush off way too many bugs and issues. My latest personal success story ist this one:

connect.microsoft.com/.../ViewFeedback.aspx

You get a handle leak in every .NET program if it runs from a network share location. The coolest thing that this was resolved as external issue. I am not sure how a handle leak can be external. Rational won´t change their MVFS driver.

Yours,

Alois Kraus

@Alois, a handle leak can be external if the handle isn't freed by the OS/native code layer called by .NET while the .NET code makes the call to free the handle. So i.o.w.: it can't do much about it.

That's the theory. As it's on connect, I have the feeling the MS employee simply didn't look, as they never do when handling issues posted on connect. It seems that they're interested in closing as much issues as possible to reach a threshold or something while at the same time forgetting that by not solving the issue, the customer / user still has the problem and potentially others will have it too.

I don't even bother reporting issues to Microsoft anymore, not even in betas (as 'beta' means that they only fix the really important ones anyway). It's of no use. If you're really lucky they fix it in 'the next version', like that's going to help much if the bug is in .NET and your customers run into it every day.

I reported a bug to Microsoft ( that had been lying around since 2005), and yet it chose not to fix it without any reason.

@Frans

It's the green culture...I'm living this everyday :(

Talk about bad translations, the "Won't Fix" translates to "Cannot fix" in danish.

@Dennis: That's always better than 'Don't want to fix that' what seems the case in the majority of the issues.

For example: I've submitted a bug that I can't pin the Microsoft Document Explorer (MSDN) to the taskbar. Their solution: VS2010 has another help systems so we won't fix that.. (closed).

But I'm very sure that statistics of Connect are being used in marketing to say '80% of the submitted issues are closed within 7 days' or something like that.

It is also possible to Microsoft changed the priority from 'urgent' to 'normal' because this currently isn't a real issue anymore. I guess that the increase the priority if someone else submits a similar issue. They might not change it for 3.5, but maybe that fix it in the current branch (net 4.0).

I've logged a few issues with Connect in the past and definitely feel like my tiem was wasted, amazed that in this case with such a serious error they didn't do more though.

This is funny (in the bottom of the issue connect.microsoft.com/.../ViewFeedback.aspx):

Expected Results: World peace.

:D

The repro in the bug in question did not actually function. It was a huge bag of C# code that wouldn't run because we didn't have an SQL database correctly setup and populated like his program expected, so there was nothing we could do with his repro program.

Moreover there are many things that can cause an ExecutionEngineException, many of which are not due to a problem within CLR (despite what the documentation pasted above says). Scribbling over the managed heap is one example out of many (bad PInvokes, improper use of the unsafe keyword, and so on).

Were there anything I could have done to investigate the bug, I would have. However, this was all wrapped up in the support case he posted there. Had there been an issue with CLR, the support folks would have contacted our team with the issue as well.

Just because the entire issue wasn't posted in the comments section doesn't mean we didn't look at the bug, or that we didn't take it seriously, or that all of the context for what went on is in the connect issue.