Make sure you won't get a power outage if you uninstall CIS.

Comodo Internet Security - CIS Install / Setup / Configuration Help - CIS
#1

Hi,

Was going to re-install CIS because of some minor issue I was having. After re-installed I couldn’t get the GUI to work, whenever I clicked something in the GUI the whole thing froze and well… that was that, restart.

So I tried to re-install again but this time during uninstall… power went out… during the uninstall of kernel drivers…

Upon restart… black screen, nothing works… Restart, black screen, restart black screen, restart, black screen… and so on, until I actually got in! =D But then CIS complained about not being able to start, uninstalled it and re-installed it again, now the gui doesn’t even exist. ???

Uninstalled again and used the uninstall tool in safe mode… upon re-install still no GUI.

I am officially declaring this installation of Windows ■■■■■.

Edit: Added diagnostics report since I somehow got that from an error message…

Myeeeeh,
Sanya IV Litvyak at-the-moment-also-known-as Sad kitty.

[attachment deleted by admin]

#2

This can happen with any number of files/applications. It’s always bad when the power goes out while you’re using the computer! (any electronics for that matter…) Just how bad depends on what you had open, and what your computer was doing at the time the power went out…

I always recommend that anyone using a computer should have it plugged into a battery backup system. The first time the power goes out while you’re using your computer and you’re able to safely shut it down, the battery backup has just paid for itself. :slight_smile:

I actually have half a dozen battery backups in my house on everything from computers, to cordless phones, to my home theater system. A good battery backup system will also provide line conditioning. Which means that it will also protect your electronics from under or over voltage scenarios, which most electronics are not happy with. No matter what the incoming power looks like, all that your electronics will see are ideal operating conditions.

#3

Indeed however I can not afford a UPS at the moment.

About the report, anyone can take a look at it and see if it’s correctable?

I was able to uninstall CIS and now the computer works as normal however if I re-install it again it will never launch the GUI and things will start to break, internet will slow down and some things won’t even get out on the internet. =(

Edit: Also, the one in a million that the power would go out exactly as I uninstall CIS and it’s at the “Kernel Drivers” part of uninstalling. <_<

#4

Waaait… I ran the CIS installer as administrator and perhaps it’s going to work now, GUI shows and diagnostics can’t find anything… (is now a hopeful kitty)

#5

Restarted a few times and tested a few things, seems to be working now! =D

Note to self: If it fails, keep trying and eventually use administrator rights 88)

(Is now a happy kitty)

Edit: Apparently it also fixed the issue which made me re-install in the first place (which was that unknown applications downloaded and executed through Google Chrome would not be sandboxed)

#6

Oh, man! I can’t believe you actually posted this! 8)

I was having issues with CIS, so after tolerating the prollems for quite a while, I woke up on 28 Fri 2013 and said “Self, we’re going to do a clean re-install.”

So I uninstalled it. I get a pop-up at the end:

1:1703 2:Comodo Internet Security Premium

The pop-up was a modal form containing the the above described lablel and contained a button control.

After pressing the buton control, the system entered shutdown mode. After saving settings, the wallpaper went away and the grey screen appeared (the one just before the screen winks out). The HDD made these funny two chirping noises that HDD make when the SCSI host-controller is polling the SCSI bus for SCSI ID during boot.

Presto! BSOD C thousand 5.

I rebooted and everything was cool. I ran CCleaner and fixed vestiginal errors. I re-installed. When it did its shutdown gyrations at the end of the installation it did the same thing aforementioned. Presto! BSOD 7E.

I rebooted and everything was cool. I launched CIS and went to update it. It gave me the error message that it couldn’t access the servers. After mucking around, I determined that CIS was preventing DNS access. Nothing was displayed in the logs as being blocked.

O.k, gee that didn’t go well. As they say, “Second time’s a charm.” SO I uninstalled CIS and rebooted (see above gyrations).

Except this time when I rebooted: things weren’t cool. I got a notice that at least one service didn’t start. When I looked into the event logs, I noticed that DHCP and a couple other services didn’t start because the TCP/IP device couldn’t be found. So the TCP/IP stack was hosed now.

But wait! I’m smart. We have the tools. We have the tinker-toys. Gentlemen, we can rebuild it!

So I rebuild the TCP/IP stack and go to do the required re-boot and see above for the gyrations. I reboot and everythings cool. I can’t update CIS. I can’t get on the interwebs. I can attach to 192.168.0.1 and ping it fine. Several image restores and CIS failed post-reinstall update attempts resu;ted in corrupt TCP/IP stqack.

Well. This aint goin’ nowhere FAST! Looks like this is a time to restore from backup. Looks in backup folder - heart sinks - last backup: 9 Apr 2013. Alas, and woe be unto me. I backs system up as is, and then reformat & re-install HDD image backup made 9 Apr 2013.

System boots up and everythings cool. Well, except for the wonky little prollems that ulitmately caused me to say: “Self, we’re going to do a clean re-install.” SO I did. See above for gyrations. Grrr.

I went through innumerable evolutions of this, trying to remove HDD drivers, SCSI drivers, GFX driver, etc all to no avail. Eventually I determined it had nothing to do with drivedrs, hardware or the O/S, it was the CIS uninstall itself that was the culprit.

I tried the Revo Uninstaller thingy per the uninstall sticky thread. How’d I get onto the interwebs to find that? OH, I have a dual-boot system and the other system works good lasts long time. Thingy is: Revo Uninstaller implements default CIS uninstaller. See above for gyrations. The thing is: rebooting from dual-boot installed WinXP was problem free.

As the sky was getting light again Saturday morning, I said “Self, this is going nowhere FAST!”

Cut to the chase: I reformatted, restored image and then ran Windows Installer Clean-up Util. After selecting CIS in MSICUU I then manually deleted CIS folders in

C:\Documents and Settings\All Users\Application Data
and C:\Program Files.

It deleted everything except: cavshell.dll (stating that despite being Administrator / creator I didn’t have permissions). Couldn’t delete the file in safe mode either. Grrrr. Booted into dual-boot system and poofed remaining vestige. Rebooted into primary desktop O/S which promptly warned me something was wrong with CIS. No kidding?

I then ran CCleaner and let it fix the stuff mucked in the registry. I then rebooted. After the system came up, I re-installed CIS and updated it. Everything was hunky dory, and no more pesky wonky little problems with CIS.

Moral of the story: drink your Ovaltine.

#7

Sounds like you’ve been through hell, however it’s always a victory if you can find your way out. :slight_smile:

#8

I made a return visit to the nether regions again. >:-D

CIS began acting wonky again. I had to go through all this ■■■■ again. (:AGY)

This time I used the Comodo Group uninstaller tool. I was very disappointed in that the activity display is quite terse. It was telling me ‘access denied’ and ‘not found’ errors (among others), and yet there was no clue what the prollems were. Eventually as I was trolling through the registry cleaning CIS out, a reference to the Comodo Group clearner’s bat file. I used that bat file as a roadmap. There are several issues with that bat file. But those are trivial compared to what my prollem turned out to be.

I discovered corruption in my SYSTEM regisrty bee-hive. And specifically it pertained to the /SySTEM/Software/Comodo branch of the bee-hive. That’s where CIS’ security policy lives. The problem was that once again attempting to uninstall CIS resulted in a modal - in contrast to modeless - form pop-up:

1:1703 2:Comdo internet Security Premium w/ a single button control.

There is no option other than to press that button control. And when that happens the system restarts. This was an inviolable chain of events. The ultimate result is a bugcheck x7E or xC thousand 5. The system will reboot without issue, but every single re-start will result in BSOD.

Troubleshooting this issue was mind-numbingly tedious After each operation’s failure, I developied various hypothesis that I ultimate proved false each and every time. A fundametnal premise that ultimately proved incorrect: a limit exists of the number of sub-keys and value names (in total) that can exist when deleting any arbitrary key.

In my specific case the problem manifested itself when pruning the Network Aliases branch of my custom CIS configuration; I have 260 network zones. I was able to narrow the problem down to somehwere w/in 5. Ultimately I dixovered deleting a single value of a sub-sub-sub key would cause the BSOD phenomena. Then I discovered that the registry bee-hives are unrepairable; and they can’t be built from scratch. If a functional one can’t be restored, re-format & re-install is one’s only option.

And if one wants to recover the current system configuration in the registry, one has to work with a copy of the registry; the live registry can’t be mounted to export the necessary data. This is a necessary and fundamental task to accomplish recovery of a current system state.

First I launched regedit and mounted /Windows/repair/SYSTEM. This is viable registry hive that is updated by NTBACKUP system-state operation. If that has never been done, those entities are in the state of initial system installation. It will have no record of any software install / updates done since. I can’t recommend heartily enough to backup system state periodically.

When one loads a registry hive in regedit, a temp name is specified. I exported each key in SYSTEM to a seperate reg file. The temp name is embedded in the registry keys of the output reg files. This is crucial. Without that temp name in the pathname, importing reg files will update the currently live registry. Bad.

After unloading the hive in regedit and then closing it, I dug up a two y/o HDD that had a functional installation of my O/S on it. That was my only option, as I had corruption problems due to system memory errors a while back; all current backups would contain the corruption discovered to be embedded in the registry. I extracted the Windows\System32\config registry files and then remounted my current HDD.

Now I launched regedit and mounted the SYSTEM file I extracted from the old HDD and used the same temp name for the mount point. Then I imported all those exported REG files into it. That’s when the embedded temp name in the key name is essential (otherwise you updating the live registry, and not the one you’re trying to fix). Regedit will display an error about incomplete operation, but I determined it did everthing absolutely necessary.

Now one has to be able to mount the operational O/S as a non-boot device, or log into Recovery Console. Then overwrite the existing registry hives with the fixed ones. After doing that the uninstall went like butter. Happy happy joy joy!

I discovered, however, that there was an inherent issue with the security policy intrinsic to the registry. Specifically, the HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Enum\Root\LEGACY_CMDAGENT, CMDERD, CMDGUARD, CMDHLP & INSPECT. They can’t be deleted because the sub-keys don’t have ‘allow’ permission for admin / creator.

I question the wisdom of implementing the registry for foundational CIS configuration. Its plausible that the number of sub-keys en toto can number in the thousands; any one of these could potentially be a source of a problem. Any user that’s had an unstable sytem while using CIS is potentially at risk. This could become a serious issue for those migrating from v5 to v6.

#9

If only corruption of CIS keys is the cause then a reformat and reinstall of Windows is not necessary.

Restoring would only work if you have system restore points (which may not be the case after have suffered memory corruption for a period of time) or have registry back ups present or have old enough exported configurations present

If none of the above are available then the only thing you can do is start with a factory clean configuration and delete the old ones.

And if one wants to recover the current system configuration in the registry, one has to work with a copy of the registry; the live registry can't be mounted to export the necessary data. This is a necessary and fundamental task to accomplish recovery of a current system state.

First I launched regedit and mounted /Windows/repair/SYSTEM. This is viable registry hive that is updated by NTBACKUP system-state operation. If that has never been done, those entities are in the state of initial system installation. It will have no record of any software install / updates done since. I can’t recommend heartily enough to backup system state periodically.

When one loads a registry hive in regedit, a temp name is specified. I exported each key in SYSTEM to a seperate reg file. The temp name is embedded in the registry keys of the output reg files. This is crucial. Without that temp name in the pathname, importing reg files will update the currently live registry. Bad.

After unloading the hive in regedit and then closing it, I dug up a two y/o HDD that had a functional installation of my O/S on it. That was my only option, as I had corruption problems due to system memory errors a while back; all current backups would contain the corruption discovered to be embedded in the registry. I extracted the Windows\System32\config registry files and then remounted my current HDD.

Now I launched regedit and mounted the SYSTEM file I extracted from the old HDD and used the same temp name for the mount point. Then I imported all those exported REG files into it. That’s when the embedded temp name in the key name is essential (otherwise you updating the live registry, and not the one you’re trying to fix). Regedit will display an error about incomplete operation, but I determined it did everthing absolutely necessary.

Now one has to be able to mount the operational O/S as a non-boot device, or log into Recovery Console. Then overwrite the existing registry hives with the fixed ones. After doing that the uninstall went like butter. Happy happy joy joy!

I discovered, however, that there was an inherent issue with the security policy intrinsic to the registry. Specifically, the HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Enum\Root\LEGACY_CMDAGENT, CMDERD, CMDGUARD, CMDHLP & INSPECT. They can’t be deleted because the sub-keys don’t have ‘allow’ permission for admin / creator.

I question the wisdom of implementing the registry for foundational CIS configuration. Its plausible that the number of sub-keys en toto can number in the thousands; any one of these could potentially be a source of a problem. Any user that’s had an unstable sytem while using CIS is potentially at risk. This could become a serious issue for those migrating from v5 to v6.

You surely went deeply into the bowls of Windows here. The Legacy keys are a chore if not almost impossible to remove using Regedit. I always remove the left overs using Device Manager under the Non Plug and Play drivers.

Even though it could cause problems when upgrading from v5 to v6.2 luckily CIW will start with a clean v6 profile and will have the old v5 configurations on store for you to enable.

Other than that if you can positively vouch that corruption in CIS registry keys can cause BSOD involving CIS drivers one could consider reporting it to Comodo as a bug. But I am a bit torn here if it would make practical sense.

If I understand things correctly you did a clean install of Windows so any mini or memory dumps won’t be available making it a a bit tougher for Comodo QA to reproduce. If you are considering to report it could you provide the offending configuration? This problem reproduces in v5. I guess if it would reproduce with v6 also (QA may try that if they find it an important bug) then it may be something.

In short. I see a bug with v5.x that may be worth reporting but there are factors making reproduction by QA more of a problem… :-\ Sorry for thinking out loud. I may ask another mod for guidance here…

#10

It seems to me there are three things worth reporting here, probably quite urgently and directly into BZ.

One is the very large number of keys which can accrete, if it causes problems on update. If so they need to know about it. Would these export in a config? If so we can test the updater on them. If not you could maybe ask Yuriy of he would authorise this guy to have the updater.

The second is the non-deletable key. What he has found explains existing bugs re driver entry non-deltion. So maybe that’s a comment on that report.

The third is this BSOD key.

So I suppose I’m saying that rather than report the whole issue, report the sub-issues.

This are long posts, and I have only spent 5 mins reading, so if what I am saying makes no sense please say so.

#11

Incidentally there is a function to create a blank registry hive. Just no tool that exploits it that I know of.

If you create one Wxman I’d love to have it.

Best wishes

Mike

#12

Oh maybe a forth one, but it’s more of a query. Does the CIS 6.0 updater now do proper Commit/Rollback (will resolve power outage problems if they don’t lock the computer by reversing incomplete changes). Which is where this topic started. Reported that myself like 3 years ago or something…

Maybe someone should test on 6.2…