Hi EricJH,
Sorry, a small correction, powershell is enabled by default for both command line and embedded code detection.
Please see enclosed.
Thanks
-umesh
Thanks for catching umesh. :-TU
I am using a custom Proactive Security configuration and that one has the filtering of numerous script hosts not enabled by default. I guess that is because it goes back to previous builds that did not filter certain script hosts then. I will adapt my active configuration.
I have edited my previous post by striking the erroneous statements about intercepting Powershell scripts.
I don’t have a release version of Win 10 on my system. Only Win 10 Insider, Windows 7 and will reinstall Win 8.1 in the next days.
I mean COMODO Internet Security (aka cis.exe, cavwp.exe, cistray.exe) closing out shortly after running and then disappearing from the task manager, BUT, COMODO Internet Security Helper Service continues to run (aka cmdagent.exe). Does that clarify?Thanks.
I checked the event manager and the error that appears about the same time that this happens has a message about twin_ui crashing explorer.EXE (which I wish I had the exact message but unfortunately this system purges logs daily, ■■■■, I should have grabbed it - hindsight, thou art a heartless )To what application does twin_ui belong? Is it a dll file?
First, there is no specific setting for "Windows Apps" and yes, they are detected just fine as regular attempting to make a connection and always have, I have tons of them on my rules, some allowed, some not, some limited to just LAN (my own configuration not on the default rulesets). So, where are you seeing this specific setting?Just for clarity about the terms App and applications. Let's use App for programs from the Windows store. They have simple interfaces that will also work on tablets and phones with a limited set of buttons and actions reminiscent of Fisher Price and Lego Duplo for toddlers. Let's use applications for program that run in the classic desktop environment. They have smaller buttons, more functions and will not always look well on tablets or other devices. CIS has different approaches to the two worlds of Apps and applications.
These days the distinction between Apps and application gets blurred which may cause confusion and hence why I am asking about which one you are talking.
And that is not the issue that was encountered anyway, the apps I tested with were not Windows Apps but even so given my experience, they would be detected just the same. I am open to clarification on that if you have it.I did a bit of testing. I made an ask rule for Firefox and XnView and would ask for internet access when they needed it.While that expectation may be the case (or intended), we have no way to know if it is actually happening and that wasn’t my observation. Since an app that has no internet access shouldn’t be able to successfully check for updates if it hasn’t been ruled to do so already (which they weren’t) and the default deny is on, if that was the case. Right? Assuming that’s what you mean, they shouldn’t by default have access.
Please advise.
I closed CIS from the systray icon and Only cavwp.exe and cmdagent.exe would be running. I closed and started Firefox and it would take a minute or longer to start. It would sit in the background until it decided to come forward. When it came fwd it couldn’t access the web and as expected the firewall did not pop up. When testing with a browser it may take pages from its cache giving the impression it loads the page. But when you would load a page it hadn’t visited yet it will fail.
XnView would freeze for approx 20-30 when I asked it to look for updates. Then it would function again without giving a message whether I was using the latest version or not.
Some applications do get affected when the client is closed. FF and one of your applications will show up in task manager without showing a UI. The examples with FF and XnView show that when the UI shows up and they are active they cannot connect to the web.
I then set the Firewall to Custom Policy mode and closed the client and started other browsers. IceDragon like FF took a minute to show and couln’t connect to the web. The same is true for Edge and Dragon.
To answer the question of your concern. The application that you were talking about that was running in the background could not have accessed the web and checked for updates.
That’s why I wish I had the details, have to wait for it happen again to capture that but I don’t recall any particular dll, just saying something about a hook into explorer.exe which results in the crash. I will share it when I get it again. Still didn’t explain why it neutered CIS in the process, that is still a mystery to me.
Just for clarity about the terms App and applications. Let's use App for programs from the Windows store. They have simple interfaces that will also work on tablets and phones with a limited set of buttons and actions reminiscent of Fisher Price and Lego Duplo for toddlers. Let's use applications for program that run in the classic desktop environment. They have smaller buttons, more functions and will not always look well on tablets or other devices. CIS has different approaches to the two worlds of Apps and applications.
Ok, will do. Yes, I develop them as well as regular .NET applications, so I am aware of their different structure system. Different approach or not, there is no unique setting for just Apps that I see, and they have always been detected appropriately without a need for one, so not sure how the “approach” is distinguished here.
These days the distinction between Apps and application gets blurred which may cause confusion and hence why I am asking about which one you are talking.
I’ll concede on that for your benefit but given the behavior of the firewall doesn’t distinguish who is making a request but just that a request has been made by “something” then it shouldn’t really matter but ok - I ran classic desktop applications.
I did a bit of testing. I made an ask rule for Firefox and XnView and would ask for internet access when they needed it.I closed CIS from the systray icon and Only cavwp.exe and cmdagent.exe would be running. I closed and started Firefox and it would take a minute or longer to start. It would sit in the background until it decided to come forward. When it came fwd it couldn’t access the web and as expected the firewall did not pop up. When testing with a browser it may take pages from its cache giving the impression it loads the page. But when you would load a page it hadn’t visited yet it will fail.
Ok, great and thank you. But what about an application that hasn’t been explicitly ruled in the settings? If the deny is on by default, then not adding them to the list should also result in them not being able to reach anything, correct? Or am I misunderstanding what default deny does here?
XnView would freeze for approx 20-30 when I asked it to look for updates. Then it would function again without giving a message whether I was using the latest version or not.
That may be a programmer’s design choice to silently ignore failures to connect to the internet. Some give feedback, couldn’t reach server, some will come back with generic “no update” like VLC does when it can’t connect, and of course if they succeed - some will tell you there is no update, some will just go silent (like WinSCP does) and of course if there is something, they will say it. The lack of feedback one way or another is unfortunately hard to interpret.
Some applications do get affected when the client is closed. FF and one of your applications will show up in task manager without showing a UI. The examples with FF and XnView show that when the UI shows up and they are active they cannot connect to the web.
Agreed, some programs (depending on how they are configured) require that they connect before even showing their interface, or takes a very long time before they ■■■■ out and say something. Like say those that load their configs or whatnot from the cloud and need it before showing up, or have say sync of some kind enabled.
I then set the Firewall to Custom Policy mode and closed the client and started other browsers. IceDragon like FF took a minute to show and couln't connect to the web. The same is true for Edge and Dragon.To answer the question of your concern. The application that you were talking about that was running in the background could not have accessed the web and checked for updates.
Interesting, this last step does seem to suggest it works by default denying but I am curious why the two that I tested (ImgBurn and Calibre) worked with it, even though they are not allowed on the list and were not running in the background. I will test a bit more and see if I can figure something out and will share, thanks.
On Win 10Pro x64 1709 (16299.309) it functions as expected
- Open Advanced Settings
- Under say HIPS Settings, check “Block all unknown requests …”
- A pop up comes up that says something to the effect of, are you sure, it is only for really infested systems, etc etc.
- Click ok to continue and it will dismiss the popup
- Click OK to save and close the GUI - it closes as it should & setting took
- Click CANCEL to close the GUI - it cancels as it should & setting dodn’t take
- Click on the X on the top, it will close the GUI
Thank you for testing that, I wonder why it doens’t behave that way for me then? I’ll have to run some more tests with app (and/or Application) combinations to see if something else is affecting it then. This morning it didn’t do it after I ran it again following your post. But then when I tried a bit later, it happened but I noticed something that might be relevant. During that “decision making” interaction, a detection “choice” popup came and stole the focus and after finishing with that, the interface behaved as described originally. So perhaps it is affected by another part of the applications GUI stealing focus and then return back to it, the focus is not returned to it? Just thinking this might be important. Thoughts?
Additionally, when you are in the Application Rules when you check a box for a rule and then click on Move Down (even Move Up) it will complain that you need to select an item (despite being selected) to move it just because at times it might be “out of view” which makes no sense, if it is selected, then you know the item and move it, whether it is visible on the screen when you click the button shouldn’t matter. For example:
- Select the first rule or whichever (checked)
- Click on
Move Downwhile it is still “in view” (moves it) - Now scroll down (item is still checked) to where you intend it to end up (no longer in view)
- Click the button and now it will say it must be selected (even though it IS selected)
- Scroll back up to make it in view (still selected)
- Click the button and it moves it just fine (no complaint)
It is 100% reproducible each and every time, this shouldn’t happen.
Furthermore, sometimes when you “check” a box, it will move the item up or down. It seems that checking the box quite often riggers the Drag event and subsequently the Drop event moving the item up or down - even though no such drag and drop was performed, just the selection box was checked. It might feed into the problem above where the items on screen visibility is tied to it being seen as selected, meaning somehow they are processing items in a non-traditional list-based indexing. Without access to the source, it is only an educated observation of the behavior. Very similar to something that often plagues “owner-drawn” controls and how they are painted.
That again doesn’t happen here; although I use Proactive tweaked to my needs, there aren’t too many rules that necessitate having to scroll . .
Try it with a scroll condition, it will happen. I used to have what you described too but ended up needing more granular control of certain things so I now have about two pages or so, give or take at any given time of items on my rules list. Unless you only run a handful of programs, you are bound to have enough to fill up a few pages (relative to your screen size/resolution). I have a large number of programs that don’t all run at the same time mind you, but do run on this system and need to be accordingly “monitored” at any given time. Right now with a custom list configuration, I have 69 items.
I have 2 . . . . I don’t have ‘Create Rules for Safe Applications’ checked . . . that’s it!
I have 3 drives with rather particular applications plus 2 VM on this one system, but have never needed more rules that need to stay more than a few days
It is reproducible by expanding a HIPS rule for a file group after you select it and use move down.
You’re right . . just tried expanding one as Futuretech pointed out and it happens as you said
Just thinking out loud. I understand you have a lot of rules. CIS will respond very slowly when making changes with a lot of rules in place. That might play a role. Could you activate a factory default configuration and see what happens?
I tested on a squeeky clean Win 8.1 x64 and CIS and the problem does not reproduce. I am using a custom Proactive config that I had saved.
I don’t have that checked either, I am on Custom Rulesetand create them as they pop up and I decide how they should have/or not access and to what. Once the rule has been established for something that won’t change for me, I don’t usually remove them, although occasionally I remove all rules and start again. If I am making selective decision on something that will not permanently behave that way, I allow/block it without “remember” so that next time it will pop again for select applications.
Great, thank you both. I didn’t check in that particular interface but behaves the same it seems.
Interesting, will do. I don’t think significantly less than 100 rules should be a major issue (at least for me never has been) but I understand where you are coming from, I will take a look, thanks. Just to be clear, I don’t use HIPS, only Firewall and use the Firewall Security configuration, would your suggestion be still relevant in my situation? Just want to make sure I don’t go down a rabbit hole 
Thanks.
It will be worth the try because a lot of rules do have an influence. So please try to temporarily enable a factory default configuration and see if the problem reproduces or not.
Sure, will give that a try and let you know when I have something to share. So you really think this was the reason the button(s) were held up after the warning popup? I just went through the process of check and click ok and there was a significant delay but it did go forward. Never thought 60+ rules would have such a negative effect. I guess I will have to rethink the setup a bit.
I don’t know how many rules would be of influence hence why I ask to test by temporarily enabling a factory default configuration. How long does it take after you added a rule or changed a setting for CIS to seal the deal? I am just wondering.
I know what you meant and I appreciate it, I was just thinking out loud. I didn’t put a clock on it (and I am not being flippant here) but it did take a significant enough time to be noticeable, most dialogs seal up nearly instantly but this one I would say took a good half a minute maybe (give or take).
Anyway, I had promised earlier in the thread to provide some information on the event that is generated when CIS gets killed and got this today for you all. I know it wasn’t your message specifically but wanted to include it here to keep it in order rather than going back to edit an earlier post.
Faulting application name: Explorer.EXE, version: 10.0.16299.248, time stamp: 0x18ee648b
Faulting module name: twinui.pcshell.dll, version: 10.0.16299.248, time stamp: 0x362fafd8
Exception code: 0x80270233
Fault offset: 0x00000000001c47f5
Faulting process id: 0x29ac
Faulting application start time: 0x01d3c462b0767ae8
Faulting application path: C:\WINDOWS\Explorer.EXE
Faulting module path: C:\WINDOWS\system32\twinui.pcshell.dll
Report Id: 054c5794-a981-4b6c-97a1-c309a1fbf496
Faulting package full name:
Faulting package-relative application ID:
This happens immediately on or after CIS disappears from the systray and stops working. So not sure which causes the other, sort of a chicken/egg situation. I did some research and while nothing is specific to this (that I could find) it seems a lot of ancillary comments revolve around some kind of Intel graphics issue with an updated driver pushed out by Microsoft but some of them are pretty dated and I haven’t had any updates from Microsoft when this started, the only thing was this update, so hence why I was thinking it might be related to this somehow. Specially knowing that M$ often releases tailored updates to account for Comodo, figured this might have been a regression of some kind. Honestly, don’t know.
It looks like you are on to something and we could be looking at a bug and something that needs to be reported as a bug. So I have more detailed questions for you about your system that are needed for a bug report.
Can you check c:\ProgramData\Comodo\CisDumps folder to see if a crash dump was created by CF? What graphics adapter do you use in your system? Do you use a single or double monitor set up (twinui may indicate multi monitor setup)?