Live data from Hacker News

“Artery chokes after 70 copies of Visual Studio”

connect.microsoft.com

31–40 of 99 posts

Re: “Artery chokes after 70 copies of Visual Studio”

#31

Instead, I had to hunt down the person who wrote bugs with only titles and severity level critical....

"unable to reproduce / not enough information" -> close.

If users want you to fix a bug, they should assume you're an idiot and can't extrapolate what their problems is from the title alone.

Re: “Artery chokes after 70 copies of Visual Studio”

#32
post #28

Not that this is a major bug, but it makes me wonder why a bug report of this detailed nature (basically doing the debugging for Microsoft engineers) shouldn't be eligible for a bounty, just as exposed security flaws are. For this bug, it would be a very small or non-existent bounty since this use case affects almost no one, but what if someone found a major bug that was not a security issue, and worked out the cause…

Bounties exist for security bugs to make it more profitable to report the bug than it is to exploit it, or to sell knowledge of it to those who would. A buy about opening 70 copies of Visual Studio is unlikely to be very profitable to exploit.

Re: “Artery chokes after 70 copies of Visual Studio”

#33
post #4
post #2

What I want to know is this, what hellish workflow led to the discovery of this bug?

My guess would be that it's an automated build / deploy system that required some addon installed to run, so they had to run `devenv /build` instead of using msbuild. Then they saw this behavior on one of their build machines when something wasn't installed correctly and the process just terminated, after 71 retries... Source: I was on the visual studio environment team a decade ago, and Rube Goldberg himself could n…

One of my personal corollaries: all build systems suck

Some suck more, some less

And most of the time it's overcomplicated.

Re: “Artery chokes after 70 copies of Visual Studio”

#34
post #32
post #28

Not that this is a major bug, but it makes me wonder why a bug report of this detailed nature (basically doing the debugging for Microsoft engineers) shouldn't be eligible for a bounty, just as exposed security flaws are. For this bug, it would be a very small or non-existent bounty since this use case affects almost no one, but what if someone found a major bug that was not a security issue, and worked out the cause…

Bounties exist for security bugs to make it more profitable to report the bug than it is to exploit it, or to sell knowledge of it to those who would. A buy about opening 70 copies of Visual Studio is unlikely to be very profitable to exploit.

[deleted]

Re: “Artery chokes after 70 copies of Visual Studio”

#35
post #32
post #28

Not that this is a major bug, but it makes me wonder why a bug report of this detailed nature (basically doing the debugging for Microsoft engineers) shouldn't be eligible for a bounty, just as exposed security flaws are. For this bug, it would be a very small or non-existent bounty since this use case affects almost no one, but what if someone found a major bug that was not a security issue, and worked out the cause…

Bounties exist for security bugs to make it more profitable to report the bug than it is to exploit it, or to sell knowledge of it to those who would. A buy about opening 70 copies of Visual Studio is unlikely to be very profitable to exploit.

Repectfully, you are incorrect that bounties exist to make it more profitable to disclose than to sell.

Corporate bug bounties will never be able to compete with the budgets of nation states.

They are basically a way of paying respect for a moral approach to a discovery that takes great skill.

Re: “Artery chokes after 70 copies of Visual Studio”

#36
post #16
post #11

Earlier quoted context omitted.

Agreed but I was confused by the MS response of "Thank you for submitting feedback on Visual Studio and .NET Framework." It seems like the bug is in VS and not .NET. Are they that interweaved these days?

in 1998 I was working with VS and had a bug with OCX and was told that the bug was due to VS not working with the current IE version as well in places and was fixed in the new release of VS due out. So I'd say very interweaved if history has its design legacy mantra.

IIRC Internet Explorer used to overwrite the shell DLLs which contain a lot of random helpers and stuff that is not strictly shell related but tempting to make your application depend on. I remember this being a frequent source of "app not working, probably works on the developer's machine" type issues, especially in the time period where this was changing a lot.

Re: “Artery chokes after 70 copies of Visual Studio”

#37
post #19

Earlier quoted context omitted.

Yes, but do you shut them down ungracefully? Do you expect to read interesting bug reports on HN?

I've killed so many devenv.exe in my career that there must be some kind of warrant on my name in Redmond. I agree that vs.net is not really pertinent to the core 'hacker' audience here, but this bug report is actually relevant to me, and I didn't get it from my MS-oriented feeds. I should read HN's FAQ, but aren't articles making it to the front page by being upvoted from new?

Ditto. And I've ony used VS for about 2 years now

Re: “Artery chokes after 70 copies of Visual Studio”

#39
post #19

Earlier quoted context omitted.

Yes, but do you shut them down ungracefully? Do you expect to read interesting bug reports on HN?

I do, they are entertaining.

Yes, well... try this one then:

http://support.microsoft.com/kb/168702

Entitled "XL97: Data Not Returned from Query Using ORACLE Data Source", one of the solutions reads:

Method 2: Move Your Mouse Pointer

If you move your mouse pointer continuously while the data is being returned to Microsoft Excel, the query may not fail. Do not stop moving the mouse until all the data has been returned to Microsoft Excel.

I'm sure some large bank has employed a data operator to do this at some point. It's a job I guess.

Re: “Artery chokes after 70 copies of Visual Studio”

#40
post #9

Now that's how bug reports should be written!

I don't think you can always expect your users to do the reduction and the debugging for you, they pay you for a bug free product. In this case it's a developer-centric product, so I guess the bug reports are more geeky, but customers are not here to serve the developers.

Agree, I should have made that clear in my comment. in fact I've found that a) the product devs should be able to find the cause much faster than you can, b) it's more effective for you to spend your time developing a repro script/code/etc, because unlike describing a bug, this is unambiguous and the devs can run it very quickly to verify tat the issue can be reproduced on their end.
Post reply on HN