Closing files in the VS2010 editor is extremely slow - by TrevorTi

Status : 

  External<br /><br />
		This item may be valid but belongs to an external system out of the direct control of this product team.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 612038 Comments
Status Closed Workarounds
Type Bug Repros 1
Opened 10/9/2010 5:22:18 AM
Access Restriction Public


I work on a solution containing around 35 projects, including a few Silverlight projects, a web server a rich client and the rest are libraries. I'm using VS2010 (V10.0.30319.1 RTMRel) on Windows 7 Prof (V6.1..7600)

My problem is that it takes between 30 and 60 seconds (and sometimes more) to close a single open editor file. This is always the case, and is independent of the number of files open in VS at the time. This is obviously a pretty crippling delay to endure while developing.

While the file closes the circular 'hourglass' cursor is displayed and VS becomes 'Not Responding'. When closing a number files in sequence they each encounter the delay.
Closing 'all files but this one' results in a magnification of the issue: The total wait depends upon the number of open files, but can take many minutes to complete. The issue also occurs when closing the solution as, I assume each open file is separately closed.

I've tried to use the VS Performance tool (PerformanceDiagnostics.exe) I've seen mentioned on the forums, but when I try start a profile against the devenv process the 'Starting XPerf profiling. Please wait' message sits indefinitely and the profiling does not start.

I've also generated a trace file manually using xperf buy: Opening my solution in VS, starting the xperf trace, closing a single file, and dumping the xperf etl file. The problem is I'm not sure how to evaluate the results. I can see what looks significant amounts of disk IO (between 200 and 600 'counts' for 80% of the trace time) which seems unusual (the total time taken to close the file in this case was around 50 seconds).

It may be relevant that I've got Resharper installed, although I have tried disabling it and it did not solve the problem.

Is this a know issue? Is there any fix for this? 
Sign in to post a comment.
Posted by Microsoft on 10/12/2010 at 12:39 PM
Hello Trevor,

Thanks for updating the defect. I'm glad to know you've found out the source of the issue. I'm going to close the defect.

I looked at the trace you've sent us (without realizing that you had already updated the defect with your latest message) and couldn't really parse any useful information out of it. Typically, when we collect traces, we need to have "sampling" turned on. The trace you generated only had context switches and disk I/O.

The performance measurement tool typically takes a long time before it starts the profiler for you, so next time give it a few minutes! If it still did not start, please feel free to contact us to debug the problem or when you use xperf manually, be sure to turn sampling on.

Posted by TrevorTi on 10/11/2010 at 11:31 PM

I believe you can close this issue.

It turns out the issue is not (directly) related to VS at all. On a hunch I deactivated the 'Antivirus Auto Protect' feature of Norton Anti-virus (Norton Internet Security V17.7) that I have running on my machine and that solved the issue.

From taking almost a minute to close an editor file, it now takes a few seconds at most.
Posted by TrevorTi on 10/11/2010 at 4:23 AM
I have uploaded some trace data as requested by your second post. If includes DXDiag information as well as the results of an XPerf trace.

As mentioned in my original post I've been unable to get the VS Performance tool to work (attempting to start a session using 'Start Profiler' just sits forever attempting (waiting) to start). The trace I've uploaded was from a manual xperf run as follows:

xperf -on DiagEasy -pids <process-id-of-devenv.exe>
followed by performing the file close operation in VS
followed by:
xperf -d filename.etl

Hope this helps: If not, let me know what xperf command line I can/should use to get useful information.


Posted by TrevorTi on 10/11/2010 at 12:04 AM
I have followed first suggestion (use VS to debug VS). The slight difference in what actually took place to what is described is that, since the issue is just 'slow response' rather than crash or hang control does not return to the second VS instance. However, I manually went to the 2nd instance, selected 'break all' from the Debug menu and then Saved the Dump.

I'll attach the results.

One curious observation: The act of attaching the 2nd instance of VS to the first appears to have moderately sped up the process I have a problem with. It did not become 'fast' by any definition but after few attempts it certainly seemed faster than it normally is. Instead of the normal 30-60 seconds to close, with the debugger attached the files took 15-20 seconds to close.
Posted by Microsoft on 10/10/2010 at 7:36 PM
Hi TrevorTi,

It may help if you provide us with a mini dump file and call stack. You can use the following steps to get a mini dump file:
1. Start Visual Studio.
2. Start another instance of VS.
3. In the second instance click Tools | Attach to Process...
4. In the list of processes locate devenv.exe.
5. Click Select... and explicitly choose 'Native' and 'Managed' code.
6. Click OK and OK to close Select dialog and Attach to Process dialog.
7. Go back to the first instance of VS and repro the crash\hang.
8. Upon the crash\hang, control should go to the second instance of VS.
9. In the second instance click Debug | Save Mini Dump (without heap).

If you are running the VB profile you will not see the Save Dump As menu item. To add this menu item:
a. Select Tools -> Customize
b. Select the Commands tab
c. Select Debug from the “Menu bar” dropdown
d. Click “Add Command…”
e. Select Debug from the Categories list.
f. Find the “Save Dump As” entry in the Commands window.
g. Click OK (the “Save Dump As…[mini dump ](without heap)” command is added to the top of the Debug menu).
h. Click “Close”

You can get detailed steps about how to get the dump file and call stack at

Please name the zipped file
You can upload the file to workspace:
Password: #Tejy))YPc
It would be greatly appreciated if you could provide us with that information as quickly as possible. If we do not hear back from you within 7 days, we will close this issue.

Thanks again for your efforts and we look forward to hearing from you.
Visual Studio Product Team
Posted by Microsoft on 10/10/2010 at 7:05 PM
Dear TrevorTi,

We cannot reproduce the issues you mentioned in our labs.

It may help if you provide us with:

1. You can run a DXDIAG and send us the output? (Type DXDiag in Vista/Win Search Box, Click Save All Information, and then e-mail the resulting dxdiag.txt file:

2.Gather some ETW traces around your scenario: In order to do this, please download the VS performance tool from:
Please read the “Performance Diagnostics Tool – User Guide” document (a shortcut to it should appear on your desktop after install) on steps to generate a trace.
Please note that when you uninstall the tool, the settings.ini file will not be removed as it contains your user settings.
Also, unfortunately this tool does not work on XP.
Once you collected traces, we have a secure site where you can upload your perf log files. Please include part of your name and issue in the perf file names, something like “612038.Issue”, or “ConnectNumber.612038”, this really helps us identify between uploaded traces.
Password: #Tejy))YPc

Thank you,
Posted by Microsoft on 10/9/2010 at 6:23 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(