Administrator cannot update [Resolved]

Discontinued Products Comodo BOClean Anti-Malware
#1

v4.23 (and v4.22) Win2K + NOD32 + SpywareBlaster+Sygate v5.5
BOClean announces:

“ERROR!!! UNAVAILABLE! Check connection or firewall settings, site might be down.” or
“ERROR!!! NOT connected. Check connection or firewall settings.”

  • when in fact it should be checking for and downloading an update. This is an old issue that goes back to October of 2006. When a manual update is attempted - 4.23 throws the analogous Comodo branded error message.

As far as I can tell, neither is a valid error message, as the program never attempts to connect - which can be verified by the firewall logs. At the same time, you can download psc-exam.exe from ftp://ftp.nsclean.com/pub/psc-exam.exe - so FTP is not being blocked. Sygate does not have the application blocked or a rule in place to prevent access.

If connected as a user - there are no issues. Checks and updates both via autoupdater and manually via the tray menu. You can browse the net with Firefox 2.0.0.4. regardless of user name.

This makes working as administrator to reconfigure or update a box extremely difficult, as BOClean pegs the CPU at 100% as it tries and fails to make a connection, which effectively makes the box unusable until BOClean releases the CPU.

Help in resolving this would be nice.

#2

Fwiw if I block the BOC updater(4.23) at my firewall(ZA) I get this message:

“ERROR!!! NOT connected. Check connection or firewall settings.” so that appears to be a valid message.

I’ll repeat here basically what I said over at Securecomp, try another Admin profile and not just the default Administrator profile created during the Win2K install. Although you didn’t mention Win2K in this post. And just for grins I’d try it by turning off Sygate.

#3

Comodo uses different servers, and at points it may update via a different address. If you have set the IP to a specific one in your firewall (and note, 4.23 is not from the old nsclean servers, but I believe 4.22 still is), this may play into it, and it is just happenstance that it does this when the Admin logs in. Not saying that’s it, but it’s something to keep in mind.

LM

#4

LM The OPs issue is not one of not being able to update but updating while logged in as Administrator. The update works ok as a User but not while logged in as Admin. (:NRD) (:WIN)

#5

I saw that, Jbob. :wink: Other users have reported similar issues; some apparently have come from directing the application to a single set IP in their FW; sometimes it would be blocked, sometimes it wouldn’t. Would probably be too much coincidence in this case, but you never know…

Also, vjk, You may want to post in this thread to let Kevin know https://forums.comodo.com/index.php/topic,8915.0.html in case he needs/wants some other info from you. He’s requested all “odd” things be reported to him there so he can just keep an eye on one single thread…

LM

#6

That’s interesting about the single set IP. Incidentally the OP has posted on another forum that creating a new Admin profile has solved the update issue. Of course that doesn’t answer why it is the default Admin profile that has the issue. Maybe this will be another clue for those that are having updating issues.

I’m wondering Sygate?

#7

I should probably clarify about the IP thing… I don’t mean sometimes the FW blocks the IP and sometimes it doesn’t. I mean that sometimes the update server is that IP and sometimes it’s a different one.

Comodo confirms that they are using a number of different servers and hosting companies due to the volume against their system (ain’t public demand great?), and frequently drop various ones from rotation. They advised against users setting a single address for updates, as it may not be “live” at any given time.

The DNS records for the servers are in the format: .download.comodo.com Ex: eu1.download.comodo.com
They went on to say that thus, using download.comodo.com will guarantee a live, local server.

So that’s what I’m getting at. Glad that creating a new Admin account resolved the issue; it would be good for Kevin to know, so that can be taken into account (if it’s an issue he’s not aware of).

LM

#8

The new user with administrator rights did not resolve any issue - it’s a work-around and nothing more.
It simply shows that the problem is that BOClean cannot deal with the default user in Win2K and that changing the configuration of the default Administrator account can stop BOClean from updating itself. No update - no protection. It aint rocket science and it aint Sygate even if you really really want it to be.

#9

Sounded to me like the image you’re restoring from may have issues, a corrupted admin account perhaps?
Try it with a fresh install from a MS disk and see.

#10

Sounds to me like corruption is a real stretch.

First off, you have 3 machines for which autoupdate does not work - period - and all three exhibit slightly different symptoms for the manual update. On one of the machines, is what appears to be BOClean attempting to download via FTP using notepad - which Sygate than flags and asks if it should be allowed. Sygate logs all the manual updates but there is nary a whiff of any attempts by the auto updater.

And this problem was documented more than 8 months ago with a detailed trouble report.

I think the gruntwork has been done on this puppy, and I am not about to start rebuilding a box from scratch because someone may want to believe 3 default administrators on three different machines are corrupted, when all the evidence points to sloppy code and there are the screen shots to prove it.

#11

vjk,

If you have not done so already, please let Kevin know by posting in this thread: https://forums.comodo.com/index.php/topic,8915.0.html

A brief scenario and link to this topic should be sufficient.

Tnx,

LM

#12

I’m sorry, I thought you stated either here or at Securecomp that all 3 boxes were installed from the same image.

#13

I’m not saying that you didn’t do this as this is just a suggestion to look at and it may not be the problem, but, if the boxes are all on the same network(using the same DNS server)were installed from the same image then did you run sysprep on the boxes before putting them on the network?

I have seen that small detail cause some very weird problems with permissions and DNS servers. The same SID on all the boxes is not good. Sometimes the problems won’t show up til weeks later.

jasper

#14

We restore from a known good Acronis image of an individual installation. Each machine has a current image and archive - and the images are usually done in 1 month increments - roughly in sync with the MS patch cycle. We typically retain 3-6 months of images for each machine. When something like this comes up, it is relatively easy to isolate a “culprit” by restoring a previous image. If I recall correctly, that was what was done when this first came up - and it was determined that that the issue did not exist prior to 4.22.002. The issue has remained the same since then. The images for the three boxes we are testing here are totally unrelated to one another - they are exclusive to the machines they image. Your point on corruption is well taken, but it would likely have to be a systemic MS thing - maybe related to their patches - and in that case could therefore be found on all three boxes. That, however, would not be related to the imaging process.

#15

Definitely one of the stranger ones I’ve heard of. One of our (former) customers contacted me and said that he’d been through this a while ago and offered this advice that might be the solution for you. Normally the only thing that would cause that problem is the connection being blocked by a firewall. But there’s one OTHER thing that could do that and that was what I was reminded of since I’d never seen that one.

If either Outlook Express or Internet Explorer is placed into “offline mode” and left that way, that would cause what you describe under Win2000 … in order to reduce the amount of code and ensure compatibility with so many different firewalls with different interpretations of what is “safe” and what isn’t, we designed the autoupdate (and the manual one as well, it’s the same code) to use the WININET library in Windows (since you can’t remove it and it’s there anyway). And to further ensure compatibility no matter what’s thrown our way, the ftp download is done using whatever is PRESET for IE/Outlook Express because some firewalls required odd settings in those as well. By doing things this way, then whatever was required externally would simply be picked up by BOClean’s updater and used with no further complications.

UNLESS perhaps on those machines in question, either IE or Outlook Express was put into “offline” mode and left that way. So give that a shot, it’s the only thing I can think of if everything else is working and there’s no firewall or other configuration blocking FTP …

#16

… it was established long ago that the firewall is not the issue - the behavior is the same without any firewall whatsoever (uninstalled).

  1. So all three machines, all of which respond differently somehow are set up in “offline mode” only in (OS) Administrator??
    2)… and this configuration on some of the machines when logged on as (OS) Administrator allows the manual updater to work??
  2. …so in essence, autoupdate is effected by “offline mode” but manual updater is not?
  3. … and why is it that if you create a new account with administrator privileges - that this account is unaffected by “offline mode” - and updates normally both with autoupdater and manual update?
    5)…and how would it be that on one machine, if it is in “offline mode”, and if you leave it alone long enough will try to connect to Comodo FTP using Notepad? - when on the same machine the autoupdater fails and there is no attempt logged on the firewall until it tries with notepad and Sygate asks for permission?

If this “offline mode” theory is the solution - what needs to be configured in the native (OS) Administrator account configuration to eliminate that possibility - and verify that this is the cause of this problem?

… and if true, then I would conclude that apparently you can disable BOClean with a fairly simple configuration, or maybe by simply deleting the outlook configuration or not configuring it at all - No? … like someone else on the forum noted - no update - no protection - either by default or by malicious bad guy nasty.

TIA

#17

Scorn appreciated and noted. :slight_smile:

I’ve had only ONE other person who described the symptoms you’re experiencing with BOClean. THAT person wrote to me about this since your complaint was seen on securecomp as well. When THIS person encountered it, this was the cause and the problem never recurred since for that one person.

Dunno what I can tell you would be the cause - the autoupdate and the manual update do the exact same thing in BOClean under W2K … they call the shell to run BOC4UPD (the updater) and that gets the update whether invoked by BOClean on its timer or if you open the menu and click the button. Same thing gets called the same way - only difference is one requires a click, the other receives a timeout. Same call though.

I can understand your impatience and frustration but all I can tell you is I’m as interested in ANY problem as always, but whatever’s going on there ain’t in BOClean or it would be a common event. There’s something squirrely there and I can do little more than grasp at straws with what the problem could possibly be with other people’s code. I can fix OUR stuff, but can’t do much about other people’s stuff. So let’s calm down for a minute and realize I’d like it to work for you as you WANT it to. I also realize you have experience in what we’re both doing and KNOW that when the “geeks hit the floor and stop at YOUR desktop, it behaves perfectly” and thus, you the “idiot at the keyboard, heh” are made to look like a complete fool.

Obviously you’ve been with PSC for a while and KNOW we’ve always cared … but like anyone else, we can only fix what we find. And if it’s someone else’s code, about all we can do is say “well … try this, try that, let me know.” It ain’t like I’ve asked you to “try rebooting” … or “ummm, no … that’s not supported, PLEASE upgrade your OS to something Microsoft still supports.” So this ain’t no game I’m playing, I’m literally STUMPED. Seriously! But I still want to try to help here, especially once we get 4.24 out the door and I have a wee bit less pressure than right now. :slight_smile:

But simple reality is that if the updater is being blocked, something ELSE is blocking it - either WININET settings, firewall policies or something else in that particular configuration. When PSC went under, we still had banks running NT3.5, NT4 and WFW3.11 with WIN32S … and BOClean even supports THOSE! But if it ain’t “offline” “pre-configured IE settings” or some other security program refusing a “child process” on that autoupdate, I’m plumb out of ideas. I wrote the code, I know what it does and what it expects and it’s designed NOT to be finicky … with all the stuff we’ve had thrown at us after all these years, anyway. Heh.

#18

Well, now you can make that 2.

The issue was IE - not Outlook Express - see:

http://support.microsoft.com/kb/q180946/
and
http://support.microsoft.com/kb/q195730/

Both links describe the IE issue. Interesting to note that the first linked KB article was last reviewed yesterday. Even though they both refer to IE 4 and/or 5, evidently the issue continued in IE6. Also worthwhile noting that the issue does not appear to be resolved by MS, the registry change may not stick and they admit to such in the KB article.

Resetting HKEY_USERS\SID\Software\Microsoft\Windows\CurrentVersion\Internet Settings\GlobalUserOffline to 0 resolved the issue on all the boxes in question.

Thanks for your help in resolving this.

#19

Hey vjk,

We should thank you for your persistence, patience and clarity throughout this issue.

Cheers,
Ewen :slight_smile:

#20

VJK, we appreciate your persistence in getting to the bottom of the problem.
I probably ought to add it to the FAQ under “WTF”. ;D
I’ll lock this up and mark as resolved. If you need it reopened. IM a Mod.