VS2012 RC split window loses indicators

In VS2012 RC, when editing a source file (C# in my case), if you split the window (menubar: Windows -> Split), the top window frame no longer has the ncrunch red/green indicators, while the bottom frame does. If you then remove the window split, the top window survives, thus the file no longer has the indicators. If you close, then reopen the file, the indicators return.


I'm running:
NCrunch 1.40.0.23b
Visual Studio 2012 RC (v11.0.50522.1 RCREL)
ReSharper 7 EAP (Build 7.0.64.89 - from 2012-06-09T03:14:46)


On a side note:
I'm very happy with the 1.40 release. It's very speedy and lighter on memory than previous releases (although I'm still seeing the BuildHost instances take about 900MB each, whereas VS2012 is only using 625MB). Keep up the good work -- this is a great piece of software!

Hi John,

Thanks for reporting this! I'll add it to the list of compatibility issues to check over for VS2012.

I'm curious about the memory utilisation you've described for the BuildHost, as usually I don't see this go over 100MB per process. Do you find this memory utilisation increases rapidly or does it slowly leak up over time?

The memory issues are slow leaks over time, as best as I can tell. It's not something I monitor that closely, as my dev machine usually has plenty of memory to spare. I did notice later that same day the two BuildHost processes were up to 1.3 GB each. However, they are currently at 200MB each. I don't recall if I restarted VS in that timeframe.

I tried attaching a memory profile to the process once when they were in the 1GB+ range, but during the time it took the profiler to take a memory snapshot, the process died, so I couldn't get a feel for where the memory is going. Initially, I suspected it was something I was doing in my test code around testing static classes/singletons, but after you renamed the processes in a recent release to separate the build from test processes, I noticed it was the BuildHost that was getting big.

I tend to leave VS open overnight and usually notice the memory usage first thing in the morning, but I don't know if that's because it's grown overnight, or if I just wasn't paying attention to memory during the day before.

I'll start taking notes this week tracking memory footprint over time and try to locate any trends.

Re: memory usage.

Just watching the memory usage over the last 24 hours, I've seen it grow from 226KB to 1.3GB. Specific readings below.
What additional information can I collect for you to help determine what's being stored in memory? Would a bug report from within VS provide any snapshot details like that?

Readings via Window7 Task Manager for nCrunch.BuildHost.x86.exe processes :

Mon, 8:05AM
ProcessId WorkingSet PeakWorkingSet
8664 226,680 K 391,332 K
9396 233,180 K 262,056 K


Mon, 11:09AM
ProcessId WorkingSet PeakWorkingSet
8664 449,020 K 472,368 K
9396 449,604 K 455,088 K


Mon, 12:39PM
ProcessId WorkingSet PeakWorkingSet
8664 626,940 K 635,900 K
9396 646,744 K 669,232 K

Mon, 3:00PM
ProcessId WorkingSet PeakWorkingSet
8664 719,324 K 749,164 K
9396 739,128 K 761,708 K

Mon, 5:40PM
ProcessId WorkingSet PeakWorkingSet
8664 1,003,156 K 1,031,340 K
9396 1,010,748 K 1,033,052 K

Tue, 10:29AM
ProcessId WorkingSet PeakWorkingSet
8664 1,293,932 K 1,326,176 K
9396 1,295,996 K 1,325,152 K

Thanks, this is extremely useful! From the information you've given me, I have three theories:

1. The memory leak is caused by the NCrunch code running inside the build host (I hope this is the case as the problem should then be fixable).

2. The memory leak is being caused by build tasks being invoked by NCrunch

3. It's both

I've yet to see the same behaviour on any of my test solutions, so this suggests that the problem is either specific to your solution or is more noticeable with it.

I'll note down to conduct a bit of a review to see if I can find any leaks during a standard build process. I'll also look at adding a resource monitor that will recycle the build host when its memory utilisation reaches a certain point (as this is fairly cheap to do).


Thanks again.

Two more quick notes:

1) I notice that NCrunch shows the "Abnormal runtime assembly reference resolution detected" message for my test assembly. I haven't figured out why yet, and tests run fine. Not sure if this is related to the memory issues.

2) I had a company meeting yesterday, during which VS was sitting idle. Before the meeting, each BuildHost process was sitting around 250KB. After the 4 1/2 hour meeting, they had both decreased about 2KB. So memory growth is definitely not occurring when changes are idle. (I didn't expect otherwise, but always good to check your assumptions).

Thanks. I also don't think that the abnormal resolution would have any impact on your memory usage - and if your tests run fine, then you can probably ignore this warning.

The build host doesn't really do anything when the NCrunch queue is empty of build tasks. Most likely the leak is being caused by the build steps themselves, so you'll probably be able to reproduce it by continuing to right-click on a project in your Tests Window and choosing to rebuild it.

For anyone interested, NCrunch 1.41b has just been released including a new configuration option designed to limit the memory consumption by NCrunch build processes. While this doesn't stop the memory from 'leaking' as a result of the build, it will allow NCrunch to regularly recycle the build processes thus preventing the memory consumption from being a problem.

By default, the configuration option is set to limit build process usage to a maximum of 125MB.