Since the application does not run with a normal extension it will by default block the updaters communications, I had to use a program called tcpview to find the path of the program, and allow it through the XP firewall. Now the updates work, but it will never ask for programs which don’t have a default extension for a normal executable.
Other firewalls will prompt for this action as it is seen as an executable, however just making it an official .exe in an update would be the easiest thing to do for those of your customers who will upgrade to XP SP2. I’m sure some other software firewalls might have this issue also, but that is just a guess.
Thank you for your time, and the effort into your programs.
Yes its RC2, however it doesn’t see it as an applicaiton for some reason, so it will not allow the responses to its communications inbound. Sorry I wasn’t clear before, so its blocking its inbound communications/responses.
ICF really has no outbound protection, except some icmp control.
I guess this must’ve changed in the RC2 (we haven’t seen this problem before). Thanks for notifying us about this… Now I wonder what we can do about that… ???
Well for what its worth, I’m in the process of letting Microsoft know as this likely extends to any non-standard application, and you know that some installs use .tmp files as executables at times so I could see that as an issue as well.
Its up to your team, but make sure all your executable have standard extensions? I thought I saw a thread where SyGate had a problem with the updater also, but I don’t really know as I didn’t fully read the thread.
An executable may have any extension if it’s spawned using the system’s CreateProcess call. Only shell has some restrictions when it spawns programs using ShellExecute.
I really love these kinds of senseless assumptions in products from big companies, causing unnecessary troubles for smaller ISVs. >:(
Hey VLK,
It’s radicalb21. I can say the same thing as my desktop is under settings update connections settings i have the following block checked that my computer is permantly connected to the internet. Prior to installing XP SP2 RC2 my system would update automatic when the new VPS was released but now mthat function is blocked. However I am able to update manually without any problem. I hope this helps. If you need me to test anything to try and get this to work I have been beta testing with Microsoft for a number of years and maybe I might be able to help.
This is the first program I have come across that I have noticed that its communications/responses were blocked by this inbound firewall. For some reason it was not being detected as a program making outbound connections so it would allow the inbound responses, and the one thing that has stuck out is the fact it does not run a normal executable extension. I know the app is seen fine in task manager so I’m still chalking this one up to a bug, but that is the only thing wrong I can find with the program.
From what I’ve been hearing for quite a while, I wouldn’t be at all surprised to see one heck of a lot of XP users disable the ICF and use something else once the “final” SP2 comes out. There seems to be very widespread agreement that it’s just about the worst firewall anyone’s seen yet.
It protects basic users who don’t want to run a firewall, but with the addition of application permissions people can easily allow their programs that act like servers now. At least this way with very little work they can still be protected inbound, and not have to deal with a more complex firewall if they don’t want to. However I do agree it will not be used by most users.
Cool, so Sygate has not problem, but one thing I noticed before is other firewalls usually get the traffic before ICF does.
I ran the previous build with a software firewall also, and it was catching all the traffic before the XP firewall. I’ve also noticed that when one firewall permits it, its already being allowed, and when one allows it other software firewalls might be powerless to stop it. I’ve seen this happen more than once as one firewall allowed it, the second one was set to stop it, but it still got through as it was allowed by the first one.
Anyway that is a theory based on experience using other software firewalls.
A way to verify this easily would be to have a system with no additional firewall installed, and only use the xp sp2 firewall. I admit I’m running with network, and connection monitors all the time right now as I don’t fully trust inbound protection only. However I’m using common sense, and software which I know as more secure like Mozilla Firefox since I don’t trust IE to be secure even with all its features disabled.
I have an alterative theory. It’s not caused by the .setup extension but rather by the fact that the setup is executed in the context of a system service. As a result, manual updates work (these are run in context of the active user [provided he/she is an administrator]) but do NOT work in the auto-mode (launched from the service)…
I can confirm this problem, running XP.Pro.SP2.2149. And I am pretty sure your theory is correct.
Also, avast! appears to not being the only av having problems with auto updating virus definitions: On the beta newsgroups people post about having problems wit Norton LiveUpdate.
I’m sure you had this resource available, if not greater access, but here is a site to check out. So far MS has made the main RC1, and RC2 builds availble to the public. The minor builds are only availble to offical beta testers. http://www.microsoft.com/technet/prodtechnol/winxppro/sp2preview.mspx
