How to Troubleshoot Visual Studio 2012 Hangs/Lockups

Question

I am doing PHP development in Visual Studio, and my solution contains projects for PHP, SSRS, and SQL Server (SSDT). And I am using TFS for version control. So there's a lot going on in my dev environment that can "go wrong".

I am experiencing intermittent hangs, usually around 5 minutes a clip. Visual Studio gives me the wait cursor, and if I click anywhere in VS the window dims. And then I just have to wait it out. Sometimes I can end the devenv.exe task, other times it takes several minutes to terminate the task. If I am feeling patient, I just wait and eventually (around 5 mins) VS comes back to life. I've never experienced loss of data, source control issues, etc, even when I terminate the process.

It happens sometimes when I save. Sometimes when I check-in. Sometimes when I check out. Sometimes when I build. I have been unable to discern any sort of pattern of the behavior.

All my workstation resources are fine- no RAM or i/o or network or CPU issues.

What can I do to troubleshoot this issue? Can I run VS in some sort of logging mode that would allow me to pinpoint what is taking so long during these periods of lockup?

Answer 1

To turn on logging in visual studio, run: devenv.exe /log

I personally would do this with a shortcut.

Answer 2

Consider deleting old TFS Workspace definitions left over from Continuous Integration Builds.

We had this same problem with a large Team Foundation Server project tree. Sometimes, but not always, opening a Solution in Visual Studio 2010 or Visual Studio 2012 would hang exactly as described above. VS 2010 was most vulnerable; VS 2012 seemed less vulnerable, but it still would hang.

We were able to get some clues by monitoring the server activity on the TFS Server machine and the underlying SQL Server machine. A certain query stored procedure was using excessive CPU time in SQL Server. We tracked this stored procedure name to a TFS operation involved in scanning TFS Workspace definitions for other user's checkouts for files.

Our TFS environment has been in use for over 3 years, and we have been using Continuous Integration build definitions using a "zombie army" of developer workstations as TFS Build Agent hosts. We also create new TFS Branches for major releases. Each branch contains about 20 separate Visual Studio Solutions with their own build definitions.

Over time, we had accumulated about 2,000 TFS Workspace definitions on each developer workstation. We had about 10 workstations at one time with their own definitions.

Using the Visual Studio Command window and running as a TFS Administrator, we used this command to identify all workspaces created by our "build user":

tf workspaces /collection:tfservername\collectionname /owner:ourbuilduser >c:\tf_ws_del.bat

We then used global substitutes and the Notepad++ editor macro recorder to convert each result line into this form:

tf workspace /delete /collection:tfservername\collectionname workspacename;ourbuilduser <c:\yes.txt

where C:\yes.txt contained a single line of "y"

We also used some human judgement to remove deletion lines for workspaces named for our most recent TFS branch.

We then ran that c:\tfs_ws_del.bat script in the same Visual Studio Command window and waited patiently for it to finish.

End Result: Our Visual Studio solutions open very quickly. Even browsing the folder hierarchy in Source Control Explorer has sped up considerably.

WARNING: The deletion operations for a very large number of workspaces may expand the TempDB on the underlying SQL Server by a large amount. Coordinate with your DBA's to monitor space on the SQL Server machine. Stopping and restarting the TFS Collection via the graphical TFS Administrator Console tool helps reclaim some of that TempDB space and return it to its internal "free block" list.