svchost.exe (i.e "service host"), is a technique for grouping several services into one process. The goal is to avoid spawning one process per service, saving some memory.

I believe today the gains are outweighted by the costs of this technique: memory isn't really the limitation factor anymore. On the other hand, grouping several mostly unrelated services in the same process is a security and stability issue.

You can configure things not to group. It's still annoying and opaque that the name of the misbehaving .exe doesn't instantly tell you which goddamned thing is in it, even if it's just one.

Any pointers how?

Yeah, I'm also curious.

I did this for Windows update on Vista last year. It was really misbehaving, chewing up a lot of memory and CPU time. Eventually I found and applied a patch but during the investigation, I isolated Windows update to its own service executable container.

TL; DR:

   sc config <servicename> type= { own | share }

I got that from this SuperUser stackexchange question:

http://superuser.com/questions/860117/isolate-hosted-service...

A registry-tweaking approach is also given.

Then wrote up my own answer to the WU issue:

http://superuser.com/questions/77658/svchost-eating-up-memor...

Excellent, thanks! I wonder if someone could create a VBS script to make all services "own". And, another problem, I wonder if Windows allows to rename processes, like e.g. Linux can because I don't want to see 50 svchost.exe in the task manager - I want them named after respective DLLs.

Some services run as threads in a shared process (svchost) to save some ram because windows has many services. You can see them using Process Explorer from sysinternals.

I'm aware of svchost, however I'm not sure I agree with his comment about the technique being "outdated" without more information on what he meant precisely. Did he mean that...

using a monolithic process is outdated?

using a shared process is outdated?

using threads is outdated?

trying to conserve RAM in this fashion is outdated?

svchost in Windows in particular is outdated?

Starting services on a 'need to run' basis is outdated?

...and quite a few other options. It seems to me like all OSs have similar facilities, so I'm not sure what he means that would not apply to other OSs.

This: 1) "trying to conserve RAM in this fashion is outdated?" and 2) "using a monolithic process is outdated?".

However the biggest problem with 2) is that you cannot see what individual thread(s) cause problems and you cannot easily kill/restart the offending DLL.