Ping: Paul re Svchost

Paul, you posted a brilliant analysis of svchosts.
Any chance you could repost it please.

--
Regards
wasbit

wasbit wrote:
Paul, you posted a brilliant analysis of svchosts.
Any chance you could repost it please.


Do you mean this ?

https://blogs.msdn.microsoft.com/spa...ging-services/

You can split it out into its own service by running:

"sc config service type= own"

And revert it via

"sc config service type= share"

Or the [Run As Administrator] Process Explorer thing ?
For looking at what each service is doing from a
cycle-count point of view ?

Other than that, I generally HATE svchost,
because they hide what is underneath and get
in my road. Many times they've made debugging
impossible. If the toolflow allowed end-users
to "bore inside" the damn things, then I wouldn't
mind. But as long as they're a brick wall, I
will be hating them.

Paul

"wasbit" wrote

| Paul, you posted a brilliant analysis of svchosts.
| Any chance you could repost it please.
|

Analysis? I'm not sure what you have in mind,
but if you want to know about services, what
they do, security risks, recommendations, etc
then there's only one place I know of:

http://www.blackviper.com/

It's all there. Anyone who wants a lean and secure
system would do well to take a look. There are guides
by Windows version, guides oriented to need, such as
home or coorporate, and even an alphabetical index:

http://www.blackviper.com/windows-services/

He used to provide handy PDF downloads,
but those seem to be gone.

"Paul" wrote in message
news
wasbit wrote:
Paul, you posted a brilliant analysis of svchosts.
Any chance you could repost it please.


Do you mean this ?

https://blogs.msdn.microsoft.com/spa...ging-services/

You can split it out into its own service by running:

"sc config service type= own"

And revert it via

"sc config service type= share"

Or the [Run As Administrator] Process Explorer thing ?
For looking at what each service is doing from a
cycle-count point of view ?

Other than that, I generally HATE svchost,
because they hide what is underneath and get
in my road. Many times they've made debugging
impossible. If the toolflow allowed end-users
to "bore inside" the damn things, then I wouldn't
mind. But as long as they're a brick wall, I
will be hating them.


I'm guessing it was an off the cuff reply, to (possibly) high CPU usage,,
which showed how to find which services were running under each instance of
Svchost.

I've since found '7 Ways to Easily Identify SVCHOST.EXE Service Name', but
thought your write up was better.

-
https://www.raymond.cc/blog/identify...ows-task-list/

Can any other readers find & repost it please?

--
Regards
wasbit

"Paul" wrote in message
news
wasbit wrote:
Paul, you posted a brilliant analysis of svchosts.
Any chance you could repost it please.


Do you mean this ?

https://blogs.msdn.microsoft.com/spa...ging-services/

You can split it out into its own service by running:

"sc config service type= own"

And revert it via

"sc config service type= share"

Or the [Run As Administrator] Process Explorer thing ?
For looking at what each service is doing from a
cycle-count point of view ?

Other than that, I generally HATE svchost,
because they hide what is underneath and get
in my road. Many times they've made debugging
impossible. If the toolflow allowed end-users
to "bore inside" the damn things, then I wouldn't
mind. But as long as they're a brick wall, I
will be hating them.


I found this (but not I think, what I was looking for) in reply to Tim on
18/07/17
Message ID:

1) The traditional command is

tasklist /svc

which tends to run on Pro versions of OS, and it dumps
the Services running inside each svchost. You would run this,
to see whether Microsoft is making an attempt to have one
service per SVCHOST, or they're trying to do something else.

2) To see which Service is doing stuff within a SVCHOST,
go to sysinternals.com and get Process Explorer. If you
run Process Explorer as administrator, you gain access to SVCHOST,
and can see the cycle counts of each Service in there. This is good
when a Service goes nuts, and uses up a CPU core.

You can cause a Service to run in a separate SVCHOST. The
first command, is putting a service called "wuauserv" in its
own SVCHOST. The second command makes it share with fourteen
other Services, all living in a particular SVCHOST (i.e. the
second command puts things back as Microsoft intended).

sc config wuauserv type= own
sc config wuauserv type= share

So when you see 68 SVCHOSTs, that can happen with the
over-usage of the first of those two commands, by Microsoft themselves.

And using tasklist /svc, can show you to what extent
they're on a rampage to separate them.

--
Regards
wasbit