Setup crashed > no execution possible > SINGLEINSTANCE

[alibaba]

Hi,

on a customers computer a setup crashed after apply install. Now he cannot execute any setup version of this product. The problem is the single instance check. If I remove it I can execute setups again. The error message is: runtime error: List index out of bounds (0)

Now my question: how can I clean the system that I can run again setups of this product with SINGLEINSTANCE=TRUE. I think there must be a file or a registry key that prevents setup from beeing started. What have I to delete?

Thank you!

[FrancescoT]

Dear User,

actually are still installed instances of your setup package with this OS?

Let me see if I am able to find somethings that could help you.

Regards.

[alibaba]

Sorry I do not understand you...I know that in the past I removed one file that was like the mutex for the single instance check. Do you know that file?

Please explain what you mean with OS-package?

[FrancescoT]

Dear User,

have you installed in that machine (the target OS where your setup package crashes) multiple instance of your setup package?

If true, actually is any instance of your setup package still installed?

Let me know.

Regards

[FrancescoT]

By the way, I believe that deleting the content of the %TEMP% folder probably should help.

If you can send to me the project you used to produce that build, I'd like to test it.

Regards

[alibaba]

I already found out myself that a file $TempDir$\{[RevisionCode]}.mia acts like a mutex file, if I delete it I can start a setup with SINGLEINSTANCE=TRUE twice. But on the relevant computer there was no {*}.mia file in the Temp folder, so is there another way IA checks the Single Instance? I just want to understand the process. Maybe I was in the wrong user-folder, so can you tell me if the named mutex-file is the only mechanism for single instance check?

[FrancescoT]

To avoid any mistakes, I asked your question to dev team.
They have confirmed that %TEMPDIR% is the only place used to store single instance check.

Probably as you said, you was with the wrong user folder.

Then, I'd like to test your project ... exist any possibility to have it or a sample that replicates the same issue?

Regards.

[alibaba]

It is hard to reproduce because within my setup I call a 3rd party driver installation .exe (after ApplyInstall). This driver installation crashed on a customer PC (to BlueScreen!) and so the Single instance was still active (anywhere). The problem is that I am not able to force this driver installation to crash with BlueScreen on any Test-PC. I suppose it has to do with the speciality of the customer system (domain controlled etc.). So I think you will also not be able to reproduce it within my project (I am even not able to reproduce it if I terminate the installation via Taskman after apply install).

But anyway I have my answer now about the SI-check implementation. Is there another mutex implementation that checks also that two IA generated setups are not running at the same time (IA-setup wide and not only Product/Revision-Code wide, or is this TEMPDIR\mutex-file check already IA-setup-wide)?

Also one question: wouldn't it be better to save this mutex-file within ProgramData (AllUsersAppData) to ensure that no two installations can run at the same time system-wide? It would also be easier to find this file for support-dept. because you may not know which user started the installation.

If you want the project anyway I can send it to support, just let me know.

Thank you!

[FrancescoT]

Dear User,

Actually, is the TEMPDIR\mutex-file check and the workaround for now is to clear the contents of the %TMP% folder. This should have been solved with the next IA release.

The suggestion for ProgramData is good, but it will fail if any of the setups are not running with admin/elevated rights ... therefore it will be not implemented.

Regards

[alibaba]

The suggestion for ProgramData is good, but it will fail if any of the setups are not running with admin/elevated rights ... therefore it will be not implemented.

Why not, every user can r/w in ProgramData. In Windows XP the folder was called AllUsers\AppData. At least I am able to create files within ProgramData with User-Rights.

[FrancescoT]

Dear User,

For what I know with OS as Win 7 an user must be at least member of USERS group to have access to "ProgramData" ... so not everyone.

Regards

[alibaba]

Ok thank you! Have a nice day!

[FrancescoT]