Another reason a custom action may not run is because the custom action function isn’t exported. This may not be common in most patch build systems, but could arise during authoring or if a binary wasn’t updated in the Binary table. You should expect to find a log line similar to the following.
MSI (s) (1C:C4) [16:57:23:258]: Doing action: CA_QuietExec_Post_InstallFiles
Action start 16:57:23: CA_QuietExec_Post_InstallFiles.
MSI (s) (1C:10) [16:57:23:274]: Invoking remote custom action. DLL: C:WINNTInstallerMSI140.tmp, Entrypoint: QuietExec_Post_InstallFiles
MSI (s) (1C:C4) [16:57:23:274]: Note: 1: 1723 2: CA_QuietExec_Post_InstallFiles 3: QuietExec_Post_InstallFiles 4: C:WINNTInstallerMSI140.tmp
MSI (c) (58:94) [16:57:23:289]: Font created. Charset: Req=0, Ret=0, Font: Req=MS Shell Dlg, Ret=MS Shell Dlg
Error 1723.There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action CA_QuietExec_Post_InstallFiles, entry: QuietExec_Post_InstallFiles, library: C:WINNTInstallerMSI140.tmp
To perform a quick sanity check on the DLL, find the custom action name in the CustomAction table using Orca and look at the Source column for that custom action. For type 1 custom actions the Source column value is the key into the Binary table for the DLL. Don’t forget that the Type column might also include flags for scheduling, return, and in-script options.
Now find that ID in the Binary table using Orca and double click the Data column. Select “Write binary to filename”, type or browse for a filename, and click OK.
Load that file in depends.exe or run dumpbin.exe /exports on it to see if the custom action function is truly exported.