X5 install fails at startup, after reboot to finish .Net Framework install - no error msg

[spicymikey]

This is hard to describe, let alone debug, because there is absolutely nothing to go by from Installaware. But there is a clear pattern to make it happen so let me describe that.

When the client starts our IA setup.exe to install our product, the installation begins to check for prerequisites. If one of them is the .NET 4.6.2 then it installs it, then calls for a reboot. When the user reboots the computer and starts the installer again, the IA setup.exe just terminates without a screen error message. Nothing is being captured by Windows in the Event logs either. Opening Task Manager, I can see the setup starting, then after a few seconds it just disappears. This all happens after the Installaware splash screen appears but before the first window of the dialog wizard.

Some facts:

- This is the IA X5 RTM version. 8.4.2016. Still seems to be the current version available for download
- We use IA X5 on an older version of our product and the problem does NOT occur, probably because it does not need the .NET framework
- The IA script used on this latest version is identical except there are newer versions of dependency packages being used.
- This has happened 4 times, out of 12 attempts, all on PC's that had that situation with the missing 4.6.2.
- We can resolve the problem for the customer if we build a new setup (no code changes) and have them use that new one.
- I checked for remnants of our setup, mia.exe, etc., and removed everything like that. The PC seems clean and the problem still occurs with a rebuild of the setup being the only thing that solves the issue for the customer.

This has me stumped. Any thoughts would be greatly appreciated.

[FrancescoT]

Dear Spicymikey,

I am very sorry but I have to admit that I don't have a clear picture of your problem or better, I understand how the issue seems to occur, but I am quite confused on some of the "Facts" that you described.

You say;

We use IA X5 on an older version of our product and the problem does NOT occur, probably because it does not need the .NET framework

and

We can resolve the problem for the customer if we build a new setup (no code changes) and have them use that new one

Maybe I am missing something, but I don't understand if the problem occurs with a setup package generated using X5. Can you try to elaborate a little bit more?

At any rate, did you try to use the "Process Monitor" tool on the same machine where you reproduce the issue?
Process Monitor is an advanced monitoring tool for Windows that shows real-time file system, Registry and process/thread activity.
Probably you will have a chance to track down the cause.
https://technet.microsoft.com/en-us/sysinternals/processmonitor.aspx

Hope this helps you.

Regards

[spicymikey]

Hi Francesco

Sorry if it was confusing. I was trying very hard to lay it out clearly to avoid confusion. What I was trying to say is that we are using X5 in both instances but it is only happening with the new version of our software. I am speculating it is because of this .NET prerequisite stopping the install midstream.

Was hoping what I gave you would trigger more ideas than to use Process Monitor. What could that possibly tell us? I'm sure its going to show us that it is calling your mia program, etc. Doesn't it seem intriguing and concerning that:

1) The process works the first time just to check the prerequisites and install .NET, yet it fails after that, from the same PC with the same setup exe that was downloaded? Nothing different!
2) It works fine on other PC's that do not get stopped to install a package and reboot?
3) Your program is stopping WITHOUT any errors and no events to the Event log?

This third one is most concerning and I've seen it before with your product over the years. Why do you not trap errors better to help us debug issues. You should NEVER be flushing out like that. It's evidently not a Windows issue otherwise it would have been captured in the Event Log. So we have to assume the failure and termination is solely from within your product.

Seems kind of serious and maybe a major problem with x5. Any other thoughts? Can you take a copy of our installer and duplicate it there?

[FrancescoT]

Dear Spicymikey,

you can trap an error if the error event can be handled by the running process.
If this occurs for some "external reasons" that cannot be handled by the running process, because such external cause has nothing to do with the process itself, it's quite impossible to trap such event.

At any rate, sure I can try to check your package.
Please use support@installaware.com to send me your file or its download link along with any instruction.

Regards

[spicymikey]

The error either occurred within your process, or not. If it was not, then Windows would have trapped it in the Event Viewer. Unless you are using third party products, then the error is occurring inside mia and intentionally or not, your processes are consuming this error and not reporting it or passing it on to Windows. But that's another issue and was just trying to push to help you make your product better. It's in your best interest because this increases your support costs.

At any rate, thanks for volunteering to help. How can I send it to you. I can't post our products installer code on a public board. Do you have a private location I can send it?

In the meantime, I want to reemphasize this one piece of info, that seems to be critically important. We can get it to work for a customer if we just rebuild the setup and give them a fresh one. Strange, because there is nothing wrong with the setup, we don't change anything before rebuilding, and it will work just fine on another pc for another person. Is something being cached that we could clear to get a customer passed this? There are no instances of our installer or that mia file. I keep mentioning that because the last time we had strange problems like this, deleting the saved mia file and related components solved it.

Thanks!

[spicymikey]

Bump

Hi Francesco, don't forget to give me instructions on how I can get you the entire installer. I don't want to post it here, plus it's way to big and exceeds your file size limit.

Alternatively, if you have any suggestions on how to capture the error from your process, I will be happy to try that first.

[FrancescoT]

Dear Spicymikey,

I don't want to convince you, but there are circumstances where an error doesn't get trapped in the Windows Event as well. I had a personal experience due a buffer overrun caused by a DLL and there was no track of that error anywhere.

Anyway, let me have a look at your package. As I have already said, you can send me your file or its download link along with any instruction, to; support@installaware.com.

"Cached setup sources files" are stored under "ProgramData" with a PER-MACHINE installation (ALLUSERS=TRUE), while with a PER-USER installation instead, these files are stored under the user account "localData" folder (eg. C:\Users\<USERNAME>\AppData\Local\{GUID})).

Regards

[spicymikey]

My apologies, you did mention sending it to support@ in the prior email. I didn't notice it.

I believe we checked for cached files under ProgramData, but not sure if we are aware of that second location under AppData. Before we spend more time, let me wait for this to occur again and we will make sure to clear out both locations to see if it helps. If nothing else it will be another clue.

I threw out a lot of "facts". Not sure if you caught them all as I know you are answering questions all day long. But the fact that rebuilding the install solves it seems like an interesting clue. The first big questions is; why does aborting the install mid way (to do a reboot for .NET Framework) seem to prevent that Installaware setup from ever running again on that PC. And then, why would rebuilding a new installation for the customer make a difference?

[FrancescoT]

Dear Spicymikey,

unfortunately I cannot give an answer to your questions and this is the reasons why I asked to have a look at your package.

If you used a previous IA version to generate the package, it may be possible that this may be caused by a "strange" behavior of that particular version of .NET Framework installer that was included with your package. When rebuilding a new installation and if you used a more recent IA version, the compiler will Always use the newest version that comes with IA.

It may be possible that has been damaged/altered the binary image of your installer and/or of the" .NET Framework installer" included with your setup. This may be caused by an installed anti virus.

However these are just assumptions.

PS
Pay attention to delete/remove "Cached setup sources files".

Regards

[spicymikey]

FYI we are NOT using any IA packages for deploying third party products. So in the case of .NET 4.6.2, we have a custom setup script that simply executes the NDP462.exe from Microsoft (which we ship with our product. It all seems to be working fine because that first time through it calls for it to be installed, it is installed, and a reboot is requested. Problem is that the installer fails after the reboot. Of course, it is the SAME setup.exe so I doubt there is any corruption issues with the executable. Also, it has now happened 4 times, for 4 different customers, under these same circumstances. Unlikely it is an environment issue with the client.

This is a good one! But of course, I've been using your product for years, so I rarely bring trivial issues to this forum.

[spicymikey]

OK that didn't take long. Just had a report of another customer who can't install because of the same problem. 2 of 6 workstations failed. No error message. Setup just starts, then ends. Cleared any cached files. Still fails. I will send the install to you at the email you provided. I can't send you the entire install because it is too big to push through our email server. However, if you wanted the full project, complete with packages, I can put it on our FTP site, or my OneDrive, for you to download.

Thanks
Mike

[spicymikey]

*** CONCLUSION AND SOLUTION ***

I took this discussion offline with Francesco since it became apparent this was a tough one. Francesco eventually figured it out. Thanks to him for all his effort.

Problem is occurring because IA X5 cannot handle an abrupt termination of the setup if you have SINGLEINSTANCE=TRUE set in your config. The reason is because of how IA is designed. To control and prevent multiple instances from occurring, they create a file in /AppData/Temp on the pc. The file is called <revisioncode>.mia. When the installation ends, IA deletes the file. So, while the install is running you can't run another instance because it will see that file and stop.

Personally, I think this design is flawed. There are so many better ways to tell if a program instance is already running. This design is vulnerable to abrupt terminations, which is exactly what happened when Microsofts .Net Framework setup called for a reboot and the user said YES. But there are countless reasons an install can terminate abruptly. This is just one example. And when it happens, the user is left without a way of running the install again until you either create a new install package (with a new revision code), or you have them navigate to the AppData folder and delete the file. Most users can't do that do it becomes a Support call to our Tech line and wastes our time. I told Francesco to report this as a problem to have redesigned. Hope they do it.

To add to the confusion, there is also a flaw in IA that is preventing it from providing a popup message before it terminates. IA sees the revisioncode file on the hard drive and consciously decides to terminate. But it gives not alert. So you are left confused because all you see is the installer starting and then ending without warning. I asked Francesco to report this as a bug.

I think this needs to be addressed by IA but in the meantime, hope this thread helps someone avoid all the lost time I experienced. The saving grace is the superior support provided by Francesco. He needs a raise! Thanks man for sticking with me until we figured it out.