Our Windows application is crashing, and when the user acknowledges the crash dialog, notices that the msi for a related product is starting, as though trying to repair some corruption caused. As I understand it from the person that encountered it, our application doesn't have any mechanism to control this other application's installer. Is this operation possible? If so, what part of the operating system controls this? If so, is there a security risk?
Asked
Active
Viewed 36 times
0
-
See this other question: https://stackoverflow.com/questions/5501028/how-can-i-determine-what-causes-repeated-windows-installer-self-repair/6066263#6066263 – StayOnTarget Jul 12 '17 at 14:04
1 Answers
1
That dialog that starts up sounds like a repair, so there should be a MsiInstaller entry in the Application Event log. This should identify that related product that's being repaired and give you the component guid of the thing in that related product that appeared corrupted.
There are several entrypoints to the repair functionality. File extension use, COM object activation, some shortcuts, some use of typelibs too I think. These basically use MsiProvideComponent() which will reinstall the containing feature if it finds a corrupted component.
If I had to guess, I'd look at things like the two related products installing the same things (such as files) inconsistently and breaking the shared component rules; your app removing or altering a file or registry data that was installed by the other product. But find those MsiInstaller repair entries, and identify the component ID and see what file or registry item it is, that should give you a clue where to start.
PhilDW
- 20,260
- 1
- 18
- 28