Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,026 | Comments: 44,842

filter by tags archive

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

time to read 1 min | 174 words

I want to point you to this bug:


Do you see the Won’t Fix there?


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


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.


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


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

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

Alois Kraus

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


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.


Alois Kraus

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.



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


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

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

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

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


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.

Comment preview

Comments have been closed on this topic.


No future posts left, oh my!


  1. Technical observations from my wife (3):
    13 Nov 2015 - Production issues
  2. Production postmortem (13):
    13 Nov 2015 - The case of the “it is slow on that machine (only)”
  3. Speaking (5):
    09 Nov 2015 - Community talk in Kiev, Ukraine–What does it take to be a good developer
  4. Find the bug (5):
    11 Sep 2015 - The concurrent memory buster
  5. Buffer allocation strategies (3):
    09 Sep 2015 - Bad usage patterns
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats