I have a couple individuals on our team that can't use the Souce Control Explorer. Visual Studio will stop responding w/ a couple mouse clicks.

For example,

1. When they click on "Workspace" and choose "Workspaces" in the drop down the "Manage Workspaces" window appears fine. However, when they select "Add" or "Edit" the application will freeze.

2. In the Source Code folder, when they right click on a file and choose "Compare", Visual Studio will stop responding.

Other memebers on our team can preform the exact same steps and function perfectly. We have tried reinstalling Visual Studio and TFS with no luck.

Any Ideas?

Justin,

If you enable client tracing you should be able to pinpoint where the problem is occurring and we might be able to help you better. This post tells you how to enable it:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=430341&SiteID=1

Regards,

William Bartholomew

When I do one of the actions that locks the application, it doesn?? write anything to the log so I don?? think it is going to be any use. I do see in the log opening VS and trying to add a workspace.

This is probably a stretch but do you have any third party VS add-ins running? There is a bug that Tim Noonan has responded to a couple of times in this forum where our interaction with VS and that of the add-in causes a modal window to lose focus -- essentially a "hang".

Also, I'm curious to know if the hang is CPU-intensive or not. What does Task Manager show for CPU usage when you get into this state?

Thanks,

Ben Ryan

I have compared any add-ins that he has installed and it is no different than mine, which is no add-ins (we reviewed his add-ins in the "Add-In Manager" w/ nothing listed. We even tried to uninstall his app and reinstall it and we are getting the same result on his box, but mine works fine.

Basically, when it "hangs" it doesn't touch his CPU. His CPU performance usage isn't touched, but his application status is "Not Responding". All 4 processors bounce between 20 and 30% while he is in the app, but as soon as it "hangs" drops to basically 1% CPU usage.

His PF Usage stays about the same at 1.7 GB.

Hi Justin:

Quick question. this only happens on this machine, correct? If that is the case I think we are pretty much out of luck and you have 2 options.

1) reimage the machine and install everything again OR

2) call tech support and open a ticket for them to help you

If you don't reimage and find out what the issue was please let us know.

thanks, mario

We have been able to identify the issue.

I tried logging into the machine that was causing problems w/ my own profile and using his installation of TFS and it worked fine for me. So since we knew that the installation was good, we figured there must be some settings files stored in the windows profile.

After doing some looking, we found the following file:

C:\Documents and Settings\[WINDOWS USER]\Local Settings\Application Data\Microsoft\Team Foundation\1.0\Cache\UISettings.config

which contained the following settings:

<UIConfig>

<AttachmentAddDialog x="271" y="438" />

<ColumnPickerDialog height="500" width="500" x="178" y="325" />

<CreateTfsGroupDialog x="473" y="372" />

<DialogAddItems height="450" width="529" x="1539" y="300" />

<DialogCheckin height="903" width="1149" x="22" y="22" />

<DialogCompareVS height="314" width="564" x="1654" y="349" />

<DialogFileFolderProperties height="742" width="1017" x="1461" y="63" />

<DialogMove height="129" width="517" x="1660" y="447" />

<DialogProjectMappings height="366" width="612" x="1731" y="381" />

<DialogWorkspace height="598" width="744" x="1653" y="329" />

<GroupChooserDialog height="319" width="384" x="132" y="132" />

<GroupPropertiesDialog height="524" width="563" x="1508" y="321" />

<GroupsDialog height="665" width="942" x="1390" y="116" />

<LinkDialog x="-968" y="492" />

<PermissionsDialog height="822" width="1032" x="1396" y="51" />

<QuerySaveAsDialog height="336" width="355" x="463" y="305" />

<UserPropertiesDialog height="301" width="384" x="22" y="22" />

</UIConfig>

If you notice the <LinkDialog x="-968" y="492"> you will realize the window that is generated is coming up off the screen. Since the application window is taking control of the application, it appears "hung".

We reset this value and it is working fine.

We also had another developer mention a similar concern w/ the "Go to Work Item" window. When he would choose this function, he wouldn't see the window everyone else could, but would go ahead and type out the work item number (assuming it was taking it somewhere) and hit enter and it would take him to the work item and didn't think anything of it.