Setup resource decompression failure on Windows 10

[AndrewC]

My company is getting dozens of reports a day of our installer throwing a "Setup resource decompression failure" on Windows 10. This is retail software so this is not happening to in-house corporate PCs. We were originally using InstallAware 9R2, and saw old posts on this forum that this error had been fixed in newer versions of InstallAware, so I used X3 to recompile our installer and we're still getting the error. I believe the root cause of some of the old issues were localized versions of Windows that used non-Ansi characters in path names, but in our case this is happening to users running American English versions of Windows 10.

When we ran the installer in logging mode, one support rep saw this error: "Cannot create file "C:\Users\Samuel\AppData\Local\Temp\mia1\installaware.png". The system cannot find the path specified."

Here is the actual log file output:
<InstallAware>
<SupportDir>
</SupportDir>
<SetupSplash>
<StubSize>
</StubSize>
<StubData>
</StubData>
<GlobalLists>
</GlobalLists>
<ExtractArchive>

I suspect the issue is that it cannot create the "mia1" subfolder. As a workaround, if we create a new user account on the customer's machine and run the installer from that account, it succeeds. We suspect this might be an issue with permissions with some users who have upgraded Windows 10. To clarify, this doesn't happen on the majority of Windows 10 installations -- but it's happening often enough that it is clogging our support queue. We've gotten zero reports of this problem with Windows 7 or Windows 8, it seems to be exclusively happening with Windows 10.

This is not a drive space issue -- in each case, the user has ample space on their hard drive and the install succeeds when re-run under a new Windows user account without freeing any additional drive space.

[FrancescoT]

Dear Andrew,

first of all, for sure what you are reporting has nothing to do with the "issue" reported by those old forum posts you mentioned.

For what concerns your specific issue instead, it seems in-fact an issue permission and it may be interesting to know what are the effective permissions of those accounts.

If I haven't missed anything, you are telling that this seems to occurs when an original Win 7 system account gets upgraded to WIN 10. Am I correct?
Do you know what kind of account was originally active on WIN 7?
I would like to see if I am able to replicate the same conditions.

Let me know.

Regards

[AndrewC]

Unfortunately we're dealing with *very* non-technical users. We know that they've upgraded from an older version of Windows, but they typically don't know anything about what type of user account they had before upgrading. Is there a tool or command line utility that you recommend we run on their system that will report what the permissions are for their Temp folders? I can ask our tech support reps to log in remotely and run the tool or command and then I can send the output to you.

[FrancescoT]

Honestly, I don't know if exists a similar tool.

You may follow the steps described with the following link in order to check their effective permissions over a folder.
https://technet.microsoft.com/en-us/library/cc758822(v=ws.10).aspx

do you know if they have any security policy active on their systems?
do you have any possibility to create a virtual machine clone of such system?

Regards

[AndrewC]

Unfortunately I don't think we'll be able to provide any virtual machine versions of customer hard drives -- even if they had the spare room, none of them have the bandwidth and patience required to put up with uploading a multi-gigabyte file.

I do have some more information: in many cases, the issue is that there is a file (not a folder) called "mia1" in the user's Temp folder. Manually deleting it allows the installer to run. I don't know what program created the file originally.

I don't think the users have active security policies because these are nontechnical end users that are not in a corporate environment, so it's unlikely security policies would have been set up.

I will work on getting a list of Effective Permissions for the users that are getting this error.

[FrancescoT]

Dear Andrew,

just to let you know that this morning, I tried to run some more tests and I am not able to replicate the problem you seem to have.

Anyway, let me know in case you have some more details to share.

Regards

[AndrewC]

One case you should be able to repro is if a file exists called "mia1" (no file extension) in the Temp folder. I was able to reproduce the setup resource decompression failure by creating a file of that name then running our installer. For sure some of our errors are due to a file by this name existing on the customer's machine. I don't know what creates such a file, but having the installer check for the presence of that file and either rename or delete it would for sure eliminate at least some of these failures. Alternatively if there's a name conflict, extract the installer's temp files into a differently-named folder.

[FrancescoT]

Dear Andrew,

for what I know it should be a folder called "miaxxx" and not a file and this gets temporarily created at setup extraction/decompression (its name is Always unique). The same folder is then removed at setup termination.

Anyway, it's strange that you found a file using that name and not a folder within the temporary folder.

Regards

[AndrewC]

Dear Andrew,

for what I know it should be a folder called "miaxxx" and not a file and this gets temporarily created at setup extraction/decompression (its name is Always unique). The same folder is then removed at setup termination.

In watching our installer in action, the folder's name is always "mia1" -- it is invariant as far as I can tell.

Anyway, it's strange that you found a file using that name and not a folder within the temporary folder.

I agree. I don't know how that could be, but we've seen it cause several support calls. If the installer is supposed to name its extracted Temp subfolder "miaxxx" with the "xxx" digits being used to avoid conflicts with existing files/folders, that logic is not working.

[FrancescoT]

Dear Andrew,

I agree. I don't know how that could be, but we've seen it cause several support calls. If the installer is supposed to name its extracted Temp subfolder "miaxxx" with the "xxx" digits being used to avoid conflicts with existing files/folders, that logic is not working.

I am not able to see any problem with the "logic" that handles the temporary folder at setup runtime.
Its name is Always unique and "xxx" digits are correctly incremented if necessary.
Can you imagine how many users should have reported the same problem?

Honestly, I really suspect that the effective source of the problem could stay on a different side.

Regards

[AndrewC]

Francesco,

We continue to get calls on this error, and now that our support team knows to look for the "mia1" file, that is the underlying cause every time.

The test case is simple: go to your Windows Temp folder, create a file (not a folder) called "mia1" (no file extension, it can be zero bytes, the contents don't matter). Then run the installer and 100% of the time you'll get the error "Cannot create file C:\Users\[username]\AppData\Local\Temp\mia1\installaware.png. The system cannot find the path specified", followed by the setup resource decompression failure message.

The function that is supposed to rename the InstallAware temp folder to mia[xxx] in case of naming collision isn't working in our installer, either in R9 or X3.

You can reproduce this in an empty project: use the New Project wizard and select Native Setup. Build for "CD or DVD". Create a "mia1" file in the Windows Temp folder. Run the project and you will get the error.

Andy

[FrancescoT]

Dear Andy,

what you reported clearly explains the issue you had.

The setup engine verifies if a temp folder named "MIA" already exist and it doesn't make any verification for a possible existence of a file named MIA.
BTW, the engine doesn't create a file named MIA or alters an existing MIA folder to a file.

For what I can tell and for what I can only suppose, for some strange reasons (probably an existing "process") the attribute of the temporary MIA folder has been modified from "FOLDER" to "FILE".

Eventually I may ask our dev team, if exists the possibility to introduce an additional verification to the engine process with next IA release.
But honestly, I don't know if this can be released indeed.

Regards

[JonPerkins]

Hi, Just to say that I have just encountered this situation as well. A customer has had a Windows 10 computer for about a month and installed a previous version of my app which seems to have been fine. I have just created a new version and ran a couple of test installs on my own kit without any problems. I then took a support call from this customer and decided to use her computer as a test for interactively installing this new build via Teamviewer. Unfortunately I also saw the "setup resource decompression failure" message, the same bad path message as discussed in this post by AndrewC - and also found the mia1 file. After a couple of tries to verify that it wasn't a one-off I then deleted the mia1 file and the entire process then worked without fault.

I suppose one workaround for now would be to ask users to clear their temporary files before the install, but I would like to know if there is anything I can do to alter the initial unpack location to circumvent the problem. I'm using the latest IA X3 and it was a single-file with medium-level compression.

Love your product though!

Regards,

Jon

[FrancescoT]

Dear Jon,

unfortunately at the moment it's not possible to override the temporary directory.

Anyway this is a very strange error and despite all my attempts, I have not been able to replicate it.
Please note that I am not saying that the error doesn't exist, but instead, that I really don't understand how such file gets created.

I'll try to investigate a little more.

Regards

[FrancescoT]

Dear Jon,

a new IA X3 version has been made available (20.05) and this should fix the problem.

NOTE!
A new re-generated license file is required to activate the product.
A full installation is highly recommended.

Regards