Microsoft Garage releases Mouse Without Borders

>Whatever. I've lost interest in participating in this thread.

That's unfortunate.

>If I'm so incapable of reproducing issues and "demons in a machine" is so laughable, why exactly does the "Unhandled ExecutionEngineException" exist and why was it more than trivial for me to reproduce?

Well, an ExecutionEngineException is simply the CLR encountering some unexpected problem. The CLR is a piece of software like any other, it is simply a COM component, written in C++. Like any other program it too can have bugs and situations that it fails to handle gracefully. They are not untraceable or uncatchable in any way, I have caught and debugged a number of them. Of course without the pdbs/source that is much harder for an external person to do. In my experience it is actually preceded by an SEH exception that the CLR itself will catch and translate into the rather generic ExecutionEngineException, so watching for first chance SEH exceptions is generally more fruitful.

>So now three MS people doubting me, mocking me, and suggesting #win32 as remotely comparable to open source style IRC rooms.

So when I point out that 'untraceable uncatchable exceptions' don't exist you see that as mocking you? Or was I the doubting one? I am simply a software engineer, like I assume you are. I was pointing out some things don't exist. If untraceable, uncatchable exceptions existed there would be a class of bugs that were logically impossible to find/fix.

As for 'the .NET runtime informing you that it was unaware of where the crash was occurring', the .NET runtime would never be aware of such a thing as a crash is a crash. It means the exception found no handler and the process was terminated. Figuring out why is what a debugger is for, not the runtime.

>I'd post it here, but I'd prefer it were not linked to my name as Googling the error message reveals my only post.

It is strange that you want to hide your identity so much.

>This is just sad, and ironic as all get out considering the fact that my original comment was that Microsoft and community don't play nice together. Don't you see that irony?

Not really, 'the community' doesn't consist of a single person. I am active on the MSDN forums in my area of expertise. I am also active on my team's blog. In the course of such activities I regularly encounter trolls, I am not saying you are one, just saying they exist. To 'play nice' with a troll is pointless. Some people have axes to grind and no matter what you say or do they will be upset, there is no point trying to help those people. Also, if people are rude from the get-go I tend to not bother helping them, since I generally am spending my own free time to try to help them out, and there are lots of other things I could be doing. Civility is kind of the minbar for what I expect of them.

As for 'open source' communities being more civil/friendly...well that is certainly not my experience across the board, but then again, people always have different experiences and tend to remember the worst/most frustrating of them and project that as 'the norm'.

My apologies as well, in re-reading my post some of it was douchey, sorry about that :) As for your specific points

>I don't know how "uncaught and untraceable" had an ambiguous meaning. Obviously I don't work at Microsoft and can't just fire up a debugger attached to the VS source to track down an issue. I find it bemusing that "you can't reproduce the issue or track it down", turns into, "well, it would be hard to debug without the source". (No joke.) From where I'm sitting, that tends toward "blame the bug on the user" bait.

No, what I meant is that you CAN catch the exception and probably get a stack trace, Microsoft, for reasons that are beyond me, generally has stripped symbols on their public PDB servers, so when customers send me stacks even with symbols resolved they say meaningless things like msenv.dll!SomeFunction + 0x392818 bytes, which is obviously silly. And THAT is the reason it is hard for external people to actually figure out the underlying issue or a good work-around. If the exception is coming from within VS code then you don't have much info on the stack. A lot of times it is coming from a third party dll (I group MS out of band releases here as they use the same extensibility APIs that third parties do for the most part), and having those symbols is also unlikely as lots of companies don't even have symbol servers, so resolving those stack frames can be a no-go as well. Some of this is unique to Microsoft, though I would have the same problem debugging Google or Apple code if I didn't have proper PDBs or source access, so I don't know if this is solely the fault of Microsoft, though their public symbols being stripped is stupid (don't get me started on how I can't even GET internal access to Office PDBs without a 'business need'...)

>As for the last two paragraphs, I'll merely hope that it wasn't a veiled attempt to call me a troll,

Nope, that is why I explicitly said 'not saying you are one', I was explaining my views on why the community can at times be dismissive or appear rude. They generally run into lots of people that come, demand answers, are generally rude all around and then leave without ever saying thanks...it is a thankless job to man support forums, and it can burn people out :)

I have had some (albeit more limited) experience with a couple of open source communities and never felt a much different vibe, I just assumed it was 'part of the customer service' kind of arena, you generally deal with the pissed off and perhaps pissy customers, which can be hard, and often times unless they have a simple question you can answer immediately they lose interest in the whole undertaking, accuse you of lying if you say you can't repro it, etc...

>I merely wish that the support forums were better, and that there were community lead resources for Microsoft products.

Me too, that is why I try to help out at the forums for the product I work on. Unfortunately I don't agree with all of Microsoft's support approaches, but no company is perfect, at least not one I have found. I think the lack of a two-way community has to do with Microsoft being a for-profit entity. People feel that if they have problems Microsoft better damn well fix it now, and they don't have interest in helping others out, that's Microsoft's job. There is some decent community on StackOverflow around MS technology, much better than MSDN Forums, but even that can be hit or miss and generally the best answers end up coming from Microsoft employees, most of whom are helping out in their free time as most of them are definitely NOT paid support people, so they can't really spend their work day answering questions, at least not too much of it if they want to make all their commitments happen.

>I hope this clarifies. I'm simply genuinely curious as to the fundamental nature of how the global community of .NET developers differs from that of python/go/c++/ruby/etc.

Yep, as I alluded to above my own personal feelings have to do with Microsoft's history (most of the people involved in the most egregious things are gone or at least 'reformed' enough I doubt they would be so 'bold' as they were back then), the fact it is a for profit company and the fact that it seems harder (for whatever reason) to get people in the community with a lot of knowledge (there are a lot of folks not at Microsoft that probably know part of my product better than I do) to 'give back'.

It is a hard problem, there are people that do nothing but work on community engagement, they closely monitor/gather data on this and try to do outreach, tweak things to be better, etc... but I don't think anyone has found the silver bullet yet.