Do I still need it for software updates (for non-Microsoft software, of
course, and maybe the monthly MSRT)?

Assuming I still do need it, can I rename it to stop it running
(renaming it back when needed), or will it auto-fix itself (I see there
is a copy in ...sxs..., which I understand mere mortals shouldn't mess
with)?

I sometimes see it is running. Not necessarily using lots of resources
(though I haven't got many!), so would like to know if it's safe to
remove it by renaming/moving (and whether that'll work anyway, or
whether it'll coy itself back).
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

"Bother,"saidPoohwhenhisspacebarrefusedtowork.

On 4/23/2022 1:53 PM, J. P. Gilliver (John) wrote:
> Do I still need it for software updates (for non-Microsoft software,
> of course, and maybe the monthly MSRT)?
>
> Assuming I still do need it, can I rename it to stop it running (renaming
> it back when needed), or will it auto-fix itself (I see there is a copy
> in ...sxs..., which I understand mere mortals shouldn't mess with)?
>
> I sometimes see it is running. Not necessarily using lots of resources
> (though I haven't got many!), so would like to know if it's safe to
> remove it by renaming/moving (and whether that'll work anyway, or whether
> it'll coy itself back).

Windows 10 or Windows 11 has a pretty tough stance.

Windows 7 isn't quite as bad.

"Windows Module Installer" is "manual start".

This means it does not run for nothing.

If you execute Setup.exe, first you might get a UAC
prompt. You need an impersonate privilege, for the
sequence to work.

TrustedInstaller is not an account in the usual sense.

1) Cannot log in as TrustedInstaller. Cannot add to "Accounts",
although it would be jolly if you could.
2) Has no home directory. No reg files of its own.
3) Available as a service, which carries a token, and
by some means, the token is transferred to another process.

This is (somehow) supposed to thwart malware, but of course
when you're doing registry edits to remove the last vestiges
of a malware, the entries in the registry are owned by... TrustedInstaller :-/

Presumably this is done to make a point.

*******

As the Windows Module Installer, it runs any time that
Program Files or WinSxS need work.

Scanning a disk really should not need it, so if wuauserv
wants to work out the maintenance stance of the machine,
it should not need TrustedInstaller to do that. I presume
it is "writes" which need this authority.

If you disable it, it should probably stay disabled.

There is no USO service on Windows 7, like on Windows 10.
There are no henchmen hiding in Scheduled Tasks, to fiddle
with stuff.

Services, if you use Services.msc, they do have recovery
properties assigned. Killing a service three times,
should be enough to stop it from restarting on its own.
You should be able to review the policy settings and
make sense of this. Items like SuperFetch (SysMain on Win10),
have fairly low aggression settings - when you kill that
one, it doesn't even try to restart, not even once.

But other services "pretend" that their settings are
there, to recover from "Oopsy: faults. As if trying
to restart the service a couple more times, will
smother a software bug with sheet embarrassment.

In any case, if you wield a hammer on Windows 7, I would
expect you to get your own way. Take pictures or make
notes of the original settings, then have at it.

You could also rename TrustedInstaller.exe

cd <someplace>

ren TrustedInstaller.exe TrustedInstaller.exe.bak

That will not disturb the hard link, and if someone
were to do maintenance on WinSxS (somehow), then the linkage
would not be broken. To restore the function, later
you could do

cd <someplace>

ren TrustedInstaller.exe.bak TrustedInstaller.exe

But you're likely to run into some sort of permissions
problem doing that. I would start with Services.msc
first, and see if Disabling it is sufficient for
your needs. That will make this seem less like
an African Safari.

A test would be, disable TrustedInstaller, attempt
to run a Setup.exe , then see if it fails with some
Windows Module Installer type error.

Paul

On Sat, 23 Apr 2022 at 21:08:30, Paul <nospam@needed.invalid> wrote (my
responses usually FOLLOW):
>On 4/23/2022 1:53 PM, J. P. Gilliver (John) wrote:
>> Do I still need it for software updates (for non-Microsoft software,
>> of course, and maybe the monthly MSRT)?
>> Assuming I still do need it, can I rename it to stop it running
>>(renaming
>> it back when needed), or will it auto-fix itself (I see there is a copy
>> in ...sxs..., which I understand mere mortals shouldn't mess with)?
>> I sometimes see it is running. Not necessarily using lots of
>>resources
>> (though I haven't got many!), so would like to know if it's safe to
>>remove it by renaming/moving (and whether that'll work anyway, or
>>whether
>> it'll coy itself back).
copy
>
>Windows 10 or Windows 11 has a pretty tough stance.
>
>Windows 7 isn't quite as bad.

I'm asking about 7, though your whole post marked keep for reference.
>
>"Windows Module Installer" is "manual start".
>
>This means it does not run for nothing.
>
>If you execute Setup.exe, first you might get a UAC
>prompt. You need an impersonate privilege, for the
>sequence to work.

Any specific setup.exe? I think I have between 119 and 146 of them on C:
alone.
>
>TrustedInstaller is not an account in the usual sense.

I wasn't asking about the "account" as such, just specifically the .exe.

[Much that went over my head snipped (-:]

>You could also rename TrustedInstaller.exe

That's what I was wondering about. I was wondering if it was one of
those files that would reappear if deleted/moved/renamed (and the fact
that I found a copy of it in sxs made me think maybe it would).
>
> cd <someplace>
>
> ren TrustedInstaller.exe TrustedInstaller.exe.bak
>
>That will not disturb the hard link, and if someone

Ah, despite having read about them quite a lot, I still don't understand
"hard links". [Somewhat cognate with "libraries".] I (seem to, as shown
by Everything!) have two copies (same size, 200 KB, and date,
2010-11-20) of TrustedInstaller.exe: one in C:\Windows\servicing, and
one in
C:\Windows\winsxs\x86_microsoft-windows-trustedinstaller_31bf3856ad364e35
_6.1.7601.17514_none_93149d6fab68cf06 . Does "hard link" mean I really
only have one (the one in sxs?), and the other one is just a link to it?
I had been thinking of the <someplace> in your instructions above being
Windows\servicing, as I've understood messing with the sxs structure is
not to be done by the faint-hearted.

>were to do maintenance on WinSxS (somehow), then the linkage
>would not be broken. To restore the function, later
>you could do
>
> cd <someplace>
>
> ren TrustedInstaller.exe.bak TrustedInstaller.exe
>
>But you're likely to run into some sort of permissions
>problem doing that. I would start with Services.msc
>first, and see if Disabling it is sufficient for
>your needs. That will make this seem less like
>an African Safari.

Oh, I'm already feeling like I'm on a safari, even if it's only in
Seattle (-: ... I'm not sure what my "needs" (wants?) are; I'll explain
at the end.
>
>A test would be, disable TrustedInstaller, attempt
>to run a Setup.exe , then see if it fails with some
>Windows Module Installer type error.
>
> Paul

My reason for asking (if I _can_ safely/successfully rename TI.exe):

Not infrequently, I find my system is very sluggish (often, though not
always, hard disc light on constantly) - even if I don't think I'm
actually doing anything, other than having lots of browser tabs open
(and I have The Great Suspender Original add-on that "sleeps" tabs after
a period of not accessing them). So I look in Task Manager to see if I
can see what's going on. Sometimes, I see TrustedInstaller.exe is
running - not necessarily taking a lot of resources, though sometimes it
is.

As well as when it _is_ taking a significant chunk of resources, I just
wonder (even when it isn't): its _name_ suggests something is being
_installed_. Which for Windows 7 I don't expect - at least, not when I
haven't just instigated something, such as the (roughly) monthly MSRT or
a Chrome self-update, or installing a new piece of software (rare for me
these days); anyway, all of those I'd know I was doing: I wouldn't
expect to see any sort of "installer" running otherwise. So I was just
wondering if I could stop it by renaming it, or would it (or some other
part of the system) just copy back another copy of itself. [And also, if
I _was_ successful in stopping/preventing it by renaming, would I get an
error message when doing something that actually needed it, or would
that something just stop, waiting, for ever, possibly causing some
apparently-unconnected function to stop working.]
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

If you think privacy is unimportant for you because you have nothing to hide,
you might as well say free speech is unimportant for you because you have
nothing useful to say - Garas Paras @GarasParas on Twitter, 2020-5-5

On 23/04/2022 18:53, J. P. Gilliver (John) wrote:
> Do I still need it for software updates (for non-Microsoft software, of
> course, and maybe the monthly MSRT)?
>
> Assuming I still do need it, can I rename it to stop it running
> (renaming it back when needed), or will it auto-fix itself (I see there
> is a copy in ...sxs..., which I understand mere mortals shouldn't mess
> with)?
>
> I sometimes see it is running. Not necessarily using lots of resources
> (though I haven't got many!), so would like to know if it's safe to
> remove it by renaming/moving (and whether that'll work anyway, or
> whether it'll coy itself back).

Notwithstanding Paul's comprehensive explanation, I wouldn't mess with it.

--

Fake news kills!

I may be contacted via the contact address given on my website:
www.macfh.co.uk

On Sat, 23 Apr 2022 18:53:59 +0100, "J. P. Gilliver (John)"
<G6JPG@255soft.uk> wrote:

>Do I still need it for software updates (for non-Microsoft software, of
>course, and maybe the monthly MSRT)?
>
>Assuming I still do need it, can I rename it to stop it running
>(renaming it back when needed), or will it auto-fix itself (I see there
>is a copy in ...sxs..., which I understand mere mortals shouldn't mess
>with)?
>
>I sometimes see it is running. Not necessarily using lots of resources
>(though I haven't got many!), so would like to know if it's safe to
>remove it by renaming/moving (and whether that'll work anyway, or
>whether it'll coy itself back).

LEAVE IT ALONE

KenW

On 4/24/2022 6:29 AM, J. P. Gilliver (John) wrote:
> On Sat, 23 Apr 2022 at 21:08:30, Paul <nospam@needed.invalid> wrote (my responses usually FOLLOW):
>> On 4/23/2022 1:53 PM, J. P. Gilliver (John) wrote:
>>> Do I still need it for software updates (for non-Microsoft software,
>>> of course, and maybe the monthly MSRT)?
>>>  Assuming I still do need it, can I rename it to stop it running (renaming
>>> it back when needed), or will it auto-fix itself (I see there is a copy
>>> in ...sxs..., which I understand mere mortals shouldn't mess with)?
>>>  I sometimes see it is running. Not necessarily using lots of resources
>>> (though I haven't got many!), so would like to know if it's safe to remove it by renaming/moving (and whether that'll work anyway, or whether
>>> it'll coy itself back).
> copy
>>
>> Windows 10 or Windows 11 has a pretty tough stance.
>>
>> Windows 7 isn't quite as bad.
>
> I'm asking about 7, though your whole post marked keep for reference.
>>
>> "Windows Module Installer" is "manual start".
>>
>> This means it does not run for nothing.
>>
>> If you execute Setup.exe, first you might get a UAC
>> prompt. You need an impersonate privilege, for the
>> sequence to work.
>
> Any specific setup.exe? I think I have between 119 and 146 of them on C: alone.
>>
>> TrustedInstaller is not an account in the usual sense.
>
> I wasn't asking about the "account" as such, just specifically the .exe.
>
> [Much that went over my head snipped (-:]
>
>> You could also rename TrustedInstaller.exe
>
> That's what I was wondering about. I was wondering if it was one of those files that would reappear if deleted/moved/renamed (and the fact that I found a copy of it in sxs made me think maybe it would).
>>
>>   cd <someplace>
>>
>>   ren TrustedInstaller.exe TrustedInstaller.exe.bak
>>
>> That will not disturb the hard link, and if someone
>
> Ah, despite having read about them quite a lot, I still don't understand "hard links". [Somewhat cognate with "libraries".] I (seem to, as shown by Everything!) have two copies (same size, 200 KB, and date, 2010-11-20) of TrustedInstaller.exe: one in C:\Windows\servicing, and one in C:\Windows\winsxs\x86_microsoft-windows-trustedinstaller_31bf3856ad364e35
> _6.1.7601.17514_none_93149d6fab68cf06 .  Does "hard link" mean I really only have one (the one in sxs?), and the other one is just a link to it? I had been thinking of the <someplace> in your instructions above being Windows\servicing, as I've understood messing with the sxs structure is not to be done by the faint-hearted.
>
>> were to do maintenance on WinSxS (somehow), then the linkage
>> would not be broken. To restore the function, later
>> you could do
>>
>>   cd <someplace>
>>
>>   ren TrustedInstaller.exe.bak TrustedInstaller.exe
>>
>> But you're likely to run into some sort of permissions
>> problem doing that. I would start with Services.msc
>> first, and see if Disabling it is sufficient for
>> your needs. That will make this seem less like
>> an African Safari.
>
> Oh, I'm already feeling like I'm on a safari, even if it's only in Seattle (-: ... I'm not sure what my "needs" (wants?) are; I'll explain at the end.
>>
>> A test would be, disable TrustedInstaller, attempt
>> to run a Setup.exe , then see if it fails with some
>> Windows Module Installer type error.
>>
>>   Paul
>
> My reason for asking (if I _can_ safely/successfully rename TI.exe):
>
> Not infrequently, I find my system is very sluggish (often, though not always, hard disc light on constantly) - even if I don't think I'm actually doing anything, other than having lots of browser tabs open (and I have The Great Suspender Original add-on that "sleeps" tabs after a period of not accessing them). So I look in Task Manager to see if I can see what's going on. Sometimes, I see TrustedInstaller.exe is running - not necessarily taking a lot of resources, though sometimes it is.
>
> As well as when it _is_ taking a significant chunk of resources, I just wonder (even when it isn't): its _name_ suggests something is being _installed_. Which for Windows 7 I don't expect - at least, not when I haven't just instigated something, such as the (roughly) monthly MSRT or a Chrome self-update, or installing a new piece of software (rare for me these days); anyway, all of those I'd know I was doing: I wouldn't expect to see any sort of "installer" running otherwise. So I was just wondering if I could stop it by renaming it, or would it (or some other part of the system) just copy back another copy of itself. [And also, if I _was_ successful in stopping/preventing it by renaming, would I get an error message when doing something that actually needed it, or would that something just stop, waiting, for ever, possibly causing some apparently-unconnected function to stop working.]

You would rename

C:\Windows\servicing\TrustedInstaller.exe

as the others seem to be in WinSxS.

But I don't think rename is necessary. Disabling
the service should be enough. And in keeping with
standard Windows practice...

Service Name: TrustedInstaller

Display Name: Windows Module Installer (services.msc entry)

*******

Hardlinking is one set of data clusters, two file pointers.

System32_one ----+
>--- DataClusters
WinSxS_one ------+

The file can be modified by using either handle.
There is one filenum entry, with two $FILE under it,
so the names are actually stored in the same place in a sense.
The files don't even need to have the same name, but
that would be a bit sloppy to call it Micky in one
place and Minnie in the other. The NFI.exe utility from
Microsoft can at least show when hardlinking is going on.
But NFI does not print out the contents of the entries.

Filenum TrustedInstaller.exe
$FILE System32_one
$FILE WinSXS_one

The mechanism is not limited to just two $FILE. Some
files are hardlinked more than twice. Although I'm
not 100% certain we have good enough utilities to give
precise info. Sometimes the count from Linux is different
than the count from Windows, and this would be a mandatory
requirement, that any software claiming to have an NTFS
driver, can extract all the names and do it properly.

I was doing something a while back, thought I was cloning,
when the linkage between System32 and WinSxS was broken,
and the cloned file system was 8GB bigger. You have to
keep a weather eye peeled, that the mandatory support
actually works :-/ If I had continued to use that clone,
the Servicing would be broken from then on (WU would have
no effect, bugs would be unpatched).

*******

As for the functions, it's a bit hard for me to say. I've not
seen the thing addressed directly. No "bullet list" of features.
All I can say, is TrustedInstaller seems to hold a token, a
token that other softwares copy so they can work in Program Files
or WinSxS (Servicing activity in Side-by-Side).

When it comes to installation logic, the OS knows what to
do if presented with a MSI file. This guy can parse the
contents and follow whatever passes for scripting in here.
If you have InstallShield, there can be some folders on C:
with material for processing those too (the first run of
InstallShield, leaves crap behind). This means that
TrustedInstaller isn't doing this function.

C:\Windows\System32\msiexec.exe

TrustedInstaller as a service is demand-started. When you're
stealing the token, you start it up manually about five
seconds before your program needs it, and then copy the
token. I have a program that can make me TrustedInstaller,
and that's how I can remove a registry entry stamped
with that by malware. Programs like psexec from Sysinternals
can make you SYSTEM, but TrustedInstaller is not on the
menu with that program. And just because you're Administrator,
you can't always bodge stuff, without this extra ceremony.

Wuauserv (Windows Update Automatic Update Service) scans
packages, compares to wsusscn2.cab info, looking for work
to do. I have no idea of the details, except to say "it's
annoying and it involves scanning". Wuauserv might need to
access TrustedInstaller once, to get a token for some reason.

TrustedInstaller is supposed to shut down after a time of
inactivity, so if no one is repetitively stealing tokens
from it, it should disappear. In Google, you can find
examples of third party installers (Citrix?) that
keep screwing with it, and that's why it stays awake.
But when it stays awake, it should not stay in a
tight loop and burn up a core either. Lots of software
on the machine are event based, send a message to a process,
it sends a message back. No cycles need be wasted once
that exchange is finished. There are many services in
Windows that live silent lives, and Process Explorer will
tell you they are using zero cycles.

On Sun, 24 Apr 2022 at 11:09:33, Paul <nospam@needed.invalid> wrote (my
responses usually FOLLOW):
[]
>You would rename
>
> C:\Windows\servicing\TrustedInstaller.exe
>
>as the others seem to be in WinSxS.
>
>But I don't think rename is necessary. Disabling
>the service should be enough. And in keeping with

I have the feeling that, in the past, I've found services running that I
was pretty sure I'd stopped; I think other things start them.

>standard Windows practice...
>
> Service Name: TrustedInstaller
>
> Display Name: Windows Module Installer (services.msc entry)
>
>*******
>
>Hardlinking is one set of data clusters, two file pointers.
>
> System32_one ----+
> >--- DataClusters
> WinSxS_one ------+
>
>The file can be modified by using either handle.
>There is one filenum entry, with two $FILE under it,
>so the names are actually stored in the same place in a sense.
>The files don't even need to have the same name, but
>that would be a bit sloppy to call it Micky in one
>place and Minnie in the other. The NFI.exe utility from
>Microsoft can at least show when hardlinking is going on.
>But NFI does not print out the contents of the entries.

Are you saying I _could_ rename the "file" in Windows\servicing and the
system _wouldn't_ name it back (or, more likely, retrieve another copy)?
>
> Filenum TrustedInstaller.exe
> $FILE System32_one
> $FILE WinSXS_one
>
Hmm. I have a .zip I fetched after you posted about it here 2021-1-18,
but I can only find nfi.dbg and nfi.pdb in it, no .exe.

>The mechanism is not limited to just two $FILE. Some
>files are hardlinked more than twice. Although I'm
>not 100% certain we have good enough utilities to give
>precise info. Sometimes the count from Linux is different
>than the count from Windows, and this would be a mandatory
>requirement, that any software claiming to have an NTFS
>driver, can extract all the names and do it properly.
>
>I was doing something a while back, thought I was cloning,
>when the linkage between System32 and WinSxS was broken,
>and the cloned file system was 8GB bigger. You have to
>keep a weather eye peeled, that the mandatory support
>actually works :-/ If I had continued to use that clone,
>the Servicing would be broken from then on (WU would have
>no effect, bugs would be unpatched).

Hmm, I don't think there are going to be many patches for W7 now.
>
>*******
>
>As for the functions, it's a bit hard for me to say. I've not
>seen the thing addressed directly. No "bullet list" of features.
>All I can say, is TrustedInstaller seems to hold a token, a
>token that other softwares copy so they can work in Program Files
>or WinSxS (Servicing activity in Side-by-Side).
>
>When it comes to installation logic, the OS knows what to
>do if presented with a MSI file. This guy can parse the
>contents and follow whatever passes for scripting in here.
>If you have InstallShield, there can be some folders on C:
>with material for processing those too (the first run of
>InstallShield, leaves crap behind). This means that
>TrustedInstaller isn't doing this function.
>
> C:\Windows\System32\msiexec.exe
>
>TrustedInstaller as a service is demand-started. When you're
>stealing the token, you start it up manually about five
>seconds before your program needs it, and then copy the
>token. I have a program that can make me TrustedInstaller,
>and that's how I can remove a registry entry stamped
>with that by malware. Programs like psexec from Sysinternals
>can make you SYSTEM, but TrustedInstaller is not on the
>menu with that program. And just because you're Administrator,
>you can't always bodge stuff, without this extra ceremony.
>
>Wuauserv (Windows Update Automatic Update Service) scans
>packages, compares to wsusscn2.cab info, looking for work
>to do. I have no idea of the details, except to say "it's
>annoying and it involves scanning". Wuauserv might need to
>access TrustedInstaller once, to get a token for some reason.
>
>TrustedInstaller is supposed to shut down after a time of
>inactivity, so if no one is repetitively stealing tokens
>from it, it should disappear. In Google, you can find
>examples of third party installers (Citrix?) that
>keep screwing with it, and that's why it stays awake.
>But when it stays awake, it should not stay in a
>tight loop and burn up a core either. Lots of software
>on the machine are event based, send a message to a process,
>it sends a message back. No cycles need be wasted once
>that exchange is finished. There are many services in
>Windows that live silent lives, and Process Explorer will
>tell you they are using zero cycles.
>
>Maybe it has some other function, but unless I can find
>an info page that addresses it head-on, I cannot tell you
>by the process of elimination, what function is "missing"
>and TI could be a candidate for owning it. When it goes
>into a loop, nobody ever mentions why it could possibly
>go into a loop. Does the protocol involve a busy-wait ?
>That would be bizarre.
>
> Paul

I think KenW's "LEAVE IT ALONE" may be the wisest way to go (-:

(I did try renaming the one in C:\Windows\servicing, but got Access is
denied.)
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

Linux is a car kit and Mac is a car with the hood welded shut - Mayayana in
alt.windows7.general, 2015-12-4

On 4/24/2022 5:12 PM, J. P. Gilliver (John) wrote:

> I think KenW's "LEAVE IT ALONE" may be the wisest way to go (-:
>
> (I did try renaming the one in C:\Windows\servicing, but got Access is denied.)

As a determined individual, I bet you would eventually get your own way :-)
The Security Tab is only meant to make you think it can be defeated
by frontal attack. The computer hates surprise attacks.

Paul

On Sun, 24 Apr 2022 22:12:50 +0100, J. P. Gilliver (John) wrote:
> I have the feeling that, in the past, I've found services running that I
> was pretty sure I'd stopped; I think other things start them.

Don't just stop an unwanted service; disable it.

I can't guarantee that something wouldn't re-enable this Trusted
Installer service, which I've never stopped, but I've found once I
disable other services, such as Apple's bloatware that comes with
iTunes, they are dead unless I re-enable them.

--
Stan Brown, Tehachapi, California, USA https://BrownMath.com/
Shikata ga nai...