software restriction policy - suppress popup ?

[Ninho]

Hi !

Is there a way to setup Windows XP Pro local policies ( being in
a workgroup - no AD) so as to /avoid/ that warning pop-up
whenever software restriction policies strike ?

Many TIA.

 

[VanguardLH]

Hi !

Is there a way to setup Windows XP Pro local policies ( being in
a workgroup - no AD) so as to /avoid/ that warning pop-up
whenever software restriction policies strike ?

Many TIA.

I never get a popup when a SRP rule prevents an executable from loading.
In fact, the only way that I know that it worked is to open Event Viewer
and look in the Application log to see that the executable was blocked
from loading.

Just WHERE are you defining these "software restriction policies" that
generate popups? I use the group policy editor (gpedit.msc) and go to:

Local Computer Policy
|___ Computer Configuration
|___ Windows Settings
|___ Security Settings
|___ Software Restriction Policies
|___ Additional Rules

There I define PATH rules to block the specified executable from
running. I've NEVER seen a popup.

Of course, if I'm blocking a program from running then *I* also am not
deliberately trying to run the program. The idea is to prevent
something else from starting the program as a child process. However,
if YOU run the program then obviously you are going to be told WHY it
won't run. It would be quite rude and confusing to run a program to see
absolutely nothing happen. You won't even see the program's process
load and unload in Task Manager because the program was banned from
loading in the first place.

If you don't want to see popups for programs that you have blocked using
SRPs then YOU shouldn't try to run programs that YOU blocked. Of
course, why are these programs installed if you don't want them to run?
I use SRPs for software that rudely attempts to run ancilliary software
that I don't want to run, like Apple running qttask.exe as part of their
QuickTime product, or a program that replaces its startup item when it
is run but I don't want it loading on Windows startup or on login. If I
didn't want MS Word to load then the easiest solution is not to install
it on my host.

If you (or someone else, which might be you if someone else setup the
SRPs) ran a program and saw nothing happen, what would you think? That
the program crashed, not that you were restricted from running it. If
you set the SRP rule, why are you trying to run the blocked program?
The popup only shows up when YOU try to run the blocked program, not
when something else tries to load it.

I have several PATH rules in SRPs. I have several blocked programs that
occasionally try to run because something else tried to load them. They
get listed in the Event Viewer logs. There is no popup alert because
*I* didn't try to start those blocked programs.

Doctor it hurts when I do that.
Then don't do that.

 

[Ninho]

VanguardLH wrote::

I never get a popup when a SRP rule prevents an executable from loading.
In fact, the only way that I know that it worked is to open Event Viewer
and look in the Application log to see that the executable was blocked
from loading.

Exactly how I wish it worked for me too; but it didn't.

Just WHERE are you defining these "software restriction policies" that
generate popups?

Local security settings (secpol.msc)/software restriction
policies/additional rules

I use the group policy editor (gpedit.msc) and go to:

Local Computer Policy
|___ Computer Configuration
|___ Windows Settings
|___ Security Settings
|___ Software Restriction Policies
|___ Additional Rules

I do *not* find that branch under gpedit.msc. Are we using the
same versions of XP (Pro, SP3, workgroup) or comparing apples &
oranges ?

There I define PATH rules to block the specified executable from
running. I've NEVER seen a popup.

I defined hash based rules to block specific executables, path
rules wouldn't suit my situation. This is a difference, though
why would Windows ring bells on one kind of rules and not another
I can't fathom. Isn't there some registry setting governing the
popup behavior ?

Of course, if I'm blocking a program from running then *I* also am not
deliberately trying to run the program. The idea is to prevent
something else from starting the program as a child process.

Of course no disagreement here. Obviously I too was trying to
prevent certain unwanted exe's from being run by background
processes which I need (...snipped more irrelevant arguing...)


Well, if I can't have the SRPs do their job silently, I'll use
other methods to prevent unwanted child processes from running.

Thanks anyway

 

[VanguardLH]

VanguardLH wrote::



Exactly how I wish it worked for me too; but it didn't.



Local security settings (secpol.msc)/software restriction
policies/additional rules


I do *not* find that branch under gpedit.msc. Are we using the
same versions of XP (Pro, SP3, workgroup) or comparing apples &
oranges ?

I am using Windows XP Professional Service Pack 3. From your
description of using the local policy editor (secpol.msc), the node does
exist because you mention it in the tree node to which you navigated.
So I have to suspect that in the group policy editor (gpedit.msc) that
you are under the wrong major tree branch; that is, you are under the
"User Configuration" branch instead of under the "Computer
Configuration" branch.

The Additional Rules node only exists if you have actually defined the
structure to list the rules. The install-time default has no such
"Additional Rules" subnode. That structure isn't required until needed.
Until then you won't find any subnodes under "Software Restriction
Policies". Right-click on "Software Restriction Policies" and use the
"Create new policies" context menu entry. Then you'll see the following
subnodes appear under "Software Restriction Policies":

Security Levels
Additional Rules

Since all policies are registry entries, you will find the SRP rules
created under:

HKCU\Software\Microsoft\Windows\CurrentVersion\Group Policy Objects
HKLM\SOFTWARE\Policies

Since you say you can see them using secpol.msc then they are there even
if you haven't yet updated the structure in gpedit.msc to show the
subnodes.

I defined hash based rules to block specific executables, path
rules wouldn't suit my situation. This is a difference, though
why would Windows ring bells on one kind of rules and not another
I can't fathom. Isn't there some registry setting governing the
popup behavior ?

Path rules are when you want to control execution of an executable file
that is in a particular location. For example, I created a Path rule
for Internet Explorer so it always runs under a LUA (limited user
account) token. That way, IE runs under a LUA token just as if I had
logged under a limited account which means privileges available to it
are reduced and the web browser is a safer process. However, there are
times when I must run IE without any restrictions. For example, IE must
run with admin privileges to use the Windows Update site, install
addons, line Adobe Flash Player, and so on. So I created a subfolder
named _noSRP under which I copied iexplore.exe (IE doesn't like its
program file renamed so that wasn't an option). Since the Path rule
works on the C:\Program Files\Internet Explorer copy of iexplore.exe,
the copy under the _noSRP folder won't get restricted. If I used a hash
rule, it wouldn't matter where was the file as it would always be
restricted under a LUA token and I could do WU or add-on updates.

The hash rule is used when it's possible the file could move around. A
hash is taken of the file's content and that hash value is used in the
SRP block rule. Alas, if the program ever gets updated then your hash
rule is no longer valid and you'll have to create another one for the
new version.

Of course no disagreement here. Obviously I too was trying to
prevent certain unwanted exe's from being run by background
processes which I need (...snipped more irrelevant arguing...)

Well, if I can't have the SRPs do their job silently, I'll use
other methods to prevent unwanted child processes from running.

The background starts of the blocked program don't result in popup
alerts about getting blocked by an SRP rule. Those background instances
were started as a child process by something else, like a startup item
or a scheduled event. It's only when YOU try to start the program that
you get alerted that it is blocked from running. If you defined the
block rule then you know that program won't run and you shouldn't be
trying to load it, anyway. If you defined the rule and someone else
tries to load the program, not doing anything (the user doesn't see the
program get loaded) would indicate to the user there was a problem and
not that the program wasn't allowed to run.

Those defining the block rules don't need the alerts but they they
shouldn't be running the blocked programs. Those that don't know the
programs are blocked really need to be told why the program won't load.
When you define an SRP rule, you don't get to specify against which
accounts they are applicable. SRPs are global across all accounts, even
admin-level account, and Windows is designed to be a multi-user
operating system, so the alerts are intended to give notice to those
that did NOT define the block rules using other accounts on that same
host. After all, along a similar vein, the IT folks don't need to be
warned that the programs they chose to block are getting blocked via
pushed policies in a domain. The alert is for the benefit of users
other than those who defined the SRP rules.

No, I know of know way that you or anyone else that attempts to run a
program that is blocked from being kept in the dark as to why the
program wasn't allowed to get loaded. A user trying to run a blocked
program (that won't load) gets notified about the block. Something else
that tries to load the same program does not show an alert but instead
gets recorded in the event logs.

If the point of defining an SRP block rule is to prevent execution of a
program by a *user*, why is that software installed that can never run?
In fact, I've read about setups where everything is blocked by default
and a list of authorized programs is whitelisted. That way, users
cannot go willy nilly installing software on their hosts, including
those that don't MSI and pollute the %userprofile% path where many
programs dump their executables because users have read, write, AND
execute privileges there. I don't know how you are managing the host(s)
on which you are defining SRP rules. They're really designed for use in
a domain environment where policies get pushed to the workstations.
They are usable in home setups (i.e., in workgroups) but to a somewhere
limited extent. I found them handy not to prevent software from running
that should've never been installed in the first place but instead to
prevent software that is wanted from running ancilliary programs that I
don't want them to run. After doing a registry hack to add Basic mode
instead of just Block or Allow modes, I can also decide which programs
will always run under Basic mode (i.e., under a LUA token), like web-
facing programs (web browser, e-mail client, etc). It really doesn't
make sense on a host that you personally manage to be blocking software
that you shouldn't have installed and don't want running there.

 

[Ninho]

Dear VanguardLH, your detailed explanations are much
appreciated.

However I'm not sure you read (or believed?) what I have been
trying to convey - possibly because of my English being not good
enough. For brevity and accurateness I'll state (repeat) the
main "facts of the case" - which you seemingly ignored :

= A background /program/ (antivirus), /not/ the user, tries to
start the banned executables from time to time, repeatedly.

= Whereupon each time, Windows SRP fires a beeping! message box
informing that program xxxx.exe has been prevented from running
by an administrator
:=( . Message boxes have to be manually closed - a double
aggravation when the machine is left unattended.


Any idea why our respective experiences differ, i.e. why /you/
do not see such message boxes from SRP ? A note : I (almost)
always am logged on to my NT based OSes as a "restricted user"
(using runas or Aaron Margosis's "make me admin" scripts for
administrative tasks). Might this be the reason ? I /don't know/
whether I would still get the popups were I logged on as local
admin.


You wrote : (....)

"It really doesn't make sense on a host that you personally
manage to be blocking software that you shouldn't have installed
and don't want running there."

But it /does/ make sense to block a piece of software, which I
do want running in the background, from launching a secondary
(and useless, just annoying) process which I'd rather /not/
have. I cannot simply delete the offending exe's for the main
program will notice them missing and redownload component on the
next opportunity (and I don't want to prevent the app from
accessing the net either, it does need to update its data).


Meanwhile FYI, I have applied a workaround - replaced offending
programs by a home brewed exe (a "new executable" NE that I
wrote years ago, which does nothing but return to caller
immediately). This is enough to trick the main program (although
in theory this approach might fail if the "father" expected and
checked for specific return codes from the child, or checked for
the child program's integrity - which it should, being this a
so-called antivirus).


Regards

 

[VanguardLH]

= A background /program/ (antivirus), /not/ the user, tries to
start the banned executables from time to time, repeatedly.

Scanning a file (query for its existence, opening it, reading it,
closing it) does not *run* a program file. If your anti-virus software
is running executable files that it finds then it is NOT an anti-virus
program but instead rogueware or malware. Something is very wrong with
your anti-virus software that it runs any executable file it finds.

What anti-virus software are you using?

= Whereupon each time, Windows SRP fires a beeping! message box
informing that program xxxx.exe has been prevented from running
by an administrator
:=( . Message boxes have to be manually closed - a double
aggravation when the machine is left unattended.

You need to get a real anti-virus program. I have never seen your
described behavior in McAfee, Norton/Symantec, Avira, Avast, NOD32,
BitDefender, Microsoft Defender or Security Essentials, or any other
anti-virus program that I've used or trialed. Scanning files doesn't
run them. SRPs do not block programs from reading the files. I can use
an SRP to block execution of a file but that doesn't prevent a different
program from reading that blocked file.

I block Apple's qttask.exe from running. That doesn't preclude their
Quicktime from trying to run it but that attempt will fail and gets
logged in the Application log seen in Event Viewer. I block Microsoft's
insistent need to run WISPTIS.exe program. Something always wants to
run that useless software (I don't have a pad and don't need their
pen&ink support) but it gets blocked from loading and I see lots of
entries in the event logs of something trying to run it. Pretty soon
I'm going to add Microsoft's stupid .Net font cache program to prevent
it from loading and staying loaded. Too bad the event logs for the SRP
blocks don't also log what process tried to run the blocked program.

Any idea why our respective experiences differ, i.e. why /you/
do not see such message boxes from SRP ? A note : I (almost)
always am logged on to my NT based OSes as a "restricted user"
(using runas or Aaron Margosis's "make me admin" scripts for
administrative tasks). Might this be the reason ? I /don't know/
whether I would still get the popups were I logged on as local
admin.

My anti-virus program (currently Avast but I've used Avira and MSE in
the past as well as Norton and McAfee) scanning those blocked files do
not try to run them. They just read them. So I don't get any popups
due to SRP rules on those files.

As a test, and in trying to start something that I defined on a SRP
blocked file, I created a scheduled event in Task Scheduler. I have an
SRP block rule on Apple's qttask.exe file. I added a scheduled event to
run qttask.exe a couple minutes later. I created the scheduled event
and it was configured to run under my account (which is in the
Administrators group). When the scheduled event ran, it failed with a
"Could not start" status and the log showed "Access is denied". There
was no SRP alert popup. Only if I double-click on the qttask.exe file
in Windows Explorer or use a command interpreter to run the program do I
get the SRP alert popup.

No anti-virus program should ever be loading executables if finds in
scanning your drives. Just imagine the problems you would have
regarding consumption of memory, paging file, and screen space it the AV
program ran every executable that it found. Something is very wrong
with your AV software.

 

[Ninho]

Ninho wrote:

Scanning a file (query for its existence, opening it, reading it,
closing it) does not *run* a program file.

VanguardLH : despite my efforts, I am starting to find it
painful to keep braking your constant efforts at answering
questions that are /not/ posed, and providing explanations that
are /not/ needed based on incorrect /assumptions/ you are making
..

If your anti-virus software
is running executable files that it finds then it is NOT an

anti-virus

It is trying to run /its/ files, of course, not random files;
some of which are not wanted (teasing-advertising for paid
versions).

What anti-virus software are you using?

Avira - free.

You need to get a real anti-virus program. I have never seen your
described behavior in McAfee, Norton/Symantec, Avira, Avast, NOD32,
BitDefender, Microsoft Defender or Security Essentials, or any other
anti-virus program that I've used or trialed.

Evidently your trial of Avira's has not been in depth - no
offence meant.

Now if you have something meaningful to add about my original
query, please be my guest. You didn't reply to this question
from my previous post, did you ? Copied below :

"Any idea why our respective experiences differ, i.e. why /you/
do not see such message boxes from SRP ? A note : I (almost)
always am logged on to my NT based OSes as a "restricted user"
(using runas or Aaron Margosis's "make me admin" scripts for
administrative tasks). Might this be the reason ? I /don't know/
whether I would still get the popups were I logged on as local
admin. "

 

[Char Jackson]

VanguardLH : despite my efforts, I am starting to find it
painful to keep braking your constant efforts at answering
questions that are /not/ posed, and providing explanations that
are /not/ needed based on incorrect /assumptions/ you are making
.

anti-virus

It is trying to run /its/ files, of course, not random files;
some of which are not wanted (teasing-advertising for paid
versions).

As I read your description of the issue, I thought to myself that that
sounds exactly like the free version of Avira and its daily nag to
upgrade.

Avira - free.

And what do you know, that's exactly what it is. In my case, I ran a
path-based SRP for over a year and never got a popup, only an event
written to the app log. These days I just let it fire off. In my case,
it fires at about 5 minutes after Noon every day, so I use it as a
reminder, of sorts.

 

[VanguardLH]

VanguardLH : despite my efforts, I am starting to find it
painful to keep braking your constant efforts at answering
questions that are /not/ posed, and providing explanations that
are /not/ needed based on incorrect /assumptions/ you are making
.

anti-virus

It is trying to run /its/ files, of course, not random files;
some of which are not wanted (teasing-advertising for paid
versions).


Avira - free.



Evidently your trial of Avira's has not been in depth - no
offence meant.

Now if you have something meaningful to add about my original
query, please be my guest. You didn't reply to this question
from my previous post, did you ? Copied below :

"Any idea why our respective experiences differ, i.e. why /you/
do not see such message boxes from SRP ? A note : I (almost)
always am logged on to my NT based OSes as a "restricted user"
(using runas or Aaron Margosis's "make me admin" scripts for
administrative tasks). Might this be the reason ? I /don't know/
whether I would still get the popups were I logged on as local
admin. "

You don't need to use SRPs to get rid of free Avira's annoying adware
popup window when it updates. Too bad you didn't ask about THIS problem
at the beginning instead of making everything so vague and claiming I
don't understand what you didn't explain.

Avira does NOT run executables that it scans. Obviously any program
will try to run its own ancilliary program - but then you decided to
hide your real intent until now. Next time be open about what you are
trying accomplish.

The following is my canned response on how to eliminate Avira's ad and
banner windows. One of those solutions is to use a SRP Path rule - and
it DOES work *without* any popups.

There are 2 "splash" screens in Avira's free (adware version) Antivir
product. One is the load-time adware banner and the other is the adware
popup during updates.

To remove the load-time adware splash screen:
- Run regedit.exe.
- Go to HKLM/Software/Microsoft/Windows/CurrentVersion/Run.
- Find the entry that loads the Avira UI program.
- At the end of the command, add "/nosplash" (sans quotes).

To eliminate the update-time adware screen, do ONE of the following:
- Rename the avnotify.exe file in Avira's installation folder. Rename
to something else, like avnotify.exx.
NOTE: It's possible this gets undone with a program update to Avira.
- Move avnotify.exe out of Avira's installation folder. Save it
elsewhere.
NOTE: A program update could also undo this action.
- Create a software restriction policy that prevents it from loading:
o Run the policy editor (gpedit.msc).
o Go to the following node in the tree list:
Computer Configuration
Windows Settings
Security Settings
Software Restriction Policies
Additional Rules
o Create a new Path policy. Navigate to and select the avnotify.exe
file. Select to "Disallow" this executable. This has the OS refuse
to load this program.

I use a policy. It is possible that a program update would replace the
avnotify.exe. So renaming it or moving it won't help because a new one
shows up. The policy doesn't care and will still block that file in
that path from running.

If you are using a Home edition of Windows XP/Vista/7, there is no
policy editor available. Those editions cannot participate in a domain
where policies get pushed. The policy editor is a glorified registry
editor that manages settings used to define policies. All policies are
defined by registry entries. However, key names and interdependencies
exist with path policies for allowing/disallowing files to execute
(i.e., there isn't just one registry entry that you can add).
Alternatively, you can still use a HIPS (host intrusion protection
system) enabled security product, like in some firewalls (e.g., Comodo
and OnlineArmor, which let you define application rules to prevent
execution of specified files.

 

[Czerno]

VanguardLH :

However savvy you are, also evidently you do not read my
postings fully.

You don't need to use SRPs to get rid of free Avira's annoying adware
popup window when it updates.

I am aware I do not /need/ SRP to this aim. In fact had you
/read/ my postings, you'd know I /have/ gotten rid of the
popups, my way.

Too bad you didn't ask about THIS problem

Too bad you're not even trying to answer THE original question -
which is WHY do SRPs pop up beeping windows here.

at the beginning instead of making everything so vague and claiming I
don't understand what you didn't explain.

I'm afraid you might NEVER understand. See above

Avira does NOT run executables that it scans. Obviously any program
will try to run its own ancilliary program - but then you decided to
hide your real intent until now.

I didn't hide anything from you. I wished - still wish - to know
how to suppress the beeping/popups from SRP which I have
experienced (and you presumably haven't). This is nothing to do
with Avira in particular...

Next time be open about what you are
trying accomplish.

I couldn't be more open !

The following is my canned response on how to eliminate Avira's ad and
banner windows. One of those solutions is to use a SRP Path rule - and
it DOES work *without* any popups.

I'm afraid it doesn't. Not here !

(snipping the rest; feel free to open another thread if you'd
want to discuss your experience with suppressing popups from
Avira)

 

[Ninho]

And what do you know, that's exactly what it is. In my case, I ran a
path-based SRP for over a year and never got a popup, only an event
written to the app log.

No popups ? Interesting. Are you logged in as an administrator ?

These days I just let it fire off. In my case,
it fires at about 5 minutes after Noon every day, so I use it as a
reminder, of sorts.

Aha, lunch time! Well, that's a point to consider...

Thx

 

[Char Jackson]

No popups ? Interesting. Are you logged in as an administrator ?

At the time, yes, I was running as a member of the administrator group
and the OS was XP Pro SP3. I have since moved to Win 7.

Aha, lunch time! Well, that's a point to consider...

Exactly. I have another task that emails some log files to me every
day at 3PM, so I also use that as a reminder of what time it is.
Sometimes I get engrossed in something and lose track of the time.

 

[Ninho]

VanguardLH :

However savvy you are, also evidently you do not read my
postings fully.

You don't need to use SRPs to get rid of free Avira's annoying adware
popup window when it updates.

I am aware I do not /need/ SRP to this aim. In fact had you
/read/ my postings, you'd know I /have/ gotten rid of the
popups, my way.

Too bad you didn't ask about THIS problem

Too bad you're not even trying to answer THE original question -
which is WHY do SRPs pop up beeping windows here.

at the beginning instead of making everything so vague and claiming I
don't understand what you didn't explain.

I'm afraid you might NEVER understand. See above

Avira does NOT run executables that it scans. Obviously any program
will try to run its own ancilliary program - but then you decided to
hide your real intent until now.

I didn't hide anything from you. I wished - still wish - to know
how to suppress the beeping/popups from SRP which I have
experienced (and you presumably haven't). This is nothing to do
with Avira in particular...

Next time be open about what you are trying accomplish.

I couldn't be more open !

The following is my canned response on how to eliminate Avira's ad
and banner windows. One of those solutions is to use a SRP Path rule
- and it DOES work *without* any popups.

I'm afraid it doesn't. Not here !

(snipping the rest; feel free to open another thread if you'd
want to discuss your experience with suppressing popups from
Avira)

 

[VanguardLH]

Czerno wrote:
<snipped - see other identical reply under other nym of Ninho>

Please pick and stay with one nym. Nymshifting is frowned upon.

 

[VanguardLH]

A significant difference that I see between how we use our hosts is that
you say that you login under a restricted (limited) account whereas I
log under an admin-level account (one in the Administrators group).
While you use the LUA account to restrict the privileges on the programs
you run, I login under an admin account and use SRPs to reduce
privileges on some programs (e.g., web-facing apps). So perhaps I don't
see the alert popups for SRP rules because I'm currently logged under an
admin account and you see them because you are logged under a limited
account.

As a test, create and login under an admin-level account and get the SRP
blocked programs to get loaded by something other than yourself, like
create a scheduled event in Task Scheduler that fires in a couple
minutes (and not have you right-click and use Run on the task). I
suppose you could also do whatever you are doing, like running an AV
scan on your host to see if the adware popup programs (avnotify.exe) get
blocked without the annoying SRP alert popup.

Since admins are those that can define SRP rules, not limited users, it
makes sense that the admins don't see the SRP alerts for rules they
defined. Limited users cannot define SRP rules and probably why they
always get alerted about the restriction.

You are also defining hash rules instead of path rules. If the above
test of checking if the SRP popups only appear for non-admin accounts
then see if using a path rule eliminates the popups.

If logging on under an admin-level account gets rid of the annoying SRP
alerts but you still want to use a limited account as your primary usage
of Windows then SRPs may not be the best method to eliminate the
software that you want from executing processes that you don't want.
For the Avira situation, and opposed to your claim that I didn't fully
trial that product, I've already mentioned other non-SRP methods of
eliminating Avira's startup banner and their adware popup during an
update. For other programs not yet identified where you want some part
of it not to run, those would have to be addressed separately.

Different tricks for different software assuming a non-SRP method is
available. For example, there are many security products that include
HIPS (host intrusion protection system) functions where you can decide
what will and won't run. The HIPS feature in Comodo Firewall and Online
Armor can let you restrict what can and cannot run if you up their
security settings; however, that means you will need to answer a lot of
prompts when you first start using them to decide what you let run and
what you will block.

In the particular case you cited of blocking Avira from showing its
adware popup window during an update, are you using a hash or path rule?
For applications that get updated, the hash rule can become obsolete on
the next program update but a path rule would still apply.

 

[Ninho]

A significant difference that I see between how we use our hosts is that
you say that you login under a restricted (limited) account whereas I
log under an admin-level account
(....) So perhaps I don't
see the alert popups for SRP rules because I'm currently logged under an
admin account and you see them because you are logged under a limited
account.

This has been my guess too. Haven't had time yet to check and verify that
it was indeed the case.

As a test, create and login under an admin-level account and get the SRP
blocked programs to get loaded by something other than yourself,

You are also defining hash rules instead of path rules. If the above
test of checking if the SRP popups only appear for non-admin accounts
then see if using a path rule eliminates the popups.

Or you might wish to test yourself - aren't you curious ? ;=)

If logging on under an admin-level account gets rid of the annoying SRP
alerts but you still want to use a limited account as your primary usage
of Windows then SRPs may not be the best method to eliminate the
software that you want from executing processes that you don't want.
Agreed

In the particular case you cited of blocking Avira from showing its
adware popup window during an update, are you using a hash or path

rule?

I was using a hash based rule.

For applications that get updated, the hash rule can become obsolete on
the next program update but a path rule would still apply.

Understood. Anyway, I'm not insisting on using SRP rules since they do
not seem the best fit in my configuration. Rather, I'm going back to good
old proven methods like I did in Windows 2000 till I reluctantly switched
to XP :=)

 

[Ninho]

Ninho wrote: =)

I'm not the one reporting a "problem". No, sorry, I'm not curious.
Works for me (no SRP alerts) in my current usage. I've got way to many
other more important tasks to complete on my computer and away from it.
I come here during my idle moments.

Understood. I /am/ curious, but, like you and (?) everybody
else, I have to prioritise tasks.