Team [Shaky] Foundation
Fishy hang.
My Visual Studio 2005 hung completely, out of the blue. Did not respond to any mouse clicks or keyboard events, though it did redraw.
I tried firing up another VS2005 to debug it, but that hung too and then closed.
So I tried firing up a VS2003 and attaching the native debugger to the hung VS2005. And the debugger crashed.
I sent the crash data to Microsoft, and tried again; same results several times, with the crashed VS2003 restarting automatically each time.
Finally closed the VS2003 manually, started a new one and attached, successfully. By this time the VS2005 window was gone, but the process was still there. Got a minidump of the hung VS2005 if anybody wants it.
(Incidentally, one of the process modules jumped out at me with the name custsat.dll … that might stand for “customer satisfaction,” which, taken in context, is a wee bit amusing.)
Detached and killed the VS2005 process and started a new one, but nothing came of that.
Finally resorted to a reboot, but the shutdown was interrupted by a VS2005 window appearing, with a modal dialog with this message:
TF30331: Team Explorer could not connect to the Team Foundation server source
used during your last session. The server may be offline or the network is unavailable.
Contact your Team Foundation Server administrator to confirm that the server is available
on the network. Use the Connect to Team Foundation Server command on the Tools menu to
reconnect to your previous server.The server returned the following error: The operation has timed out
Figures that it was the Team Foundation server, because the same mess was going on on a co-worker’s machine at the same time.
But … the server catches a flu and the whole IDE hangs?
Closed the modal dialog and the studio window, rebooted, and started up VS2005 again.
It seems to be working now … but I don’t need this kind of aggravation. I have work to do, and I miss my VS.Net 2003 (!) and the trusty, robust, never-hanging Subversion we were using along with it.
I googled the error message and got nothing. So if this were Eclipse or NetBeans or IntelliJ (or, indeed, Subversion) hanging, I would go file a bug and attach the minidump to it and feel all warm and fuzzy about helping out. And I would cheerfully expect a new version fixing the problem. In less than two years’ time, even.
But it is a Microsoft product; I do not know of a public bug database, and I do not feel inclined to go telephone the uninvitingly-named “Professional Support Services” and stay on hold while all of their customer representatives are currently busy assisting other callers and will answer my call in the order in which it was received, and then try to convince one of them that I’m honestly not that big an idiot (a relatively small-framed one, in fact) and that there really is a problem. No thanks. So last-millennium.
That kind of prejudice — while indicating the image Microsoft still has, despite the best efforts of MSDN bloggers — begs to be proven wrong and unfair. I want it to be proven wrong and unfair. And sure enough: after a little spelunking, here is the place to submit feedback, without hanging around on the phone at all. I’ll go do that instead of whining like a crybaby.
All right, after signing in with my Passport login, and then signing up with name and email and age and all that (yet again — now, what was Passport for, again?), I spent about 20 minutes carefully describing what happened, providing exact product and add-in versions and the like, and then submitted. Kabloom:
And yes, that does repeat when I back up and retry the bug submission several times.
Ah well. I did give it a try. And I’m glad they have it. Just look forward to trying it out when it’s feeling better.
EOR
September 26th, 2006 at 6:45 pm
My guess is that the apparent bug in the bug submission system is actually a feature. This feature ensures that Microsoft will not be flooded with error reports and that we won’t waste time trying to report the bugs in the future. I’m not just being sarcastic here. I’m basing my guess on my experience with the MSDN pages. I was browsing through a language reference page a few months ago when I noticed that the example code I was reading actually had a bug in it and wouldn’t work. When I tried to report this error, I found a couple of bugs in the bug reporting system before being encountered with an error message similar to the one you got. This new Connect thing might be supposed to work, but my bet is that it’s just a new fancy way to present the “don’t ever try to report a bug again” message.
September 26th, 2006 at 10:46 pm
You are being sarcastic — but still, that guess is not too far off: I got a response today:
Feedback permissions! Ergo, by default you don’t get to help them with quality assurance; that’s only for those who have been granted specific permission to do so.
(and if you do not have permission to help out, that is manifested only by a cryptic error with a GUID attached to it, which appears only after you’ve spent your valuable time writing a meticulous error description to feed their
/dev/null.)So much for valuing feedback from the developer community. I hope they’ll get there someday!
September 27th, 2006 at 12:36 am
Aw, shucks, that´s really not fair. The people working on Visual Studio must want decent bug reports — no sense in doubting that. But their good intentions are not enough; there seems to be a substantial organizational wall between them and their users, one that does not exist in the open-source world. That is why users enjoy interacting with open-source projects more than they enjoy interacting with Microsoft development projects. That’s just a pity.
September 27th, 2006 at 5:34 pm
Update: Being curious about whether the previously mentioned code example error in the VBScript Language Reference had been fixed, I went to the MSDN home page and searched for “vbscript”. To my pleasant surprise, the top hit was a link to the “VBScript Language Reference”. My joy was however somewhat dampened when I clicked the link and got this message: “The Requested Location Cannot Be Found”. Helpfully enough, Microsoft goes on to suggest the following: “Please update any bookmarks that you might have that are out of date.” Well, right back at you. The climax of this experience came when the automatic redirection resulted in the message: “The system cannot find the file specified.” Badabim badaboom. Operation “Convince-the-ranting-QA-guy-to-go-away-and-never-return” was completed successfully.
November 3rd, 2006 at 8:08 am
Being working with TFS over VPN, and as I sometimes open Visual Studio with VPN disconnected, can feel your pain.
There is trendy undocumented switch in registry that will disable automatic TFS reconnect on VS start. Helps a lot. See http://blogs.msdn.com/hippietim/archive/2006/03/14/551320.aspx
November 3rd, 2006 at 8:42 am
Excellent, thanks!
January 15th, 2007 at 4:00 pm
Looks like that MS Connect feedback submission page did receive my feedback … I just got email notifying me that these reports were all resolved “fixed”: 211946, 211804, 211812, 211813, 211865.
They’re all the same one: the bug report I tried several times to post. So, ranting doomsayers like myself notwithstanding, it does make sense to file feedback at MS Connect. :)
February 7th, 2007 at 11:24 pm
[...] A source control client that blocks the entire IDE while waiting for the server, and hangs on Cancel. [...]