msiexec loading everytime at startup after updating comodo firewall

about 6 months ago I had a problem with a corrupted installation file which caused msiexec.exe to load everytime at startup without installing anything… I don’t know how but it dissapeared after two weeks and I was no more bothered by it until last week on saturday which I updated my Comodo firewall from version 3.09 to version 3.10 (if I’m right) and suddenly after my pc restarted because of the update, the msiexec.exe came back and it’s starting itself after each startup, and the funny thing is that if I close it from the task manager it will restart itself if I go to any forum from my browser (such as right now)…I have updated my Comodo firewall at least 3 or 4 in this 6 months so why did this last update caused it to bring msiexec back !!! :o
Is it related to Comodo firewall? can I fix it ?
thanks in advance for any help :-La

Comodo does not use MSI installer which would call msiexec.exe. I think there is an MSI version for corporate deployment though but we don’t get our hands on that installer.

Can you download Process Explorer and see what process tree there is for msiexec.exe? That may point the finger to the installer it is related to.

Open services.msc, double click Windows Installer. Is the start method Automatic? Set it to Manual and reboot.

I don’t think either Process Explorer or ensuring MSI service is set to manual on start-up will help. I don’t believe this is how MSI either works or starts. It’s virtually impossible to know what MSI is doing from a command-line point-of-view… at start-up MSI runs an integrity check of its installed applications & if it finds anything wrong it prompts to re-install the application… usually with some message about locating an obscure MSI file that may or may not exist (many come from DVDs, CDs & temporary directories). So, if the message itself doesn’t tell you which application MSI is referring to, your best recourse is to look at the Windows Event logs to find an application name, or at worse, the CLSID that MSI is complaining about. In addition, the Windows Event logs should give clues as to what MSI has been doing prior to the CIS update. By default, MSI logs informational & error messages (including any installs or uninstalls) to the Event logs.

Whilst m2stech’s report was of the MSI trouble starting following an CIS update, it as, as Eric says, unlikely to be directly related to CIS, since CIS doesn’t use MSI. However, the reboot (for whatever reason) itself… now that as I explained, can & does trigger MSI.

windows installer was already on manual from services.msc and that process explorer was useful but didn’t show the source of problem…

in my event viewer I have tons of “information” and “warning” messages ( and they are all like :

Detection of product ‘{F1E74294-BEF3-4729-9B75-B4FB1850C747}’, feature ‘AlwaysInstall’ failed during request for component ‘{3207D1B1-80E5-11D2-B95D-006097C4DE24}’

Beginning a Windows Installer transaction: {F1E74294-BEF3-4729-9B75-B4FB1850C747}. Client Process Id: 1940.

Ending a Windows Installer transaction: {F1E74294-BEF3-4729-9B75-B4FB1850C747}. Client Process Id: 1940.

I think we’re reaching a solution here what do you suggest I should do now ? :slight_smile:

!ot! and btw I get a DNS error on your forum from my own ISP so now i’m using a proxy server and it works !

On Most Of The Scenarios, This Would Happen If There Is An Issue With Hewlett-Packard Digital Imaging Or Microsoft Office Packages.
I would request you to search your registry for the key “{F1E74294-BEF3-4729-9B75-B4FB1850C747}” and check whether you can find out any information about the package that causes the issue

I found it, it’s in Documents and Settings\User\Application Data\Microsoft\Installer{F1E74294-BEF3-4729-9B75-B4FB1850C747} and also in the registry HKEY LOCAL MACHINE\software\microsoft\windows\currentversion\installer\folders should I delete them ?

No, don’t delete a thing… MSI will notice & get really miffed. Dive into the registry tree & see if any of branches give you an application name. Failing that, check & see if you have a…


As mentioned by kail don’t delete them. Juch check whether you can find out some information about what package is it

Yep, the plan is for you to find the application concerned & then you can use the standard Add or Remove Programs applet to either repair (if it has the option), install (if you need/use it) or uninstall (if its unwanted) to deal with the application & MSI.

PS I’ll leave you in napsterz capable hands. :slight_smile:

Ofcourse, You Can… :slight_smile:

I couldn’t delete the application in {F1E74294-BEF3-4729-9B75-B4FB1850C747} because I had deleted it about 6 months ago so I even manually removed anything with the name {F1E74294-BEF3-4729-9B75-B4FB1850C747} from both registry and installer folder of documents and settings but it didn’t remove the installer from starup!
so I went to log viewer to see the exact last log before when I got the first error log about the installer after checking I saw two logs from the source crypt32 with the following messages :
Successful auto update retrieval of third-party root list cab from:
Successful auto update retrieval of third-party root list sequence number from:

Is this what happens before updating Comodo firewall? because I’m now sure this is what caused the installer to start at each startup !

here’s a screenshot of it in log viewer

There is a Microsoft tool to get rid of MSI installer related information on your computer: Windows Installer CleanUp Utility.

Run this tool and see it shows your uninstalled program and let it delete the left overs.

nope no sign of that program…

It’s just a bit further down the page on the URL that Eric posted. But, here’s the direct download link…
Please don’t smite me MS!

However, this utility is known to fail at removing any MS Office 2007 MSI issues. So, please take care.

The general rule with MSI data (both file & registry) is never to delete anything manually, always use Windows itself (Add or Remove Programs applet, etc…). MSI can be very tricky & sensitive on this. MSI does sneaky things like use reverse CLSID’s and storing data in unexpected places. Unless you know exactly what you’re doing you can easily make things worse… and I’ve done that myself a few times. :slight_smile:

On the image you posted: I’m not convinced that the Crypt32 messages are related to the MSI issue, since the timing is off. Are there any MSI entries prior to this? They often appear at start-up… obviously. :slight_smile:

However, I do see that there are plenty of MSI entries there, scanning all these might reveal some useful info (ie. the application that MSI is wibbling about).

No, there’s there’s been a misunderstanding, I meant to Eric that windows clean up utiliy didn’t find left overs of that problematic program

there are some MSIinstaller logs prior to it but for 6 days before it and they are only information logs and not warning logs meaning they’re not the cause.

those tons of MSI entries began after updating Comodo or maybe from Crypt32 and they all have the same message which I posted it before but I’ll put it here again

warning log
Detection of product ‘{F1E74294-BEF3-4729-9B75-B4FB1850C747}’, feature ‘AlwaysInstall’ failed during request for component ‘{3207D1B1-80E5-11D2-B95D-006097C4DE24}’

information log
Beginning a Windows Installer transaction: {F1E74294-BEF3-4729-9B75-B4FB1850C747}. Client Process Id: 396.

information log
Ending a Windows Installer transaction: {F1E74294-BEF3-4729-9B75-B4FB1850C747}. Client Process Id: 396.

and these logs cycle repeats

I deleted this folder according to logs (Documents and Settings\User\Application Data\Microsoft\Installer{F1E74294-BEF3-4729-9B75-B4FB1850C747}) including its content which were installer of that problematic program but the problem was not fixed :-TD

Is it normal if something else is in Documents and Settings\User\Application Data\Microsoft\Installer\ ? I mean is it a temporary place or permanent ?

The only recourse that I can think of at the moment is to use the Group Policy Editor to flip MSI into verbose mode in order to get it to tell us more about what it is doing. It could be running one of those .MSI files under C:\Windows\Installer (don’t delete any of these). But, unless you already know about these types of things I’m not sure how comfortable you would be with that. Although it might not look much, the Group Policy Editor is a very powerful tool. There’s probably some sort tweak tool that does it, but I cannot find any at the moment (still looking). Anyway, can you confirm your OS in meantime please, thanks.


How about this registry tweak (I’ll still need you to confirm your OS to be sure)… it apparently turns on verbose logging for all Windows MSI installations.

Logging = voicewarmup

This might do what we want without having to use the GPE. You’ll need to take note of the current setting, as it has the potential to fill your event log & you will want to turn it off later.

I have XP sp2, but I don’t know a thing about this Group Policy Editor !