Runtime Error in setup script (msi.dll - not found)

[vartom]

Dear support,

I've got the following:

***********
Runtime Error in setup script
Source file: "..."
Line Number: 68684
Library Not found: msi.dll
***********

I've researched this issue for days now but I couldn't find an answer even though I was looking at your Technical Support forum as well...

You can see, that our project has a lot of line of code.
From one of your previous post I figured it out, that the 'Line Number' is the number of the line in the main script, after the include scripts have been merged.
The problem is that our main script contains no more than 2500 lines, so the rest of the lines are the other included scripts.

My question is how can I determine exactly where the exception was thrown (in which include script, which line)? Is there a tool which can merge all my included scripts to the main one?
And also do you have a ruff idea how the 'msi.dll' can't be found?

All this is happening during UN-INSTALLATION (from Control Panel, Add/Remove programs) process...
The un-installation itself is starting in a strange fashion, the MAINTENANCE variable does not recognized that the product is installed, and it's value is FALSE instead of TRUE (we know this from the logs).

I must mention that this happens on some of our client's machine, so it's pretty difficult for us (developers) to identify the actual cause of the error.

Thanks in advance for your assistance.


PS: Just this morning I got this error from another client:

***********
Runtime Error in setup script
Source file: "..."
Line Number: 35330
Unable to obtain command headers. Please rebuild you project.
***********

Is this mean that during building or bagging the project something went wrong? Do an actual "rebuild" as the message suggests solve the problem, or should we investigate this more deeply?
This is happening during INSTALLATION...

(We are using InstallAware 11, and I'm afraid at the moment to update it is not an option . )

[FrancescoT]

Dear User,

could you please post the link where I can download your installer?
If you prefer, you can send me an email with the download link.

I'll try to check it.

Regards

[vartom]

Hi Francesco,

Sorry for the late response, but I was waiting for a response (logs and environment information) form the client where the error occurred.
We add a lot of log messages to the code, and find out which line of code throws the exception: Get Installed State ... is the culprit.
This is happening under WIN8 Pro (without any patches).

Do you have an idea what can I do to fix the problem?


Previously we had a similar issue with another function, which crashed on certain computers: Get System Setting Language.
This call was replaced with this one: Call DLL Function Kernel32.dll->GetSystemDefaultUILanguage, and after that the crashes disappeared from those computers as well.

I was thinking, if there is maybe a similar call, that I should use to replace the "Get Installed State" command, if no other option is available?

Thanks for your assistance.

[FrancescoT]

Dear Vartom,

Do you use any localization with the project?

Regards

[vartom]

Yes, we do.

Also we have several embedded installers, which got installed/uninstalled by selecting/un-selecting a component.
And we are getting the install state for those components when the function fails.

[FrancescoT]

Dear Vartom,

Are you sure that the localized resource strings currently used by your project have been updated accordingly (they include the most recent changes you may have applied to your script(s)?

I may suggest to try to export and then to import back in your project the localized resource strings used.

Regards

[vartom]

Hi Francesco,

I think there is a misunderstanding here.
We do use localized resources, and they do cause some other kind of error if they are not updated correctly, but I don't think that's the case here.

When the exception occurs the client didn't change the culture setting, the default language was used (with the original scripts). We don't have a problem with the languages at all.

At the moment, not the Get System Setting Language function crashes, but the Get Installed State.
More precisely, what fails (just on a few machines, on other ones is working), is this line of code : Get Installed State for {3EB4E0FD-CFE6-469D-AECC-8B0B7B39CA68} into Variable SETUPTYPE_LMM.

I don't understand why that is happening, so basically I'm looking for a possible explanation here.
And if there is non what you can think of, I'm also opened to change that line of code to something else, which does the same, but differently. For example I found this post: viewtopic.php?f=2&t=2766.

Based on what I read there, would it be correct to change the above mentioned line of code with the below ones, and get the same result? (If the answer is NO, can you please correct this code part, or provide some other way to achieve our goal?)

Read Registry Key HKLM\\{3EB4E0FD-CFE6-469D-AECC-8B0B7B39CA68} into SETUPTYPE_LMM
After that check weather $SETUPTYPE_LMM$ contains something or not.
If YES than the program was installed, otherwise was not.

Thanks for your assistance.

[FrancescoT]

Dear Vartom,

you can also use the approach described by the link, in place of that command(If I am not wrong, that command should do something similar internally).

Anyway it may be interesting, if you could provide some more details about the machine where you found such error.
I would to see if I am able to replicate the same.

Regards

[vartom]

Sorry Francesco,

I couldn't find out any more specifics (just what you can find above) about the machine, where the problem first occurred.
But since I don't have any better ideas, I'll try to change the code based on the other post.

I don't know when that will happen (because we are in a middle of a release, and I have other important issues), but I'll let you know if it worked out or not.

Thanks.

[vartom]

Hi Francesco,

I'm back to this issue again. I'm still trying to fix it, but a new issues kept me from finishing it.
I managed to reproduce the issue on one of my Oracle VM Virtual PC (WIN7 64-bit - after a new installation).

I successfully switched the Get Installed State with Check Registry + verifying the returned value, so that not an issue anymore. This won't cause the runtime error anymore...
But now my installer is crashing with the same message (Runtime error / msi.dll not found) on a totally unexpected place.

Here is how I can reproduce the issue:

1. Install the product, everything work out as expected, NO ERROR.
Here the part of the log (IA related):

Verbose logging started
----------------------------------------------------
Installer : Start
CMDLINE : /m="C:\Temp\SetupO~1.EXE" /k=""
LANGUAGE: English
ADVERTISE: FALSE
LOGGED :
MAINTENANCE : FALSE
MODIFY : TRUE
NEEDSUPGRADE : FALSE
NEWINSTANCE : FALSE
REBOOTCOMPUTER : FALSE
REBOOTNOW : OK
REMOVE : FALSE
REPAIR : FALSE
AFTER_REBOOT : FALSE
EXEDIR: C:\Users\user\AppData\Local\Temp\mia8562.tmp MSIFILE : C:\Users\user\AppData\Local\Temp\mia1\SetupOffice.msi
ROOTDIR : C:\Users\user\AppData\Local\Temp\mia8562.tmp----------------------------------------------------

2. I'm going to Control Panel/Programs and Features, trying to uninstall the product.

Here's the same log part:

Verbose logging started
----------------------------------------------------
Installer : Start
CMDLINE : REMOVE=TRUE MODIFY=FALSE
LANGUAGE: English
ADVERTISE: FALSE
LOGGED :
MAINTENANCE : FALSE
MODIFY : FALSE
NEEDSUPGRADE : FALSE
NEWINSTANCE : FALSE
REBOOTCOMPUTER : FALSE
REBOOTNOW : OK
REMOVE : TRUE
REPAIR : FALSE
AFTER_REBOOT : FALSE
EXEDIR: C:\ProgramData\{FBA686E9-64F4-40CB-8E95-66BB923BBA52} MSIFILE : C:\Users\user\AppData\Local\Temp\mia1\SetupOffice.msi
ROOTDIR : C:\ProgramData\{FBA686E9-64F4-40CB-8E95-66BB923BBA52}----------------------------------------------------

The setup is running successfully until reaches the Apply Uninstall command, than crashes with the "Runtime error / msi.dll not found" message.

The main difference that I noticed between the two logs, are with the CMDLINE, EXEDIR, ROOTDIR and the MAINTENANCE/MODIFY values.
As I previously mentioned the uninstallation is starting in a strange fashion, the MAINTENANCE variable does not recognized that the same product is installed, and it's value is FALSE instead of TRUE (on this virtual machine ONLY). If I run the same installer on my dev. PC everything is working as expected, the MAINTENANCE will be TRUE during uninstallation, and also the Apply Uninstall command does NOT crash.

3. If I start the setup from Control Panel/Programs and Features but this time to REPAIR/REAPPLY/ADD FEATURE installation, the setup will also crash, but this time at the Apply Install command, error message is the same.

Do you have any idea what is this about?
What can I do, is there a way that I can fix this?
Can I replace these command with something else? (I don't think that is plausible this time, right?)

4. If I run the executable to REMOVE/REPAIR/ADD FEATURE, and not start it from Control Panel/Programs and Features the setup will NOT crash. (That is not a user-friendly way to uninstall/repair the product. The users will not think of this scenario, they will always try to uninstall the product from Control Panel/Programs and Features !)
This is again can be a useful information. What is the main difference that you can think of between those two scenarios??

ALSO: I set the LOGGED variable from code, so that I trace everything. Durring installation the log is successfully saved with every information in it.
But durring REMOVE/REPAIR the log file only contains a few line, and nothing will be placed inside the < m y a h > node, basically will be empty. So I know nothing what could have caused the crash...
This is its whole content:
< / R u n S c r i p t >
< F r e e >
< / F r e e >
< C a c h e d S u p p o r t D i r >
< / C a c h e d S u p p o r t D i r >
< / I n s t a l l A w a r e >

msi.dll exists in C:\Windows\SysWOW64\ folder.

I'm just pinpointing here:
- A windows update that is missing here?
- Somehow during uninstall/repair the Apply command faces a user authorization error (cannot create a folder or overwrite something)? [my user is admin on the virtual machine]
- Is is possible to use different CMDLINE params and still run the setup from Control Panel/Programs and Features?

I would really appreciate any ideas.

Thanks.

[FrancescoT]

Dear Vartom,

Unfortunately and as you can imagine, it's not easy from here to point you to the right direction, without having the possibility to directly verify what happens.

For what concerns the different behavior you noticed, while un-installing the package running the setup directly (instead to remove through Control Panel), this could be explained probably by the different MSI script code involved with the process... but it's actually quite strange what you reported about the MAINTENANCE value.

Regarding the empty log, this means that the MSI engine "for some unknown reasons" is not able to start and this for sure ( ... it's the only sure fact we have at the moment) this has a direct relation with the "msi.dll - not found" error.

At this point it'll be interesting to know, if you are able to replicate the same effects with creating a dummy project from scratch. At this purpose it's just enough to create a project and then to build it (... without setting anything or adding any file to it).

For sure this will tell to us, if what you are experiencing, it could be caused by some "unwanted" behavior present with your setup script.

Let me know.

Rewards

[vartom]

Hi Francesco,

Thanks for the quick feedback.

I tried to reproduce the issue with a dummy project, I just forgot to write it down, but it was unsuccessful. With that everything worked out as expected.
But we decided, that we won't spend more time to find out what is causing this issue, since we have a workaround to eliminate it (by run the exe file, and from Control Panel) and also we plan to upgrade the current IA11 to the latest, InstallAware X2, version.
I'm most certainly convinced that this issue was eliminated with the improvements you've made between these two releases.

I'll let you know about the outcome.

Thanks again for your support.

Regards.