AppGuard 4.x 32/64 Bit - Releases

I will check the Windows system log.

 

May be you want to check this?

C:\ProgramData\Blue Ridge Networks\AppGuard\appguardsetup_selfupdate.log

 

Ok, thank you! I will check now.

 

I too have system restore disabled and the auto-update at the Medium protection level worked perfectly for me. I agree that a progress bar would be useful. I found myself sitting there, not sure whether the update had failed or was still in progress. Task manager CPU activity provided the best indication that the update was still in progress, so I waited until it had successfully completed.

 

Same here.

 

Your right. I have the same event in my update log that you have. The last events in the update log was the system restore point. I just wish I knew about the update log when I sent my bug report. I will send it to them now.

InstallShield 21:59:17: Extracting support file ISBEWX64.exe to C:\Windows\TEMP\{8C659D33-ED52-431B-9F1D-FE6DB2772134}\ISBEW64.exe
InstallShield 21:59:18: Setting script cmdline...
InstallShield 21:59:18: ProductCode is {B18537F1-B130-4C4B-A606-01128D45907E}
InstallShield 21:59:18: Initializing Engine
InstallShield 21:59:18: Done Initializing...
InstallShield 21:59:18: Registering Msi Server...
InstallShield 21:59:18: Invoking script function CreateRestorePoint
1: Creating system restore point 'Blue Ridge Networks AppGuard 4.1.41.2 Install'

 

Hopefully it helps in their investigation.

 

Hello,

I believe that if you are on Windows 7 or 8 (probably Vista but cannot test here) with system restore turned off, the auto-update will fail. However, for some reason it does not fail (update finishes successfully) on XP with system restore off...

 

I just sent them the log file from the auto update feature. They also have the debug view log I sent them earlier. I think they will have everything they need to fix the problem. I hope so anyways. I will be out of town tomorrow so I probably want be back until Saturday, or Sunday.

 

That's exactly the way I felt except the update actually failed.

 

Yes, I think the reason it worked for me with system restore turned off is that I'm on Windows XP, not Windows 7 or 8.

 

+1 here. Windows 7 with SR turned off.

 

Even after reboot? You should have seen a toaster message indicating that a reboot was necessary.

 

My mistake. The new link is https://blueridgenetworks.s3.amazonaws.com/AppGuardSetup.exe

 

Windows 8.1 64 bit:
AppGuard stays a long time busy with updating,with a warning that I may not change the protection level...and if it finally goes away,I can't move the protection level slider anymore....
after a reboot,this cyclus starts all over when the program informs me about the new update.
Barb,can you please pm me the link for v 4.41 so that I can manually update??

Edit:just saw that you posted it ....THX

 

It stated boot was necessary in the toaster message. I rebooted and still 4.1.41.0.

Whenever I try to update now, AppGuard tells me I'm using the latest version.

 

Suggestion:

c:\$recycle.bin\ should be listed with read/write under guarded apps \ folders by default. Otherwise guarded apps can't move anything to the recycle bin.

 

I'm getting ready to leave for the weekend, but I wanted to give you guys a quick update on one of the problems I discovered. I found an itunes installer that is able to spawn a process against AG 4.1, and then AG kills it like within a second. The itunes installer is not able to spawn a process against AG 4, and no other executable I have test against AG 4 has been able to spawn a process against AG 4. Well, it tuns out that it has something to do with that second warning box 4.1 gives you when an executions has been blocked. If I tick not to receive that second warning box then AG prevents the itunes installer from spawning a process, but as long as I allow the second warning box itunes is able to spawn a process each time. AG does kill the process, but it takes it about a second. The last time I tested I removed all traces of AG before installing 4.1 except for the legacy registry keys. I thought maybe this was being causes by the old policy file not updating correctly, but I guess I was wrong. It seems to be specific with 4.1. I will look into it more when I get back. Maybe BRN can look at the code that related to the second warning box since if I tick not to see it again then AG prevents the itunes installer from spawning a process. I only tested with a handful of installers so there may be other executables able to spawn a process. I was only using simple .exe installers, and nothing designed to bypass security applications. If others cannot reproduce this when I get back then I will try it on another Windows 7X64 machine to see if I get the same result. I have to run. Everyone have a great weekend!

 

I am running AppGuard 4.1 beta on Win7 Pro x64 and Win8.1 Pro x64.

I installed the beta 6 days ago on the Win8.1 machine and it did ask me today if I wanted to update after booting. I allowed the update and about 4 minutes later, I received the notice it was updating. I then rebooted and the AppGuard about lists 4.1.41.0 but the Programs and Features in Control Panel lists version of 4.1.41.2 Seems the about and Programs and Features are checking different files?

I installed Appguard beta 4.1.40.2 on the Win7 machine which went fine. It would be nice if the installation checked for a newer version before installing. Upon reboot it did not ask to update so I checked manually and it told me about the update. I agreed to the update and after 2 minutes it began the update. I then rebooted and the AppGuard about shows 4.1.41.0. The Program and Features shows 4.1.41.2, same as Win8.1.

Neither of these systems ever had Appguard installed previously. I am running both systems on the 10-day trial.

 

Wow, good find. I'll get our test department to look into it. The added message box *should* not cause that (scratching my head).

 

I brought this up to our system architect and we agree. Trouble is that one of our previous developers objected to doing this in the past. We're trying to find out what his objection was - he was exceptionally talented and he must have had a good reason. I've tested this policy addition (I also added c:\$recycle.bin to my user-space to prevent any launches as well) and have no issues.

 

It's functioning as designed (maybe poorly designed I'll grant you). The Control Panel uses the version of the Install Package, while the program uses the version of its own executable. We use the first 3 numbers of the version to indicate when there is a change in the main binaries (i.e. AppGuardGUI.exe or AppGuardAgent.exe). If the Install Package changes for some reason (in this case the EULA was updated between 4.1.41.1 and 4.1.41.2), we bump up the last number. To be more consistent, we should probably pull the version information we use in the about box from the same place that the control panel is, but that is a low priority for now.

 

See my note immediately above. 4.1.41.0 is the latest version of the binary. 4.1.41.2 is the latest version of the Installer. Since this is at least the third time I've explained this on this board (I know this has come up previously), I have to rethink my statement about this change being a low priority. It shouldn't be rocket science to do, and it seems to cause confusion.

Update: After reviewing the previous page of posts, I see that it has caused lots of confusion. I'll see what I can do to get this change in sooner than later (especially if it saves me some work in the long run).

 

Do you know if you have System Restore off?

 

Good idea. We should have thought of that ourselves. Will add to candidate features for the next release (4.2?).