I recently took charge of a new system, it is a windows application written in C#, an installer (.MSI) file is created for its distribution. When I install the software it installs properly but it crashes on start. Then if I run the .exe file once for the application, the installed software starts working.
My observation is that .EXE installs some missing bit which is required by .MSI file. Is there a way I can find what files are missing in .MSI file ?
UPDATE on 09-08-2014:
I have found WER4A29.tmp.WERInternalMetadata.xml file which talks about System.Net.WebException
-<ProblemSignatures>
<EventType>CLR20r3</EventType>
<Parameter0>test.exe</Parameter0>
<Parameter1>1.0.3.33</Parameter1>
<Parameter2>53dca4f6</Parameter2>
<Parameter3>System</Parameter3>
<Parameter4>4.0.30319.18408</Parameter4>
<Parameter5>52311185</Parameter5>
<Parameter6>21b0</Parameter6>
<Parameter7>1fb</Parameter7>
<Parameter8>System.Net.WebException</Parameter8>
</ProblemSignatures>
First run an admin install via command line (cmd.exe) to extract the files from your MSI:
msiexec /a File.msi
Then inspect the extracted files to determine if there are configuration EXE files that perform configuration tasks. Determine what configuration files are there, if any. For example INI or XML files. Check for per user / user profile files.
In case you don't have the tool to view the MSI file, get hold of Orca or install a trial version of a commercial packaging tool. You will need this to see what is happening inside the MSI file. If you list the content of the Custom Action table there may be clues there as to what is going on. Also look in the Registry table for per user data to go into the registry. Debugging an MSI properly takes a lot of domain knowledge, but looking through it like this is useful too. Just post follow-up questions. I assume you have the Wix source code too?
To debug the application launch use Process Monitor (procmon.exe) to determine what is going on during the successful launch. The logging is a bit verbose, but with flags you will get to narrow it down.
- For native applications (Win32, or non-.net), I like to use Dependency Walker (depends.exe) too. It can be used for .NET too, but I find it less useful. I am not aware what the best dependency scanner for .NET is at the moment.
If manual debugging fails, several tools used for application repackaging are able to scan the system and determine the state before and after something is done and capture it as a list of differences. Advanced Installer's trial version should be able to do this. With some technical insight you should be able to identify what is needed from the diff image.
The .msi file is the installation set-up it include the installation script and the actual executable .exe file and other required dlls and configuration files.
I think the issue is with how the set-up is created. when you start the application after installation it is not performing the start up tasks like configuration of environment.
And the when you run the .exe it takes care of these configruations by it self.
I suggest that the testing of setup files .msi files and its generation scripts should be revisited.
