MsiExec.exe causes exception on CA with managed code

[LaserVision]

When I use a CA with managed code I get a nasty exception with the MsiExec.exe, see attachment. I have seen it working on a new installed system, but on a running systems I got into this problem on at least three different computers. The C# code in the managed dll can not be the problem, it's too simple to break and both methods are with inside a try-catch block, I hope you agree on this:

public class Helper
{
	public Helper() { }

	public static string ToUpper(string value)
	{
		try
		{
			if (value != null) { return value.ToUpper(); }
		}
		catch { }

		return String.Empty;
	}
	....

I tried a workaround where I tried to increase the assembly trust in the .NET Framework 1.1 Configuration. This is obviously not possible on the setup.exe but strangely the setup worked after that - BUT not always. I guess this has nothing to do with it.

Any ideas?

My system configuration:
- Windows XP SP2
- NET 1.1 with SP1 installed
- Managed code dll written in C# with .NET 1.1
- Disabled code optimization in the project setting of the managed code dll
- Set the location of the custom action to be "Stored in the Binary table"
- Install UI Sequence "After LaunchConditions", Condition "Not installed"

When I start the setup and I have no exception (later, on the same machine, killed all MsiExec, done my "workaround") I see three MsiExecs in the Taskmanager! That makes me wonder how my dll is called by the setup. Is there some kind of resource synchronization problem depending which MsiExec is called first? Maybe the sequence point for the CA is to early in the process but I want to call this only once before the dialogs are shown.

I hope someone could help me...

Ciao
Toni

[Christopher_Pai]

I'm curious why you are still on .NET 1.1. Personally, there are way too many feature in 2.0 ( generics for starters ) that I can't see myself living without.

I'd switch to .NET 2.0 and checkout DTF for your CA hosting/interop mechanism. It's far superior to InstallShield's managed custom action pattern.

[LaserVision]

I would rather like to go directly to the latest .NET but we are in a transition state. Our main software is still in VB6 and when it was decided to move to .NET they picked 1.1. Until I haven't finished the application (still a couple of months work ahead, changing some basic thing, moving to C#, ...) we are stuck to this .NET version...

Still the problem is why this message box pops up when the setup.exe is calling the dll.

I don't think that writing the dll in .NET in 2.0 is an option. I only can assure that 1.1 is installed...

[MichaelU]

Is there anything in a verbose MSI log around this action that sheds some light on this? The managed-code custom action support tries to be rather good about logging information, but as I've not encountered this error, I'm not sure whether there will be any useful information.

[LaserVision]

Added "/l*vx C:\log.txt" to "MSI Command Line Arguments" and the result was

[CODE]...
MSI (c) (30:94) [09:49:32:328]: Doing action: MakeMachineIdUpperCase
Action 09:49:32: MakeMachineIdUpperCase.
Action start 09:49:32: MakeMachineIdUpperCase.
MSI (c) (30:94) [09:49:32:359]: Creating MSIHANDLE (26) of type 790542 for thread 916
MSI (c) (30:EC) [09:49:32:359]: Invoking remote custom action. DLL: C:\DOKUME~1\LV1126\LOKALE~1\Temp\MSI51.tmp, Entrypoint: m1
MSI (c) (30:EC) [09:49:32:359]: Lost connection to custom action server process. Attempting to regenerate.
MSI (c) (30:68) [09:49:32:359]: Cloaking enabled.
MSI (c) (30:68) [09:49:32:359]: Attempting to enable all disabled priveleges before calling Install on Server
MSI (c) (30:68) [09:49:32:359]: Connected to service for CA interface.
MSI (c) (30!74) [09:49:32:421]: Creating MSIHANDLE (27) of type 790531 for thread 1396
MSI (c) (30!74) [09:49:32:421]: Closing MSIHANDLE (27) of type 790531 for thread 1396
MSI (c) (30!74) [09:49:32:609]: Creating MSIHANDLE (28) of type 790531 for thread 1396
MSI (c) (30!74) [09:49:32:609]: Closing MSIHANDLE (28) of type 790531 for thread 1396
MSI (c) (30:EC) [09:49:58:421]: Closing MSIHANDLE (26) of type 790542 for thread 916
Action ended 09:49:58: MakeMachineIdUpperCase. Return value 1.
...[/CODE]

Hope that this helps you to get an idea, Michael.

Checking the forum shows that this problem exists at least since 2005, also 2007 and 2008 someone got into the same situation.

So, what I would like to know is - because I assume that this will not be fixed in the near future - is this a general problem calling any kind of dll? If I would replace the .NET dll with a custom dll would I get the same trouble?

Can I achieve following two things with IS build in mechanism?
1. I want to check if volume "D:" exists, to change a default path. The volume might exists but could be a CD, but I want to be sure that I can use it to write to it.
2. I want to write to the registry a string in upper case.

Thx in advance
Toni

[LaserVision]

Added "/l*vx C:\log.txt" to "MSI Command Line Arguments" and the result was

[CODE]...
MSI (c) (30:94) [09:49:32:328]: Doing action: MakeMachineIdUpperCase
Action 09:49:32: MakeMachineIdUpperCase.
Action start 09:49:32: MakeMachineIdUpperCase.
MSI (c) (30:94) [09:49:32:359]: Creating MSIHANDLE (26) of type 790542 for thread 916
MSI (c) (30:EC) [09:49:32:359]: Invoking remote custom action. DLL: C:\DOKUME~1\LV1126\LOKALE~1\Temp\MSI51.tmp, Entrypoint: m1
MSI (c) (30:EC) [09:49:32:359]: Lost connection to custom action server process. Attempting to regenerate.
MSI (c) (30:68) [09:49:32:359]: Cloaking enabled.
MSI (c) (30:68) [09:49:32:359]: Attempting to enable all disabled priveleges before calling Install on Server
MSI (c) (30:68) [09:49:32:359]: Connected to service for CA interface.
MSI (c) (30!74) [09:49:32:421]: Creating MSIHANDLE (27) of type 790531 for thread 1396
MSI (c) (30!74) [09:49:32:421]: Closing MSIHANDLE (27) of type 790531 for thread 1396
MSI (c) (30!74) [09:49:32:609]: Creating MSIHANDLE (28) of type 790531 for thread 1396
MSI (c) (30!74) [09:49:32:609]: Closing MSIHANDLE (28) of type 790531 for thread 1396
MSI (c) (30:EC) [09:49:58:421]: Closing MSIHANDLE (26) of type 790542 for thread 916
Action ended 09:49:58: MakeMachineIdUpperCase. Return value 1.
...[/CODE]

Hope that this helps you to get an idea, Michael.

Checking the forum shows that this problem exists at least since 2005, also 2007 and 2008 someone got into the same problem.

So, what I would like to know is - because I assume that this will not be fixed in the near future - is this a general problem calling any kind of dll? If I would replace the .NET dll with a custom dll wouild I get the same trouble?

Can I achieve following two things with IS build in mechanism?
1. I want to check if volume "D:" exists, to change a default path. The volume might exists but could be a CD, but I want to be sure that I can use it to write to it.
2. I want to write to the registry a string in upper case.

Thx in advance
Toni

[LaserVision]

The more I try the stranger it gets.

I was able to get rid (currently) of the MSIExec exceptions but this was not straight forward: I have the strange feeling that this problem occurs when the UI is visible and the CA should be working in the background. Therefore I executed the first CA before the UI starts, but the second I had no clue where to put it - tried several possibilities...So, as a hack I created a InstallScript, great :mad: (I wanted to get rid of this ...)

This still leaves me all in doubt if the solution is fool proof in all cases...

Found two articles that are saying this kind of CA is a bad idea:

• Custom Action Guidelines and
  
• Don't use managed code to write your custom actions!
  

I wonder why this is sold as major feature for IS if in the end it useless.

Anyone experience with Wix? Couldn't test it because you have to have at least VS2005 installed - still not finished :mad: Will try it later at home, but anyone: Can I make my CAs with this one?

Bye
Toni

[MichaelU]

I'm not too familiar with that error, but it sounds likely to be a machine-specific configuration problem -- the log doesn't even show lines that should occur from the native wrapper before the managed code itself is loaded. And thus yes, it's likely to be a problem with just about any custom action. Can you test the install on another machine which was not built from the same base image?

[Christopher_Pai]

The blogs you quote are only telling half of the story. It's old outdated information.

The solution to managed CA woes is WiX's DTF and it doesn't cause you to leave InstallShield. It allows MSI/InstallShield to treat managed code as C++ style custom actions.

The problem is you refuse to take a dependency on .NET 2.0 which is required by DTF.

I hate to tell you so, but I already told you what you need to do. So either go back to InstallScript, write it in C++ or adopt .NET 2.0 and use DTF.

[LaserVision]

Easy Christopher,

I appreciate your comments pointing me out to WiX and DTF, probably the solution to my problem - haven't heart of WiX before and made not the connection that DTF has something to do with it, so thank you for that.

But as I wrote earlier we are still bound to .NET 1.1 take this as a fact which I can not change in the short run - I might add that our Software must still run on several NT4 systems (end of story of using 2.0). So I hope you agree that installing 2.0 only for install reasons is not an acceptable solution. I know 2.0, 3.5 and know that 1.1 has a lot of other deficiency, e.g. I waisted a lot of time finding memory leaks.

Toni

[nitsev]

Laservision,

I would say that from my experience that using Custom Actions does not always work as expected. Errors usually occurs on systems that are to be updated and not on a clean install. This is because the first installer many times leaves one or more instances of msiexec running. I have no idea why. When I run an upgrade the installer (msiexec) sometimes terminates when the first CA is executed. If I kill all msiexec before trying to upgrade it usually works fine. No useful info in the verbose log. The type of error can vary from the standard dialog saying that msiexec just stopped working to DEP (Data Execution Prevention) errors that causes msiexec to terminate. I don't know if this is a MSI or InstallShield problem but I'm leaning toward MSI. Also, I am not using manages code but a standard Win32 MSI dll.

[LaserVision]

@ nitsev
Thank you for your comment. Just to verify, did you experienced similar problems with a standard Win32 dll or did you get rid of them with the standard dll? Fear the first...

I agree that this problem tent to be a caused by the MSIExec by looking at the error message caption. But the question is why multiple MSIExec are running, ¿is this valid? If yes probably the MSIExec was not designed to be used this way. I am really scared what the next tests will show up, probably I have to use another more evil trick...

@ Michael
I want to add two more things:

• If this error occurs the setup.exe stays in the Taskmanager after canceling the setup.
  
• The problems occurred on different machines, one where the setup was used to update the current version and one which was new and the setup was run for the first time. Both were XP machines, but we don't have a "base image". Probably the same installation CD was used - I can't say for sure - but definitely they are not based on a pre-installed image.
  

The msiexec.exe is version 3.1.4000.1823 from 2005-05-03 12:58:36 on one of the machines, I have the same one on my PC...

Bye
Toni

[nitsev]

LaserVision,

I am using a standard Win32 MSI DLL and that's all I've ever used.
I don't really know if a running msiexec indicates a problem, all I know is that 9 times out of 10 when I run into problems there were running one or more instances when I launched the setup, which then fails. I notice that when I run my setup.exe it launches no less than THREE instances of msiexec.exe. One is run as SYSTEM and the other two as Administrator. I tried logging everything msiexec.exe does on my machine with process monitor (www.sysinternals.com) but can find nothing that indicate what is causing my problems. According to the MSI log the error occurs when a custom action is fired. This is part of my log
----------------
MSI (c) (F4:8C) [15:40:49:921]: Invoking remote custom action. DLL: C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\MSI1B9.tmp, Entrypoint: MyCostFinalize
MSI (c) (F4!50) [15:40:50:374]: Doing action: CostFinalize
MSI (c) (F4!50) [15:40:50:374]: Note: 1: 2262 2: Patch 3: -2147287038
MSI (c) (F4!50) [15:40:50:405]: Target path resolution complete. Dumping Directory table...
MSI (c) (F4!50) [15:40:50:405]: Note: target paths subject to change (via custom actions or browsing)
MSI (c) (F4!50) [15:40:50:405]: Dir (target): Key: TARGETDIR , Object: C:\
...
...
MSI (c) (F4!50) [15:40:50:437]: Dir (target): Key: _2F7946307A534E73B52854F6CF9BEB8A , Object: C:\Program Files (x86)\Prodacapo\Server\scripts\Common\en\
MSI (c) (F4!50)
-------------------

I can find nothing on Acressos site about this error. Also there is an Application Error item in the event viewer with ID 1000
"Faulting application msiexec.exe, version 3.1.4000.3959, faulting module unknown".

other instances of msiexec are left in the task manager once the setup has terminated. Once I kill the current msiexecs and restart the installer, everything works fine.

Go figure? :confused:

[Christopher_Pai]

Multiple msiexec is not uncommon. You have to remember that the client / server / custom action hosting can be in different processes with different priv contexts. You also have to remember that msi can spin up on demand and run for a period of time ( I think it's 10 minutes if I recall ). You can get into really ugly race conditions when you tatoo the process with the 1.1 CLR by things like managed custom actions and ngen type stuff.

I know I'm not telling you what you want to hear but the reality is your going to be pulling your hair out for a long time if you are trying to support NT 4.0 and .NET 1.1. Let's not even mention the issue that NT 4.0 isn't supported and can't be patched anymore. Basically a security nightmare waiting to happen.

So sorry, but my suggestion is still to move your platform baseline components up to something a bit more modern and all of these problems you are facing will easily go away. It's not just for the installer, it's for your product as a whole.

[MichaelU]

My point about not using the same base image is to try to avoid any identically bad environments. If you have a clean XP virtual machine image with nothing or nearly nothing installed, that would be ideal for testing, or at least for cross-referencing. As for setup hanging around, once MSI does something this unusual, I'm not prepared to guess what the implications are. Has anyone found out how to make a previously-good machine show the "lost connection" behavior? Windows Installer does use multiple instances of msiexec in order to run different parts of the install; on NT you should expect to see at least one each for the UI and Execute sequences, as well as one for each executing custom action. As custom actions generally execute serially, there's commonly no more than three, but that's not a hard maximum.

In another thread such as http://community.installshield.com/showthread.php?p=428890 you can see a lot of log messages all starting with "InstallShield:" between the start of the custom action and (in this case) its failure. We see none of that here, and I think it's caused by (rather than causing) whatever is breaking. As you noted, the MSI "lost connection" behavior dates back to at least 2005, which is well before we had managed code custom actions, so they are merely part of your scenario, and not likely part of the root cause. So while I think Chris's points about DTF and modern OS requirements are well intentioned, they also do not address the root problem, and would likely share the same symptom.

[Christopher_Pai]

My thought behind modern OS requirements is to just move on and not even try to get NT 4.0 / 1.1 to work. I know, that's a bit of an ivory tower position but let's face it... that's Microsofts answer to problems these days.

It's just too expensive to be doing support on such old stuff. Anything prior to Windows 2000 and .NET 2.0 I don't even touch anymore.