Overall: I like Tom Blodget's advice here to find dependencies and runtimes. Below are some detailed, technical options to determine what is going on with problem applications. Assembled in a hurry.
Clean Virtual: And obviously take Lex Li's advice (above comment to your question) to set up your application manually on a clean virtual for QA and testing and to determine deployment requirements in an "iterative fashion".
Check-List: And just for the record: a general-purpose check-list for application launch problems (that somebody downvoted for some reason, let me know what errors you find in there maybe? I am a deployment specialist not a coder - it is more of an "ideas" list than a true checklist).
UPDATE - September 2018:
Debug Binaries - Launch Sequence Debugging: You could insert a message box early in your application launch sequence and slipstream
the debug binaries into your setup, install it, and then attach the
debugger to the application's message box on launch in order to step
through the launch code? (set a breakpoint). Now you can debug, provided your EXE gets off the ground at all.
Maybe check this nice Advanced Installer Video Tutorial for this "attach debugger approach". It shows the same approach for custom
action code. The procedure is the same for launching applications.
Just attach to message box and set breakpoints.
Note: Obviously remember to recompile with the release binaries once you know what the problem is - and retest launching. Debug
binaries are not redistributable - they bind to debug dlls only
installed by the MS SDK. Normal PCs will not (normally) have these
debug dlls.
Visual Studio Modules View: I have seen it recommended to run in debug mode in Visual Studio. Run project interactively: Debug => Start Debugging, and then go: Debug => Windows => Modules in order to get a list of what has been loaded for the application to run. I am not sure, frankly, if this gives you all types of dependencies. There can be many different types as explained here in the Dependency Walker help file. I tried to pick the brain of our Hans Passant on the issue :-), but it is probably too detailed to go into.
Dependency Walker: This is an old Windows SDK tool. It is very outdated by now - over 10 years since the last update I think. It was the old warhorse to rely upon, but does not work great for newer binaries. It does not support WinSxS dependencies (side-by-side win32 assemblies) or API-Sets.
- I still use it to remind myself of the "module search order". With the tool open:
Options => Configure Module Search Order.... Windows locates files / modules in a search order like that - and with differences between different OS versions.
- It is certainly outdated, but it is at least a reminder of how folders are scanned in Windows - and every Windows version is different - especially with manifests.
dumpbin: Another old work-horse from the Windows SDK (search under %ProgramFiles(x86)% on a system with Visual Studio installed). This is a command line tool. For masochists :-). I honestly do not know if it features proper support for the newest binaries, but it appears maintained (unlike Dependency Walker).
ProcMon (Sysinternals): This is the tool that people swear by when it comes to solving the hard dependency issues. Quick mock-up sample. The real deal - a spyglass for whatever is really happening under the hood. I am not expert at its use, but it is always enlightening to look at the output for ideas. Missing COM server registration etc...
ProcessExplorer (Sysinternals): Please check this answer.
Fuslogvw.exe: Does Fuslogvw.exe tell you anything? (.NET assembly binding failures).
Dependencies.exe: Maybe you can also try this new, open source rewrite of Dependency Walker (that old SDK tool mentioned above) partially done in C#: "Dependencies.exe". This tool is quite unfinished and doesn't feature all functionality from Dependency Walker (I can't see any profiling features for exe files), but it has support for API-sets and WinSxS dependencies - or side-by-side Win32 assemblies (which is missing from Dependency Walker). I haven't tested it enough to really recommend it - but it is open source and hence inspectable. I have contacted the author about an issue where the bundled peview.exe is identified as malware. The author quickly came back to explain. Recommend you just delete peview.exe before starting to use the application.
NDepend (wikipedia): A tool I am afraid I don't use, but please check this answer (do check).
Deployment Tools: Various Deployment Tools besides Inno setup (list view, core tools only).
Some Links:
.NET
