Outpost Firewall Pro 7.1

This probably sounds like a peculiar question, but is there a setting somewhere in OFP 7.1 to keep it from starting when Windows starts -- but still lets you manually start it sometime after that?

 

Yes, you can control Startup in Settings > General. Set it to disable and OP won't start. You'll have to do it manually when you decide.

Is there any particular reason you want to lose protection when the machine is booting?

 

Thanks, Manny. I thought that might be it, but wasn't sure.

I just wanted to put it under the supervision of a startup delayer to delay its startup position a little. Right now it ants to load right away and it seemed like it might be conflicting with another startup item. However, to put it in the startup delayer, I need to stop it from loading on its own in the normal startup menu.

So, if I disable it and later decide to let it load on it own (not in the startup delayer), is it simply a matter of going back in to OP and changing the setting back to "normal"?

 

Why delay the startup of a security program? Do you want malware to run before it?

 

You can certainly put the setting back any time you wish.

However, the firewall service [acs.exe] is among the first thing to load -the interface loads much later - so as to provide you protection before the network loads. Defeating that is a bad idea. While it's possible there is an interference with something else it's best to work on fixing that problem rather than not starting the firewall which leaves you vulnerable. At the very least you should turn on Windows firewall so that can provide protection.

What exactly is the problem you are having? Perhaps we can help fix that.

 

manny, i don't think he actually wants to stop the firewall itself, just the GUI.

i use a startup delayer (Chameleon) to do what i think you want.

right after boot, and on my pc, the second part of the system to load is the sandbox driver ('sandbox64.sys in my case) that agnitum adds as the initial protection, all traffic goes thru the sandbox for testing before being allowed access to the system. as no filtering has yet been loaded, anything trying to get in can't get out.

the firewall's port driver 'afw.sys' is loaded shortly after as part of the networking systems. again, nothing can get thru, it may have an inlet, but as yet no outlet.

the acs.exe service loads later, but still before logon. it drives the filters, the anti-malware system, and the rest of the protection. at this point outpost is operational and will be protecting your system. at this point the total outpost system is active, you can't see it or interact with it yourself tho, as you are not logged in.

when you log in, the GUI (graphic user interface), OP_MON.exe is started. it is not a necessary part of the system, as i said, you are protected before it runs. the gui is what shows you op's current state, and allows you to change settings, view logs, edit network and other rules, etc.

in fact, you can set OP startup to 'background' and never run the gui part. this is useful for non-admin users as then they cannot change settings the admins don't want changed in a connection sharing and/or multi-user pc. they don't get a tray icon then either. depending on how much you trust them, you may allow them to run the gui when they need to, or not. that's up to you. don't allow them execute permissions if you don't want them to.

if you are a single user, a power user /admin, you can just run with startup set to normal, windows will run the gui when it feels like it, & it will show a tray icon at some point, not necessarily in the order you'd like as it's based on the whims of how windows starts stuff, which side of the power cycle you powered on, how high the creek rose last night, and what color socks o'bama (or is it al gore) put on this morning.

anyhow, back to start delayer.

to control what order stuff is run, to avoid any conflicting competition for resources, and make for a smoother startup, some people run a startup delayer program. i use chameleon startup manager, as it allows me to control the startup better than most similar programs. i set it to provide a three second delay between launching programs, and set the list order in which it does this. alternately i can set the list order and tell it not to launch the next program in the list till the previous one is finished loading (or stops).

anyhow, i set outpost's GUI, OP_mon.exe to start first so the tray icon appears next to my wireless network's tray icon.

outpost itself is set to start in background mode (no tray icon) to keep the gui from starting when windows feels like it instead of when I feel like it.


just for interest, my load order (from sys internals 'loadord.exe')

 

That could certainly be the case Wayne.

As Wayne explained in detail there are two basic parts to the firewall. The hooks and service which loads very early in the boot process before anything has a chance to get out of your machine and then the user interface which loads some time after you sign on as the user. Using a startup delayer for starting up the user interface would pose no problem because the interface is just a convenience and not needed. If you did it my way by putting the firewall to disabled then none of the services start at all and all protection is lost. That's the dangerous way but does makes sure no firewall component is interfering with anything else starting up.

Setting the startup mode to background and then starting up the user interface later, either manually or with a startup delayer, is certainly the safe way to go and the first thing to try. The services start and provide protection but the user interface waits around until you are ready. This way you continue to have protection and can determine if starting the user interface is where the problem lies. I agree with Wayne.

 

Thanks, guys, for the detailed explanation -- this helps a lot.