services.exe intermittently using 10-20 GB of memory when Visual Studio 2013 is running

Question

When I run Visual Studio 2013 on one of my machines, I notice that services.exe will intermittently consume 10-20 GB of memory. This happens randomly and seems to have no relation to anything I do; I can just open a project and leave it in the background, and services.exe will eventually begin to consume excessive memory.

As a result, my entire system becomes unusable (presumably due to memory thrashing), and I have to kill Visual Studio. Even after killing it, it can take up to 5 minutes before the memory usage drops back down. In extreme cases, I have to reboot my machine because I can't bring up Task Manager or Process Explorer.

I have three machines, and only one machine experiences this problem. The machine in question is a Mac Pro with 24 processors and 16 GB of RAM, running Windows 7 Ultimate N. I'm using Bootcamp to run Windows. The machine is fairly clean, having only Visual Studio and Git for Windows installed, on top of Bootcamp. Another developer also uses Bootcamp with higher specs, and they don't encounter this problem, so it doesn't seem to be a general Bootcamp problem.

What could the issue be? Is there any way to diagnose it?

Answer 1

At first blush, I thought this might have something to do with the Native Image Generation Service (ngen). This can either be invoked directly, or run as a service. But the name of the service is actually mscorsvw.exe (I think; unless it changed in .NET 4.5 / VS 2013). Also, I forgot that services.exe is actually the Service Control Manager, and does not refer to any particular service, because no Windows Services are actually hosted within services.exe.

Problem is, this is going to be super specific to your particular configuration. It could be hardware; it could be a driver; it could conceivably be a virus running as a seemingly legitimate process to try and mask itself.

Check your Windows event log under Administrative Tools. Is it being spammed egregiously? I believe event log writes involve services.exe.

Also possibly of interest is that hotplug device drivers (for USB peripherals, and these days even graphics cards) are loaded via services.exe. From wikipedia:

Services whose Type registry value is SERVICE_KERNEL_DRIVER or SERVICE_FILE_SYSTEM_DRIVER are handled specially: these represent device drivers for which ScStartService() calls the ScLoadDeviceDriver() function which loads the appropriate driver (usually a file with an extension .sys) which must be located in the %SystemRoot%\System32\Drivers\ directory. For that purpose, the NtLoadDriver system call is invoked, and the SeLoadDriverPrivilege is added to the SCM's process.

So the SCM, aka services.exe, has a fragile and highly privileged interaction with the system's device drivers. A driver could very likely be malfunctioning and periodically trying to reload itself (perhaps due to a crash), and eating a lot of RAM in the SCM during its initialization routine, which is done in-process in services.exe.

This answer is very speculative because I don't have a precise answer based on the information you provided. Sorry.

Things to try:

• Watch the event log like a hawk. See if anything gets written around the time that you experience the lag.
• See if it happens without Visual Studio running.
• Try updating your drivers. I know that sounds silly, but it could actually be drivers.