AppGuard 4.x 32/64 Bit - Releases

Can you tell me how I do that? Add Heimdal Pro to power apps?

 

Customize... - Advanced - Power Applications - Add ...
Now add the Heimdal-Executable

 

I thought I would be able to tell more by looking at the message info, but that was not much help. Are you very familiar with Process Explorer? https://technet.microsoft.com/en-us/sysinternals/processexplorer.aspx If you know how to configure Process Explorer to show the command lines for processes then I think it will show you the parent for netsh.exe. In other words, it will show you what is using netsh.exe After you install Process Explorer, go under view, then choose select colums, and make sure "command Line" is checked under Process Image. Don't forget to click on "OK" to save the settings after selecting "Command Line".

Look in the image below how I was able to look at the command line column to determine that Eset was the parent process for rundll32.exe. I would try that to see if it shows exactly what is spawning netsh.exe To make it quicker, disable AG for now so you don't have to configure AG to allow Process Explorer. If you want to continue using Process Explorer install it in the Program Files Directory, and make it a Power App. If you need anymore help then just let us know.

Edited 5/16 @ 9:55

Btw.. you can do the same thing with Process Hacker, and other Process Viewers. Process Hacker may be easier for you to install, and setup than Process Explorer. To see the Command Line for netsh.exe using Process Hacker, just double click on netsh.exe from the process viewer sceen, and it will show the Command Line for netsh.exe under the "General" tab.

 

@boredog Try this.
After your post I also noticed many netsh blocks to the registry, preceded by a Heimdal-related entry which could be a clue.
Adding the Heimdal executable(s) to Power Applications seems to have 'solved' that (and hopefully some funnies I have been experiencing with Heimdal also, we'll see).

 

I'm always amazed how people on wilders can defend a software.
OFF must not block anything. If you turn the light OFF, there is no light.

Also it's been years since I reported protection level switching bug and you still say its not a bug.

 

paulderdash:cutting edge :mood:
Yes I have used process explorer before MS acquired it but don't see ant thing strange there.
Am attaching a screenie of the EXE's that Heimdal uses. Should I add all of them to the power APPS? I hope this is not a Heidmal secret of how there internet filter works? There rep seems to be out doing her yoga again and not responsive here. Maybe she is busy fighting off all those Vampires in Romania ? LAst timer Andra was here was over a month ago

 

The executable that is responsible for modifying the registry has to be added but in the previous screenshots it isn't clear.
Try to add all 4 executables to Power Apps.

 

I'm not defending AG, but there is a bug in AG's logging. It happens especially when the same thing is blocked several times in a row. Some things that are blocked by AG will not show up in the log until like a minute, or so after they have been blocked. I looked at the image you posted, and it looks like that bug could explain the block showing in the image you posted since the autorun.inf had just been blocked several times in a row before you disabled AG. Have you been able to verify that AG is blocking what it is reporting after AG has been disabled? The logging bug is a very prevalent bug since several users have reported it here. I can easily reproduce the bug on my own machines.

 

Paulderdash:

I added all Heidmals exe's tp power apps and all those reports are gone. Thanks. I thought it was something like that because of the way Heidmal works. Now I only have a few blocks. Most likely another security program

 

I re-reported this bug to BRN.

 

I re-reported this bug to BRN.

 

Ah ok, my bad. Didn't catch AG was OFF as per the screenshot, so yes it's a bug as reported before.

 

Unfortunately, after each new release one has to check to see if bugs are actually fixed. If they are not, then they should be re-reported.

Lots of bugs get reported on this thread and Barb never sees them; bugs should be reported directly to BRN via support page.

Plus, I think BRN has some difficulties in keeping track of all the reported bugs -- so it is good to remind once in a while.

 

I reported the logging bug about 3-4 weeks ago. I thought AG was blocking executions after shutting AG down, but when I tested further I saw the bug actually was in the logging module. AG had blocked some things prior to me disabling AG, and they were not logged until after I shut down AG. Someone else recently reported the same behavior in the thread, and 2 other users reported this to me by pm. Are you sure the bug is not in the logging module?

 

No. I just pointed Barb to the auto.inf block thread posted here.

 

The screenshot of the auto.inf being logged as blocked after AG had been shut down shows the block occurred about 1 1/2 minutes after AG had been shut down. AG had previously blocked auto.inf several times in a row, and every time AG blocks the same thing multiple times in a row on my machines the last few blocked events are not recorded to the log until a minute, or so after they occur. I'm not saying this is the case with everyone, but I think the possibility needs to be considered. Even if the bug happens to be in the logging in only some of the reported cases it needs to be fixed because it is causing confusion, and damaging the trust customers have in AG at the very least.

 

I saw this logging-bug yesterday (again, and again ...)
Something was blocked, i turned off the protection and 1-2 minutes later there was an additional entry in the Activity Report. This is a little bit irritating

 

Yeah, well, this sort of issue is nothing but an annoyance and causes needless user confusion.

Keep reporting it to BRN support until it gets fixed. I think sometimes that they lose track of reported bugs...

 

If I want to make a registry change, do I have to set AppGuard to install mode?

Thanks

 

No. Only if a Guarded App wants to modify the registry you have to switch to install mode.

But AppGuard doesn't protect the whole registry, only parts of it:

#4104

 

Ok thank you Mood. I installed an App that turned off my Windows Defender and not sure which one. So tried to make a registry change to turn it back on and was unsuccessful. Problem is I did set AppGuard to install mode before installing the program that disabled defender. I should have had Quietzone active I guess. At this point I do not want to do a restore of my last Image because I paid the 60 bucks for the program and did not make another image after.

 

But it can happen that something is blocked, even in Install Mode. To be on the safe side, turn AG off before installing something.

 

I've always toggled to Off Mode when running installers. Once happened to me, I don't recall how,when or what, that Install Mode blocked something. Is not the installer had malware or something, it just violated some AppGuard's policies.

 

In Install Mode, if an installer uses (calls) a Guarded App, then I suspect AppGuard will sometimes block the actions of the Guarded App if it attempts to modify protected objects.

However, I cannot confirm this officially. BRN states that cannot replicate.

I have seen block events while in Install Mode that should not have taken place -- like writes to Tasks (which is in User Space\*.job files).

There is no rhyme or reason to it. Sometimes it is a one-off, random event that I cannot make heads or tails of it.

Despite this, I have only seen this happen when installing an app with AppGuard in Install Mode. So, I suspect, the issue is specific to installers -- and not program updates.

Not sure... it's one of those "flaky" issues that is hard to pin down -- mostly, because it is difficult to replicate.

 

Does anyone has both Rollback RX and latest beta version of Appguard installed?

if yes, can you guard (portable) softwares located on another partition without any errors message/issues?