Wise Installer Interacts With Other App's Installer Data (3.0.24 / 25 - XP SP3)

Bug Reports
1

Products Tested:
CFP_Setup_English_2.4.18.184.exe
CFP_Setup_3.0.25.378_XP_Vista_x32.exe
CFP_Setup_3.0.24.368_XP_Vista_x32.exe
CFP_Setup_3.0.13.268_XP_Vista_x32.exe

Products Affected:
CFP_Setup_3.0.25.378_XP_Vista_x32.exe
CFP_Setup_3.0.24.368_XP_Vista_x32.exe
CFP_Setup_3.0.13.268_XP_Vista_x32.exe

Platform: Win XP Pro / SP3 (32-bit)

Possible Relationship To Outstanding Bug:
https://forums.comodo.com/empty-t15137.0.html

Issue:
Wise Installer parameters used by Comodo Firewall Pro 3.0.24 & 3.0.25 (possibly all 3.0 versions) may interact negatively with Wise installer data used by other applications on the system.

For example, after multiple, repeatable test installations of the affected products, PowerDesk 6 (which also uses a Wise installer) re-installs itself. PowerDesk has been on the test system since 2005-10/12 and has never been disturbed by untold numbers of other application installations which used Wise Installers.

The Wise Installer parameters used by CFP 2.4.18.184 do not cause this issue.

Details

Testing:

  • created backup images of disks to be affected
  • downloaded CFP products (see above)
  • checked the md5 sums (checked OK)
  • installed software (for v3.0.x, the toolbar was not installed)
  • rebooted

The results were repeatable following these steps:

  • restore disk images
  • boot
  • re-install software to be tested
  • reboot

Observations and Results w/ v 3.0.24 & 3.025:
After the installation / reboot and logging into my user account, I started to do some cleaning (deleting desktop icon, tidying up the Start Menu items), I noticed that a new Start Menu group for PowerDesk 6 had been installed. That was very odd as the application was installed years ago, so why the new Start Menu group?

I deleted the Start Menu group and began digging around a little more and found this folder (the folder was new, i.e., it was not on the system prior to the Comodo 3.0.x installation):

C:\Windows\B93251B592094DAB867CAA98D91584CD.TMP

containing these files:

WiseData.ini
WiseCustomCalla5.dll
WiseCustomCalla8.dll
WiseCustomCalla10.dll
WiseCustomCalla13.dll
WiseCustomCalla16.dll
WiseCustomCalla17.dll
WiseCustomCalla.dll

The INI file contains detailed installation information about PowerDesk 6 (Wise installer information).

So, I deleted the entire folder and continued to dig a little before I rebooted and restored the disk images. But before I could reboot, I saw a flash on the screen that looked like something was being installed, and upon checking, all the items I deleted had returned.

I went through the deletion process several more times, and the items returned after every deletion (a small amount of time elapsed before the reappearance … I didn’t time it so I can’t be exact).

So, I rebooted, restored the disk images and made sure by observing over an extended period of time that the behavior did not exist on the restored images (without the Comodo installation). It did not.

So, I repeated the disk-image restoration / Comodo installation multiple times, and after each reboot following the installation, the Wise / PowerDesk 6-related issues return (PowerDesk 6 itself runs fine, by the way).

Searching the registry for this entry:

B93251B5-9209-4DAB-867C-AA98D91584CD

found keys with values referencing these installation file locations:

C:\Program Files\Common Files\Wise Installation Wizard
C:\WINDOWS\Installer\123832.msi

The registry shows the InstallDate of the application as 20051012 … quite a while ago.

So, I deleted the two files from the referenced locations, re-installed Comodo Firewall Pro, and though the behavior was essentially the same (i.e., an attempt to re-install PowerDesk was made), this time the process prompts for user interaction because the installer can’t find the location of the files (the ones I deleted). This allowed me to take a screen-shot which was previously impossible because the installation happened so quickly that only a flash (if anything) could be seen. The dialog box shown in the attached screen-shot is what greeted me upon logging in to my account. The dialogs can be dismissed, but they return upon re-boots.

One final note: it seems most odd that even with Comodo FP / D+ set as paranoid as they can be set, the installation of these PowerDesk items does not cause any prompting (i.e., the activity proceeded unimpeded).

Edit:
Added CFP_Setup_3.0.13.268_XP_Vista_x32.exe to the list of products tested. The same issues described above were also observed with this version.

[attachment deleted by admin]

2

Hallo BH-CFP,
Does PowerDesk 6 launches anything at boot-up?

3

No.

Unless, of course, you mean immediately after Comodo Firewall Pro 3.0.x is installed. Then the answer would be, “Yes, the Wise installer related to PowerDesk is launched at log-in”. :slight_smile:

4

I wonder if installing PowerDesk after comodo products trigger the same issues.

This is only my guess about the relation to comodo install and PD wise installer issue.
IIRC Comodo does not use msi installers so the only thing left is that PowerDesk and Comodo have some DLL in common.

There should be some app at startup to check PD installation integrity that somewhat notice something and trigger a reinstall.

Only way to shed more light in this issue would be to track comodo installers file and registry activities during installation.

Process monitor can do something like this but I guess the output will be quite verbose. :o

5

It’s a valid question, and one I’ve asked myself. I just haven’t acted upon it yet. Certainly, the goal is to find a solution that does not require uninstalling software prior to installing CFP, but getting at that solution may require this very thing.

I am familiar with SysInternals’ (er, MS’) Process Monitor. I already have it installed (as well as just about every other SI tool), so that is not a problem.

I’ve already run the Monitor on the processes involved, and it only created a 46000 event (filtered) / 298000 event log. :slight_smile:

I’m viewing it in a spreadsheet now, but I can’t guarantee I’ll find anything. I had already run a before / after Registry snapshot comparison, and it looked pretty normal to me.

We’ll see.

Thanks for responding.

6

One thing that could be realted is that CFP requires Visual C++ 2005 runtime (maybe it launch a silent msi install).
Did your system got Visual C++ 2005 runtime before installing comodo or could be PD build using VS5 runtimes?

Guess I was off-track I uninstalled CFP including VS5 runtimes. After reinstall the uninstall entry for VS5 C++ runtimes was nowhere to be found.

My memory failed me. :cry:

7

Sorry it took a while to get back here to post. I’ve been a little busy.

Anyway, I dug around for quite a few hours on and off and conducted some more tests.
For example, using Process Monitor, I created logs:

  • during a boot prior to installation of any Comodo product (file size: 122 MB)
  • during installation of 2.4.18.184 (file size: 13 MB)
  • during 2.4.18.184’s post-installation re-boot (file size: 137 MB)
  • during installation of 3.0.x (file size: 25 MB)
  • during 3.0.x’s post-installation re-boot (file size: 200 MB)

I restored pre-installation disk images between each test, of course. You can see by the file sizes of logs that I had plenty of fun digging through all that stuff. But it’s also pretty obvious that I wasn’t going to easily turn up anything that wasn’t obvious before starting the investigation.

However, I did dig a little deeper into how Windows Installer works, and at the very least I learned a few useful things I didn’t know before. Take for instance this blog post that seems very relevant, but perhaps not:

Why does Windows Installer start installing some other product when I try to
install or use a different MSI-based product?

Without reading any further, the title of the article states an MSI → MSI issue, whereas here
we have a Non-MSI (because your installer doesn’t appear to be MSI-based) → MSI issue. Perhaps that is really not a requirement as long as the impacted application uses Windows Installer.

Just as an FYI, the Windows System Event Viewer / Log showed this entry relative to each “unsolicited” installation of PowerDesk (meaning, the installations that automatically occur after installing Comodo Firewall Plus):

Source: MsiInstaller
Detection of product ‘{B93251B5-9209-4DAB-867C-AA98D91584CD}’, feature ‘Skins’ failed during request for component ‘{3207D1B1-80E5-11D2-B95D-006097C4DE24}’

For clarification:

{B93251B5-9209-4DAB-867C-AA98D91584CD} = PowerDesk
{3207D1B1-80E5-11D2-B95D-006097C4DE24} = C:\WINDOWS\system32\comcat.dll

NOTES

  1. Tests of PowerDesk installations on a clean (no CFP) computer did not produce the error message shown above. Tests included full uninstall / re-install and repair installations (disk images were restored between tests).

  2. Process Monitor’s logs of the PowerDesk installation tests mentioned in the preceding note, when compared to the MSI-related log events from the re-boot after installing Comodo 3.0.x, reveal that the “solicited” Windows nstaller installations’ logged events are significantly different than the events logged during the “unsolicited” installations, though obviously there is a lot of commonality as well.

  3. C:\WINDOWS\system32\comcat.dll:
    a) does not appear in the pre-Comodo-installation boot log
    b) does not appear in the post-Comodo-2.x-installation boot log
    c) does appear in the post-Comodo-3.x-installation boot log
    d) does appear in the log of the “solicited” PowerDesk repair installation
    e) the results (3a-3d) are not surprising and probably don’t necessarily reveal anything
    as I believe any time MSI-related processes are involved, you will find events
    related to C:\WINDOWS\system32\comcat.dll (unconfirmed).

While I found lots of other interesting things, there are too many to post and none led me to any conclusions, so to wrap-up abruptly, the following process:

uninstalling PowerDesk → installing Comodo Firewall Pro → re-installing PowerDesk

prevents the repeated “unsolicited” repair installations, and though this does not address the core issue (one that is evidently rare, and for me, beyond available time and knowledge to correct), it is the solution I’m using to continue testing Comodo Firewall Pro.

Thank you for your attention.

Edit:

Forgot to mention that I also set Windows Installer to verbose logging via Group Policy Editor (options voicewarmupx), and reviewed those as well during testing.

8

Sorry I wasn’t of help.

Since that file was not replaced/altered in any way the only thing that come to mind is that CFP needed a rule for that component.

When I thought about installing Powerdesk after CFP I guessed that the MSI rebuild was triggered by a version mismatch.
If that was the case installing Powerdesk after CFP should have been enough to have the MSI installer acknowledge the updated component.

but the error Detection of product ‘{B93251B5-9209-4DAB-867C-AA98D91584CD}’, feature ‘Skins’ failed during request for component ‘{3207D1B1-80E5-11D2-B95D-006097C4DE24}’
make me think about a CFP interference due to a missing rule.

Anyway my guess is inconclusive since IIRC the only setting that could have caused this is D+ “Block all unknown request if the application is closed”.
This setting is disabled by default and I don’t think you enabled it.

If anyone get this issue the only thing I could think of is to test if Disabling D+ permanently suppress the MSI rebuild actions.

Thanks for digging in this issue.