Ayende @ Rahien

Refunds available at head office

Hello!!! Is this ON?! [Connect Bugs sucks, again]

I want to point you to this bug:

image

Do you see the Won’t Fix there?

image

Let us take a look at what ExecutionEngineException is all about, okay?

image

Now, the real problem here is that along with this issue there is a failing sample, so it is not a case of not being able to reproduce the error. Granted, the customer has managed to find a workaround for their problem, but the bug in the framework is still there, and was not fixed. I would assume that CLR crashing bugs that “should never occur” would be given some priority, even if the customer managed to find a workaround.

Comments

Arne Claassen
09/12/2009 05:06 PM by
Arne Claassen

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...

KAE
09/12/2009 05:18 PM by
KAE

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!

Valeriu Caraulean
09/12/2009 06:00 PM by
Valeriu Caraulean

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

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

tobi
09/12/2009 11:33 PM by
tobi

executionenginge bugs can well be security holes...

Alois Kraus
09/13/2009 06:15 AM by
Alois Kraus

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

Frans Bouma
09/13/2009 09:09 AM by
Frans Bouma

@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.

Set
09/13/2009 01:25 PM by
Set

@Frans

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

Dennis
09/14/2009 02:27 AM by
Dennis

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

Dave Mertens
09/14/2009 07:02 AM by
Dave Mertens

@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).

Colin Jack
09/14/2009 08:21 AM by
Colin Jack

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.

Lee Culver
09/30/2009 11:47 PM by
Lee Culver

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.

Ayende Rahien
10/01/2009 12:51 AM by
Ayende Rahien

Lee,

I run into this issue while trying to figure out another EEE issue ( I forwarded that to you as well, so you can see if this is similar or not, this one include a simple sample that repro EEE, wihtout any pinvoke, unsafe, etc ).

The problem in having a public bug tracking system is that it is used to look for bugs. When I see something that looks like a close match to what is wrong with my scenario, and I see it (as viewed from outside) as being basically ignored, it is infuriating. Add that to the usual issues with Connect, and you get this post.

If there are external communications going on, they should be mentioned in Connect, including something that says where the problem is.

Comments have been closed on this topic.