SqueezeSvr.exe could not be recognized

I am having endless problems with trying to configure my Squeezebox server. I create a rule for it, but this rule is simply ignored. Eventually, CPF trips into the final rule for “All Applications” where I have temporarily altered the default rule from “Block” to “Ask” for mismatching requested. So up pops an alert and I am asked what I want to do. When I tick “Allow” (and “remember my answer”), CPF actually adds a new rule to the very same ruleset that it ignored when mapping the request in the first place. And, naturally, the rule it has added to the ruleset it ignores, it continues to ignore and so it asks again. And again. And again.

I trawled through this forum yesterday and various posts associate this kind of behaviour with a corrupt installation. So I bit the bullet and uninstalled COMODO (in accordance with instructions found on this forum) and did a clean re-install (of the latest s/w). And the same problem’s back !!!

I have no idea what do next. Any suggestions?


Bowl me over by this deathly silence … No-one able to help??? Here’s an update:

Ordinarily, one is supposed to start SqueezeSvr.exe via a little tray-app called SqueezeTray.exe. When I do so, all the hell described in the OP breaks loose. (I did not actually mention that I don’t just get firewall problems in that instance, I also have Defense+ detonating all around me with all sorts of terrible warnings.) As I write this, SqueezeSvr.exe is actually running properly and observing all the rules I put in place. I got there because I did NOT launch from the tray but double-clicked instead on the executable in Program Files/Squeezebox/server.

Does this ring any bells with anyone, please?

And more trouble along very similar lines: I was trying to assign a ruleset for M$ Outlook. Just selected “Preconfigured rules, Email Client”. Should have done the trick. Instead, COMODO simply ignore the ruleset completely. Deleted the set and replaced it with a “Block All” rule to see whether Outlook would puke. 'course not. It just keeps punching out thru the All Application rule at the bottom. Can someone please tell me what is going on with this product? It makes no sense to me ???

I MAY be on to a pattern to this problem. On Windows, and I never asked how this works, we are sometimes given a full pathnames for a file, as in eg “C:\Program Files\Microsoft Office\Office 10\OUTLOOK.exe”, while at other times the same pathname is reported as “C:\PROGRA~1\Squeezebox\server\SqueezeSvr.exe”. It seems to me that I get problems with those executables that are reported with the latter convention in the Firewall Events viewer. Perhaps, an expansion of the "C:\PROGRA~1" to "C:\Program Files" is performed when the ruleset is applied and is afterwards found not to match the "C:\PROGRA~1" reported back from the executable?

Does anyone know how to force Windows / COMODO always to expand the "C:\PROGRA~1" moniker?

Please leave the Outlook problem out of this topic. It has its own topic and will only make this topic needlessly more complex.

Am I correct to understand that you need an open port for incoming traffic for Squeezesrvr.exe? That is something that needs to be dealt with in Global Rules.

What is your current rule for Squeezebox? Please post a screenshot of it. Also post a a screenshot of your Global Rules. Also tell me for what type of traffic firewall rules need to be made? Do you have a url to a support page of Squeezebox that can tell me?

Agreed, to some extent. I am now positive that the root of the problem’s the same: 8.3 names. The reason I’m positive on this is that since SqueezeSvr took it upon itself (search me why) to report back its LFN, CIS 4.0 is applying my ruleset. And the app’s working -ish (see below).

Yes, and no. All music streamers are on the LAN (behind the router) and I have a Global Rule (created by COMODO after the installation) that allows all local traffic to pass.

There’s one but it seems totally out of date. The current app appears to require a lot more ports. As I say, as of THIS VERY moment, SqueezeSvr.exe is behaving itself. Now, mysqld.exe, which is part of the Squeeze distribution, that’s another matter altogether. That thing wants to listen on 9092 and I cannot get that cleared because the thing reports with a mangled 8.3 name.

There’s actually something rather odd about that 8.3 name, as burcine commented on in the other thread. The string (as reported by COMODO) is literally:


Now, STRICTLY speaking, to observe the 8.3 conventions, this should collapse to sthg like


Curious, no? This may be a clue to what’s wrong, though. A guess says that COMODO always uses some expansion routine for filenames (which would conform to MS coding conventions) but that there’s a bug in that expander such that it (randomly?) fails to expand only the first component of each path.


Do you have download link for the Squeezebox Server program so I can install it and see how it behaves. None of the currently installed programs use the old 8.3 convention.

If you really wonna go that kind of trouble, try My Media - Welcome to mysqueezebox.com!. Bear in mind, though, that my experience clearly demonstrates that COMODO’s behaviour seems unpredictable. At this moment, SqueezeSvr.exe is fine while mysqld.exe (and Outlook.exe) is broken. There’s no rhyme nor reason. The correct approach is to have a developer look at what had been fixed in Version and how that same code broke again in 4.0.

You made a thorough bug report in the bug section. So the devs will see it and should pick up on it. Thanks for getting to the bottom of this and reporting it. :-TU