Discussion in 'other anti-malware software' started by Jryder54, Oct 29, 2013.
Did it break anything. If no, you can ignore it.
Sometimes I get this message:
Nobody from Rambox get this, so I don't know if this is related with AppGuard...
Forgot. How many PC's can the v4 with lifetime license be installed onto?
only one normally.
It might be valid on 3 PC's, it depends.
I have bought one several years ago and it works for 3 PC's.
in fact , it is a bit more complicated than that, you have a set number of activation, and if you format your system without uninstalling AG, then reinstalling it, you will lose 1 activation.
You can check your status here https://license.blueridge.com/solo/customers/LicenseHistory.aspx
mood and guest, thanks. I had 3 left.
First verify with Rambox support if it is a known issue. Don't be surprised if they do not know or cannot provide a definitive answer.
If you wish, you can exclude the Rambox file path in AppData from User Space. Add it to the list and set it to NO and leave it that way for at least a couple of weeks.
I already did it, but for now it's an unknown issue:
I excluded the "C:\Users\x\AppData\Local\Rambox\" from User Space, but still happens...
It seems it isn't AppGuard.
I did this now, and will see if I still have the issue.
Thanks a lot!
For the sake of thoroughness, please set AppGuard to OFF and disable the 20 min timeout in the main GUI. That will disable AppGuard permanently.
Zeroing-in on these kinds of errors is a process of elimination.
In the past I could have AG on Locked Down Mode, or Protected Mode, and Windows could still update. That's no longer the case. I just discovered that AG blocked Microsoft .NET Framework 4.7 Update. It was blocked twice by AG, and as soon as I disabled AG the installation completed without issue.
I suspect that AG has been blocking update components in the recent past that has lead to update problems. I had seen blocked events in my Activity report, and I assumed the blocked events had not caused any problems. I guess I was wrong because I was unable to install the following update below after recent blocked events in Activity Report. I had to roll my machine back because my Windows installation had become corrupted. After disabling AG all updates installed without any problems.
Windows 10 Creators Update Privacy Settings for x64-based Systems (KB4013214)
Also, AG is constantly blocking the following from Microsoft Office 2016 from the screen shot. Microsoft error reporting immediately request to dial out each time AG blocks this. I don't know any easy way of allowing it without compromising security. I really wish the new owners of AG would add hash support to facilitate whitelisting when it's not practical to do with SRP. Hash support has been requested in the past, and BRN either did not have the budget to allow for development, or it was low on the list of priorities.
Would you please post the block events from Activity Report here ?
Once in a while I will see rundll32 blocked from writing to an xml in C:\Windows\Temp during Windows Update. Despite this block event, I have observed no Windows Update blocks up to this point on Windows 10 Home\Pro using both regular updates and the slow ring.
I am not saying you are not having an issue or that AppGuard is not causing it. What I am saying is that without block events recorded specifically in the Activity Report, there is no data to work with.
I am particularly keen on any potential issues between AppGuard and Windows Update. Therefore, I always keep an open eye for problems during testing. The most useful infos are the events in the Activity Report - including both before and after the block event in question.
Would you please post the block events from Activity Report here ?
KB4013214 is the preparation tool for upgrade from Anniversary to Creator's Update. UPX = Upgrade and Privacy Experience utility.
I have 12 Windows test systems and not seen any problematic block events during Windows Updates on W10 both standard and slow rings. I am not saying you are not having an issue. What I am saying is that without block events recorded specifically in the Activity Report, there is no data to work with.
In Locked Down mode, AppGuard denies TrustedInstaller from accessing digitally signed *.msi from publishers on the TPL - even in System Space.
We went over this in regards to the GoogleUpdateHelper.msi about 6 months ago.
Excluding it in User Space NO will not allow TrustedInstaller to access it.
You must lower protection to Protected mode.
No. It's not a priority. At some point in the future the request will be considered.
The way it works at this time is that all focus is on Enterprise at this time and for the forseeable future. Once things get sorted out with Enterprise, some things trickle down - when there is time available - to AppGuard consumer.
A minor release of AppGuard consumer might be released within the coming months. As it stands today, there is no ETA for it.
The transition to the new company is going to take much longer than anyone not familiar with what is involved in a company transition of this scope suspects. It involves not only the transition logistics itself, but also hiring new team members. In other words, at this time we are still a very small team. And there are thousands of details that must be attended to in between. Things are sorted out as we go, with all of it being very time intensive.
How did the .NET Framework 4.7 update hit your system ?
Was it a part of regular or slow ring Windows Updates ?
Or did you download the .NET Framework 4.7 installer and run it ?
During actual use of various Windows versions, I have only seen .NET Framework 4.7 made available to Server 2012 R2 via Windows Updates.
Sorry, I don't have the blocked events now. I forgot to save them to an external drive before reformatting
The best I can tell is it failed due to corruption caused by some other update being blocked by AG. Maybe the Microsoft .Net Framework 4.7 update. It installed without issue after I disabled AG to allow the .Net Framework to install. The .Net Framework was unable to install until I disabled AG.
I will try excluding Trusted Installer from the UserSpace, and see if that helps with the problem, but it already can't access it in Locked Down Mode so it may not make any difference since I always operate in Locked Down Mode.
To solve the issue, you have to temporarily lower protection to Protected mode.
If you move the *.msi from System Space to User Space and set it to NO, then InstallGuard will definitely block access to it by TrustedInstaller - because it is in User Space and the setting for it (YES or NO) does not matter.
It was delivered by regular updates through Windows updates. In other words it was automatic with Windows default update settings. Maybe it's pat of Microsoft Office 2016 365 ProPlus. I work with databases a lot using Microsoft Access.
I thought you was saying to move TrustedInstaller to the UserSpace. It is located in the System Space at this path. C:\Windows\servicing\TrustedInstaller.exe. Do you mean to move msiexec.exe to the UserSpace, and set it to NO? It's located here C:\Windows\System32\msiexec.exe
Don't move anything to User Space. It will not fix the issue. Sorry for the confusion.
You have to lower protection temporarily to Protected mode and then run the Microsoft Office tasks from Task Scheduler.
I have a note about InstallGuard blocking TrustedInstaller access to any *.msi located in System Space. The InstallGuard policy needs to be revised to resolve this issue.
I have Microsoft Office installed on all the test systems.
When did (time frame) did .NET Framework hit your system - recently, within the past few weeks ?
I think I first saw it this month on patch Tuesday, but i'm not sure. That would have been June 13th. I'm really not sure though.
Ok, thanks for clearing that up. I thought that was an odd way to resolve the problem i'm having.
Would you please go into the Windows Update history and locate the update ?
Would you please provide the KB # along with the date of installation - a screenshot would work.
Also, when you upgraded from W7 to 10, did you already have general .NET Framework versions 4.0, 4.5, and 4.6 installed ?
Microsoft is throttling the distribution of .NET Framework 4.7 via Windows Updates -- and increasing telemetry because they are using peoples' systems as guinea pigs to flesh-out problems with .NET Framework 4.7.
They made a statement on June 13: https://blogs.msdn.microsoft.com/do...ilable-on-windows-update-wsus-and-mu-catalog/
I still need to look into it as a potential problem and the infos I requested immediately above would be quite helpful.
Plus, here is additional infos from Microsoft:
On Windows 10 Anniversary Update and Windows Server 2016 you can find this as Update for Microsoft Windows under Installed Updates in Control Panel.
This version of the .NET Framework runs side-by-side with the .NET Framework 3.5 SP1 and earlier versions, but performs an in-place update for the .NET Framework 4, .NET Framework 4.5, .NET Framework 4.5.1, .NET Framework 4.5.2, .NET Framework 4.6, .NET Framework 4.6.1 and .NET Framework 4.6.2. For important information about this release, see the Known issues for the .NET Framework 4.7 .
I have them now, so isn't reg.exe...