The CustomAction will in error execute during any repair (and self-heal) and reset the registry keys due to the lack of conditions. Looking at the InstallExecuteSequence table the CustomAction is set to run at sequence # 6260, however no conditions are set for it. The accuracy of Process Monitor has given us a very precise timestamp (972791 are the last digits) and we can easily see that during the time-slot of 12:04:11 there are 7 different CustomActions occuring, however only two occur within the reach of 12:04:11:97~.Īs the FindfxViewVersion1 is actually executed after the timestamp, we can safely assume that it is the FindFrameWorXVersion that is setting the registry key in question.ħ. Review the log-file generated during the installation and find the corresponding timestamp (12:04:11,972791 is the time in the screenshot). Once the applicable registry key is found and the RegSetValue is located the timestamp is located.Ħ. Therefore you can exclude this and avoid a lot of traversing through unnecessary finds.Īs you can see, searching can take a bit of time ĥ. For example, RegOpenKey isn’t something that corresponds to the operation we are looking for. As we are looking for when the registry key is updated, certain operations aren’t applicable. Search for the registry key (or file if that is your case). Once the installation is completed, stop the monitoring within Process Monitor.Ĥ. Msiexec /i install.msi /qb TRANSFORMS=install.mst /l*v install.logģ. A sample command-line could look like this Initiate the installation using verbose-logging.
No filter needs to be applied immediately.Ģ. Fire up Process Monitor and let it monitor. How do you identify a CustomAction which sets a registry key ? Using timestamps in Process Monitor of course!Ī fare warning before you start the steps A lot of memory will be required due to the capture of Process Monitorġ. Infact they started at 5750 and stopped at 6720 in the InstallExecuteSequence table. Unfortunately, none of the CustomActions had very descriptive names as to which one would touch this key and there were a lot of them. "Proficy Machine Edition (TM)"="v5.50 Build 3655" Registry key that was wrongfully set looked like this (when it was not correct) The registry-keys could not be located within the Registry-table and there was a ridiculus amount of CustomActions. While troubleshooting an installation that seemed to be running a specific CustomAction once a self-heal was initiated and in error set a few registry keys to an odd-value. SysInternals has for a long time provided us with the valuable tool Process Monitor, which everyday presents new use cases.
0 kommentar(er)
