0

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>
user11
  • 301
  • 1
  • 3
  • 11
  • Before you try anything else, try **running the MSI file** from an **elevated cmd.exe** session. There may be design problems with the MSI. – Stein Åsmul Aug 08 '14 at 16:25
  • Just in case there's a repair going on, look in the Application Event Log for MsiInstaller entries that refer to missing components. Unless the exe is adding something, it might be that using that shortcut does a repair, because that's what MSI shortcuts do. – PhilDW Aug 08 '14 at 17:28
  • I'd start by running the executable inside a debugger so you can see where the crash occurs. – Harry Johnston Aug 08 '14 at 22:57
  • Just a shot in the dark: are you using .NET help components or COM objects for Microsoft html help or Internet Explorer Active X? Also have a look here: http://stackoverflow.com/a/3220025/129130 – Stein Åsmul Aug 09 '14 at 10:09

2 Answers2

0

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.

Community
  • 1
  • 1
Stein Åsmul
  • 34,628
  • 23
  • 78
  • 140
  • Hi Glytzhkof Thanks a lot for detailed response. I have found WERInternalMetaData file (created after application crash) which says there is a System.Net.WebException. Installer uses a web service that deals with the licensing issue. How can I check if the software is connecting to server (hosting webservice) properly ? – user11 Aug 09 '14 at 04:02
0

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.

Mudasar Rauf
  • 516
  • 7
  • 18