Another common reason exists for binary custom actions: missing dependencies.
When a binary custom action appears to work on your developer machine - and you
really shouldn't test on your developer machine unless you're always
changing
the package code - but not on a test or client machine, this is likely the
reason. If you find that setting the
MsiBreak environment variable doesn't prompt for a debugger, this only
strengthens the case of missing dependencies.

Run depends.exe on your custom action server .dll file or
.exe file on the machine where the custom action doesn't appear to run.
Missing dependencies will cause the dependency walker to display an error
dialog, an error to be printed in the bottom message window, and a yellow
question mark icon next to the missing dependency in the dependency navigation
tree. Common missing dependencies are msvcr71.dll and msvcr80.dll
- Visual C++ 7.1 and 8.0 runtimes, respectively - and pgort80.dll - a
library linked into your executable when you instrument your project in Visual
Studio 2005 for
profile-guided optimizations. With missing implicit or forward dependencies,
your executable cannot be loaded. You might instead consider statically linking
what dependencies you can, such as the C runtime (CRT).

Another common mistake is when executable custom action servers depend on
libraries to be installed, but the files haven't actually been installed yet.
Files are installed during
InstallFinalize after
InstallFiles has scheduled files to be installed via the
installation script. You might consider scheduling
InstallExecute or
InstallExecuteAgain after InstallFiles if your immediate custom actions
require that dependencies to be installed are actually installed first.