Intel / AMD Question

I was looking at the Processes tab of Windows Task Manager, and found
unsecapp.exe: Sink to receive asynchronous callbacks for WMI client
application. That was a new one to me.

I went he

http://www.pcadvisor.co.uk/feature/w...us-or-malware-
3614218/

and found where to locate this file. The article also stated:

"When the results appear, you’ll see the file path listed, as well as a
similar file found in the Windows\winsxs\ folder with either an x86 or AMD
prefix depending on the CPU your PC has fitted."

Hmmm...I found this file in 5 locations, 3 of which have amd64 in the
description. None show x86. (Thgis is a 64 bit processor.) I have an
Intel Processer, as verified with the Intel Processor Identification
Utility.

How do I reconcile the article and what I found on my machine?

TIA

"Boris" wrote

| Hmmm...I found this file in 5 locations, 3 of which have amd64 in the
| description. None show x86. (Thgis is a 64 bit processor.) I have an
| Intel Processer, as verified with the Intel Processor Identification
| Utility.
|
| How do I reconcile the article and what I found on my machine?
|

One of the little known travesties of Vista+ is
that Microsoft basically forces you to install the
whole install DVD to winsxs. There are tens of
thousands of drivers there for hardware you'll
never install, wasting 4-30+ GB of space. The
advantage is that it makes plug and play hardware
install seem improved.

In other words, if you fish around winsxs you'll
find lots and lots and lots of stuff you'll never
need. But delete it at your own risk. I've experimented
with cleaning or getting rid of winsxs. I even tried
moving it to D drive. Everything seemed to work OK
except for deleting the content. That's not a good
idea. Win7 is brittle that way.

WMI is Windows Management Instrumentation.
For most people it's not necessary to leave it running.
It's mostly used by IT people and cheapo system
info utilities. WMI serves as a wrapper system around
numerous Windows tools, like Windows Installer,
Registry access, system info, etc. It's designed to
be usable across a network.

I leave WMI as a service to run at startup only
because I use it in scripting. Otherwise I'd disable
it. I also have unsecapp.exe in the WBEM folder
(WBEM is WMI) but it's not currently loaded and I've
never seen it running. It may be that it's used if
you're on a network. I don't know.

"Mayayana" wrote in
:

"Boris" wrote

| Hmmm...I found this file in 5 locations, 3 of which have amd64 in the
| description. None show x86. (Thgis is a 64 bit processor.) I have
| an Intel Processer, as verified with the Intel Processor
| Identification Utility.
|
| How do I reconcile the article and what I found on my machine?
|

One of the little known travesties of Vista+ is
that Microsoft basically forces you to install the
whole install DVD to winsxs. There are tens of
thousands of drivers there for hardware you'll
never install, wasting 4-30+ GB of space. The
advantage is that it makes plug and play hardware
install seem improved.

I see.


In other words, if you fish around winsxs you'll
find lots and lots and lots of stuff you'll never
need. But delete it at your own risk. I've experimented
with cleaning or getting rid of winsxs. I even tried
moving it to D drive. Everything seemed to work OK
except for deleting the content. That's not a good
idea. Win7 is brittle that way.

I will not.


WMI is Windows Management Instrumentation.
For most people it's not necessary to leave it running.
It's mostly used by IT people and cheapo system
info utilities. WMI serves as a wrapper system around
numerous Windows tools, like Windows Installer,
Registry access, system info, etc. It's designed to
be usable across a network.

I leave WMI as a service to run at startup only
because I use it in scripting.

I see that WMI starts automatically as shown in my Component Services
(Services Local),but it's not in my Task Manager, or msconfig StartUp
tab.

Otherwise I'd disable
it. I also have unsecapp.exe in the WBEM folder
(WBEM is WMI) but it's not currently loaded and I've
never seen it running. It may be that it's used if
you're on a network. I don't know.

I am on a home network,but very rarely log on to other machines on the
network.


Thanks much.

Boris wrote:
I was looking at the Processes tab of Windows Task Manager, and found
unsecapp.exe: Sink to receive asynchronous callbacks for WMI client
application. That was a new one to me.

I went he

http://www.pcadvisor.co.uk/feature/w...us-or-malware-
3614218/

and found where to locate this file. The article also stated:

"When the results appear, you’ll see the file path listed, as well as a
similar file found in the Windows\winsxs\ folder with either an x86 or AMD
prefix depending on the CPU your PC has fitted."

Hmmm...I found this file in 5 locations, 3 of which have amd64 in the
description. None show x86. (Thgis is a 64 bit processor.) I have an
Intel Processer, as verified with the Intel Processor Identification
Utility.

How do I reconcile the article and what I found on my machine?

TIA

https://en.wikipedia.org/wiki/X86-64

"x86-64 is the 64-bit version of the x86 instruction set.

The original specification, created by AMD and released in 2000,
has been implemented by AMD, Intel and VIA.
"

In recognition of that, namespace objects might use AMD64
which means "this is a 64 bit item". It does *not* mean
"applies only to AMD processors". It applies to any
processor supporting the x86-64 set of instructions.
It could apply to a VIA processor even.

All I can tell you is, I don't panic if I see AMD64
in a name. My last AMD processor was an AthlonXP
32bit of long ago. Everything else here is Intel, and
I'm not panicked.

*******

If you have software making WMI calls, that could unleash
a host of strange processes in your task manager.

Maybe some feature in Avast, switched it on.

*******

Items in WinSXS are hard linked into the System folders.
So in fact, when you count five objects, it might really
be only two or three unique objects. The WinSXS folder
exists for Windows Update and maintenance, and the
right version of file is then hard-linked into some
system folder. If all you have is AMD64 ones, then
it must only be available as a 64-bit executable.

Paul

"Boris" wrote

| I see that WMI starts automatically as shown in my Component Services
| (Services Local),but it's not in my Task Manager, or msconfig StartUp
| tab.
|
Msconfig is old fashioned. Better to use Autoruns.
But as a service it's handled through services, anyway.
If you have Process Explorer you should see WMI under
one of the svchost instances. You can try setting it
to manual if you want to and see if it gets started.
There aren't many things with good reason to use it.

On 26/09/2016 22:16, Mayayana wrote:
"Boris" wrote

| Hmmm...I found this file in 5 locations, 3 of which have amd64 in the
| description. None show x86. (Thgis is a 64 bit processor.) I have an
| Intel Processer, as verified with the Intel Processor Identification
| Utility.
|
| How do I reconcile the article and what I found on my machine?
|

One of the little known travesties of Vista+ is
that Microsoft basically forces you to install the
whole install DVD to winsxs. There are tens of
thousands of drivers there for hardware you'll
never install, wasting 4-30+ GB of space. The
advantage is that it makes plug and play hardware
install seem improved.

In other words, if you fish around winsxs you'll
find lots and lots and lots of stuff you'll never
need. But delete it at your own risk. I've experimented
with cleaning or getting rid of winsxs. I even tried
moving it to D drive. Everything seemed to work OK
except for deleting the content. That's not a good
idea. Win7 is brittle that way.

WMI is Windows Management Instrumentation.
For most people it's not necessary to leave it running.
It's mostly used by IT people and cheapo system
info utilities. WMI serves as a wrapper system around
numerous Windows tools, like Windows Installer,
Registry access, system info, etc. It's designed to
be usable across a network.

I leave WMI as a service to run at startup only
because I use it in scripting. Otherwise I'd disable
it. I also have unsecapp.exe in the WBEM folder
(WBEM is WMI) but it's not currently loaded and I've
never seen it running. It may be that it's used if
you're on a network. I don't know.



This is not the answer to the question.

amd64 is the designation used by Microsoft for all 64 bit files.

It's fair enough, AMD invented the 64 bit mode and Intel just copied it
with minor changes.

--

Brian Gregory (in the UK).
To email me please remove all the letter vee from my email address.

"Mayayana" wrote in news:nscct7$vq5$1@dont-
email.me:

"Boris" wrote

| I see that WMI starts automatically as shown in my Component Services
| (Services Local),but it's not in my Task Manager, or msconfig StartUp
| tab.
|
Msconfig is old fashioned. Better to use Autoruns.
But as a service it's handled through services, anyway.
If you have Process Explorer you should see WMI under
one of the svchost instances. You can try setting it
to manual if you want to and see if it gets started.
There aren't many things with good reason to use it.




Process Explorer shows:

wininit.exeservices.exesvchost.exeWmiPrv.exe, unsecapp.exe, and
dllhost.exe
only unsecapp.exe has a description

If I go to Services (Local), and turn WMI to manual (I got all sorts of
warnings). then shut down, next boot up, Process Explorer shows the same
as before, and Services (Local) shows that WMI is still set to normal.

On 9/26/2016 4:19 PM, Boris wrote:
I was looking at the Processes tab of Windows Task Manager, and found
unsecapp.exe: Sink to receive asynchronous callbacks for WMI client
application. That was a new one to me.

I went he

http://www.pcadvisor.co.uk/feature/w...us-or-malware-
3614218/

and found where to locate this file. The article also stated:

"When the results appear, you’ll see the file path listed, as well as a
similar file found in the Windows\winsxs\ folder with either an x86 or AMD
prefix depending on the CPU your PC has fitted."

Hmmm...I found this file in 5 locations, 3 of which have amd64 in the
description. None show x86. (Thgis is a 64 bit processor.) I have an
Intel Processer, as verified with the Intel Processor Identification
Utility.

How do I reconcile the article and what I found on my machine?

Yeah, the official name for the 64-bit architecture was AMD64 at the
beginning, and Microsoft stuck to the naming convention. AMD was the
inventor of the 64-bit x86 architecture, and Intel has a cross-license
for it with AMD.

Yousuf Khan

"Boris" wrote

| Process Explorer shows:
|
| wininit.exeservices.exesvchost.exeWmiPrv.exe, unsecapp.exe, and
| dllhost.exe
| only unsecapp.exe has a description
|

I'm on XP, which is a bit different, but that
doesn't sound problematic.

| If I go to Services (Local), and turn WMI to manual (I got all sorts of
| warnings). then shut down, next boot up, Process Explorer shows the same
| as before, and Services (Local) shows that WMI is still set to normal.
|

Did you check dependencies? On my system I
see Security Center and Windows Firewall/ICS
as depending on WMI. (They shouldn't. I suspect
that's for the networking aspect.) I don't need
any of that stuff and many people don't, but you
might. I'm guessing maybe Security Center is
running and that started WMI. You can try disabling
WMI if you don't want it, after checking dependencies.
There could be something you use that needs it.
In that case you'll have to re-enable it. But aside
from those services it's likely to only be used by
some system info programs.

I don't know of any serious security risks with
WMI, but it does allow for managing computers
across a network, so it may carry some risks.
As with PowerShell, if you don't need it then you
can remove one vulnerability point by not having it.

I've found that the DCOM Server Process Launcher
service is required by WMI. DCOM is distributed
COM, which basically means running stuff on other
computers. Not a good idea for computers not in
a safe intranet. So it would be nice to not need
DCOMSPL, but Microsoft designs things that way,
with the assumption that your computer is on
a corporate intranet, where the network is trustable
and you're not.

DCOM has been involved with security problems
in the past. The usual advice is to disable DCOM
port 135 in one's firewall.

You can explore all that if you care to.