Mod edit: Please help this guy if possible. From the trace this does not look like a bug.
A. THE BUG/ISSUE: Windows Live Messenger Remote Assistance has never worked with Comodo Firewall
1. What you did:Tried to use Windows Live Messenger Remote Assistance feature
2. What actually happened or you actually saw: I accepted a request for remote assistance (to help the other user). Request was accepted, I received the Password Prompt for the session, and entered it as provided by the user (it was 123abc). The session never actually began. This issue has been ongoing for a while now and I believe its never worked with Comodo Firewall.
3. What you expected to happen or see: It should have launched a window for the Remote Assistance session, showing me the users screen.
4. How you tried to fix it & what happened:By disabling the Firewall AND rebooting I am able to make the Remote Assistance session. (Please note this uses UPnP)
5. If a software compatibility problem have you tried the compatibility fixes (link in format)?:
6. Details & exact version of any software (execpt CIS) involved (with download link unless malware): All current versions of Windows Live Messenger released in the last two years.
7. Whether you can make the problem happen again, and if so precise steps to make it happen:
1. Log into a Windows 7 x64 computer.
2. Open Windows Live Messenger and log in.
3. Have another user log into WLM from another PC (without Comodo) on a different network only reachable over the internet (each user behind different modern/current home router/firewalls). (They must be friends in WLM, so do that if needed)
4. Have the other user submit a Remote Assistance request (for you to help them).
5. Accept the RA request.
6. Have the user enter a password for the session when prompted.
7. Have the user provide you the password (via any method possible).
8. When prompted on your computer, enter the password given.
9. The session should start here, but never appears. There is no indication the local computer is attempting anything at this point.
8. Any other information (eg your guess regarding the cause, with reasons):
UPnP or Windows core system network issue. Note that a reboot is mandatory to resolve the issue after Comodo changes are made. It will not work unless a reboot occurs. There are no firewall blocks logged in Comodo or elsewhere. There are no Defense+ blocks logged. UPnP behaves fine. Session works when no Comodo Firewall is involved. This has been going on for 2 years and I'm finally submitting this bug because its ridiculous. I will happily friend someone on WLM to troubleshoot this from the Comodo side.
B. FILES APPENDED. (Please zip unless screenshots).:
1. Screenshots of the Defense plus Active Processes List (Required for all issues):
2. Screenshots illustrating the bug: irrelevant
3. Screenshots of related CIS event logs:
4. A CIS config report or file:
5. Crash or freeze dump file:
6. Screenshot of More~About page. Can be used instead of typed product and AV database version:
C. YOUR SETUP: Windows 7 x64, fully patched.
1. CIS version, AV database version & configuration: CIS 5.8.213334.2131
2. a) Have you updated (without uninstall) from a previous version of CIS:No
b) if so, have you tried a clean reinstall (without losing settings - if not please do)?:Yes
3. a) Have you imported a config from a previous version of CIS:No
b) if so, have U tried a standard config (without losing settings - if not please do)?:Yes
4. Have you made any other major changes to the default config? (eg ticked 'block all unknown requests', other egs here.):
5. Defense+, Sandbox, Firewall & AV security levels:Custom, Off, Custom, Not Installed
6. OS version, service pack, number of bits, UAC setting, & account type:win7 x64 SP1, 64bit, UAC Always notify, User
7. Other security and utility software currently installed:Avira Free AV
8. Other security software previously installed at any time since Windows was last installed:None
9. Virtual machine used (Please do NOT use Virtual box):None