Setup file(.mia) in temp folder blocking to start the setup

[ssubramaniam]

Hi Francesco,

As per your suggestion, I have started new topic here.

My customers are facing this problem very occasionally. I have analysed this problem with multiple machine and the result are same. Finally, I am able to recreate this issue in version 18.08.0.2014 and 20.11.0.2016. Since this is not reproducible in straight scenario, so I found some workaround options to recreate the same problem.

Option-1
1. Run the setup.exe or MSI
2. Copy the .mia file and store it another folder
3. Cancel the setup once the first screen launched.
4. Place the copied .mia file to temp folder
5. Run the same setup.exe or MSI

Now, you can notice that failure during launch of first screen.

Option-2
1. Run the setup.exe or MSI
2. Kill the setup once the first screen launched.
3. Run the same setup.exe or MSI

Now, you can notice that failure during launch of the first screen. Once you delete the .mia file from temp folder then setup is running as normal.

Why the setup is checking the existence of .mia file after unsuccessful install and when setup lunched for second time to repair ?

Thanks,
Senthil

[FrancescoT]

Dear Senthil,

I just tried to repeat your steps and I am not able to replicate the same.
I used InstallAware X3 ver. 20.11.0.2016 and the following systems to test the behavior;
- WIN 10 x64
- WIN 10 x86
- WIN 7 x64
- WIN 7 x86

I have also tried with "terminating the process" from Task Manager and even in this case, I am not able to replicate the behavior you reported.
Note that I have brutally terminated the running task while the files installation was in progress. This may generate eventually, an unrecoverable error "state" with the Windows installer engine itself and this due a possible internal corruption of the MSI data.

In case of an internal MSI engine corruption, there is nothing that we can do to control this to happen. Due the fact that in such specific event, it's still the Windows Engine itself that handles any error state or error message that may be displayed.

In addition and in case of a single compressed MSI setup file (.msi), the process creates the following file and folders under the local TEMP directory;

- a folder named MIA(x) where the X represents an auto incremented number, for example; mia1, mia2, mia3 and so on. If at setup Runtime a "mia" folder is already present within the TEMP target folder (eg. mia1), a new mia folder gets created by the process (eg. mia2).

- a {GUID}.EXE file, where the "GUID" represents the package PRODUCTCODE. This file is Always overwritten if already present.

- a {GUID}file without extension, where the "GUID" represents the package PRODUCTCODE. This file is generated during setup files installation and it gets Always overwritten if already present.

In case of a single compressed setup EXE file (.EXE), the process creates ONLY a "MIA(X)" folder under the local TEMP directory.

Finally, a setup package created using IA X3 doesn't creates any MIA file (.mia) under the local TEMP directory

Regards

[Yuriy Svichenskiy]

Hello everyone. I've faced the same problem. It breaks <yourinstaller>.exe startup at all, which means that it is event possible to break uninstallation and your client will stuck with installed app at his machine. I've found the only one way to solve it - remove all *.mia files in the temp folder. At least you can provide uninstallation via that method. But still, I don't know what to do in case of installation process stoppage(via taskkill or simple machine reboot). User won't be able to run <yourinstaller>.exe again to install app.

[FrancescoT]

Dear Yuriy,

as I have already said previously, I am not able to replicate this issue.
I don't know which IA version are you using, but for I can tell you, the problem you seems to have it's not replicable using IA X3 or successive versions.

Of course, it may be possible that some old IA version was affected by this problem.

Hope this helps you.

[mbond]

I know I'm late to the game here, but we have seen the same issue. We are using InstallAware version X15, only create single EXE installers, and only test on/support Windows 10 and 11.

We see this issue when the install crashes for some reason. When the install is started again, then it will go through the decompression UI. When that is done, then the program closes. It never shows the first interview dialog. There is nothing in the log file about why it doesn't show the dialog.

The quick and dirty solution is to delete the contents of %TEMP%, at least everything that doesn't complain about being deleted. Then start the installer again. This last time it will work. Definitely something that is unique to InstallAware.

[JohnGaver]

I know I'm late to the game here, but we have seen the same issue. We are using InstallAware version X15, only create single EXE installers, and only test on/support Windows 10 and 11.

We see this issue when the install crashes for some reason. When the install is started again, then it will go through the decompression UI. When that is done, then the program closes. It never shows the first interview dialog. There is nothing in the log file about why it doesn't show the dialog.

The quick and dirty solution is to delete the contents of %TEMP%, at least everything that doesn't complain about being deleted. Then start the installer again. This last time it will work. Definitely something that is unique to InstallAware.

This doesn't account for the expected behavior as %TMP% folders are NOT reused.

In other words, each time setup is run, the %TMP% folder created is guaranteed to be unique and distinct from all other pre-existing folders.