Printable View
We are getting the following decompression error in an install:
Attachment 4293
I have reviewed several of the other posts about decompression errors but none of them reference the #99.
This error is happening in an include script where we are installing a .sql file, running it via sqlcmd.exe and then deleting the .sql file. If the user goes "back" in the installer, then this process could be ran multiple time.
Any help on this is greatly appreciated! Thanks in advance!
Terry Mullican
Terry,
Hmmm, you said that if the user goes "back" in the installer, then this process could be ran multiple time. Are you using the Install File(s) function in a Loop Statement (e.g. a Loop or Loop Wizard)? Or the include script that holds this Install File(s) function in a Loop Statement?
This is from the Remarks section: Never use the Install File(s) script function in a Loop.
An Install File(s) function can only be executed once, a Loop might execute it multiple-times and this is not possible. To handle a Loop scenario, you can use the Copy File(s) function.
Does this help?
Friedrich
Yes sir! Thank you, sorry I missed this!
I decided to change it to install the files once in the main script and then run the include script multiple times for re-querying the database. Then at the end of the install I can clean up the files.
As a follow up, here is quick video of the "search" process I am working on. The list of databases would not fit into a single variable, so we decided to provide a search by name.
http://screencast.com/t/FfdYRzqfiXN
As you can see in the video, I am having problems getting the Dialog to use the updated variable after the second search... any tips?
Thanks,
Hi Terry,
Interesting project!
BTW, the runtime variable value limit is 10,240 bytes (10KB) when using the "Set VariableEx..." script function. This is not enough in your specific case?
I have created a demo project for you:
http://www.lindersoft.com/projects/TerryCombo.zip
See attached screenshots. It "re-loads" the combo box with new values.
Does this help?
Friedrich
Or this one if you don't want a Custom Wizard Dialog combo:
http://www.lindersoft.com/projects/Terry2Combo.zip
The "Refresh Next Dialog" function does the magic here.
Friedrich
Friedrich,
So we are loading a list of database from a SQL server, this list has to be dynamic and it contain almost 200 databases to choose from. I can not hard code these names because they change daily.
Here is the process:
1. Install SQL file which creates a sql store procedure (SP) to return the database list.
2. Run sqlcmd.exe, running the sql file to create the SP on the local master database.
3. Run sqlcmd.exe, calling SP with search parameter. We include a switch to output the results to a INI file.
4. In SB, loop thur the file and append the names to variable.
Note: All the database have TirePower-%CompanyName% as the name. We hit the variable limit a couple of years ago and then we just stripped "TirePower" from the name and bought us some space and the drop list had all the names again. After reviewing the data closer today, I am not sure why the variable is not showing all of them, we have currently have 148 databases and putting this into text file it is only 2083 chars. Here is the code, I even tried to trim the names to see if would help.
Attachment 4302
And as I am typing this up, I re-read your last post and realized... the "Refresh Next Dialog" is my issue!
I did not have it in there! THIS FIXED IT! http://screencast.com/t/lseu7Yvn1FJW
For anyone reading this post, this is why SetupBuilder is a great tool, unmatched support for the crazy stuff we try to do with it! My team here at TCS has worked with Friedrich for many years troubleshooting a lot of different things and everyone one of my team members has always enjoyed working with Friedrich and SetupBuilder. This is a crazy powerful tool! Thanks again SetupBuilder/Friedrich!
Thanks,
Hi Terry,
Thanks so much for your kind words !!! :)
Friedrich
Are there other cases that can produce this error? Or is there a description of this error?
I am also receiving this error, but for an "Install File(s)" command that is not in a loop. The install command is in an include script. This include script is run multiple times, but the source directory has a different value each time. The target is the same (temp) directory, but this is cleared and created before the install command.
When I build with a smaller set of artifacts, the installer works in all use cases.
When I build with the full set of artifacts, the installer works in 3 of 4 use cases. The 4th use case presents this error ("A decompression error has been detected" ..... [#99]).
Regards,
Seth
Seth,
an "Install File" action can only be executed once. If you "run" an include script multiple times then the same "Install File" action is executed multiple times. This results in Error #99.
The correct way to handle this scenario is to install the file once and then use "Copy File..." to copy the file to its target location(s).
Does this help?
Friedrich
Friedrich,
I re-architected my scripts so that the "Install" in the include script would not be executed twice. However, I am getting the same error on the same file.
Seth
Seth,
unfortunately, reviewing the source code in your .sbi does not help in this case. But the "sbevents" log is interesting.
Error #99 comes up if the next install file (decompression) action can't be executed because the decompression library was unable to find the "magic sign" of the next file. The magic sign is the archive header of the next file to be decompressed and includes the name of the file, original file size, date/time stamp, CRC-32 code). If Error #99 is returned from the LSPack decompression then the magic sign was not there.
This might happen if:
1. An installation action is executed multiple times (99%)
2. The archive is tampered (e.g. transmission error or false-positive from a protection software)
3. The file is > 2GB
In your "sbevents" log I see multiple installation actions for your "deltaCompression.log" file:
|08/26/2021|13:17:41.032|Install file: C:\Users\edtadmin\AppData\Local\Temp\b60e1f40-0670-11ec-4823-001ce5d30029\deltapackage\\deltaCompression.log
|08/26/2021|13:18:53.596|Err01: 99 - File: C:\Users\edtadmin\AppData\Local\Temp\b60e1f40-0670-11ec-4823-001ce5d30029\PlugInFiles\\deltaCompression.log
If you did not include this file TWICE in your project then it comes from the SAME "Install File(s)..." action and the 2nd call returns Error #99 (IMO).
Or did you add "deltaCompression.log" twice? If yes, you should see this file multiple times in your compiler HTML.
Friedrich
Friedrich,
I am including "deltaCompression.log" using 2 different "Install" commands, from 2 different sources, installing to 2 different locations. I also included the compiler HTML and CSV in the previous post. Is it possible that it does not handle the 0-byte file appropriately?
Seth
Seth,
yes, I see. I did not notice the .htm file, thank you.
The first "deltaCompression.log" succeeded. Then you make a bunch of DLL calls (as far as I can see). Is this your own DLL? Do you call into a DLL named "InstallDelta.dll" from that script?
It is nearly impossible for me to find out what might cause this Error #99 from the info I have.
Just curious: what happens when you EXCLUDE "deltaCompression.log" from your 2nd "Install Files..." action. Does it fail on "index" then? If this is the case, it is very well possible that one of the DLL calls corrupts the application stack. But it's just a guess.
Friedrich
BTW, the LSPack library handles 0-byte files without any problem.Quote:
Originally Posted by st09
Friedrich
Seth,
you said that "the installer works in 3 of 4 use cases. The 4th use case presents this error ("A decompression error has been detected" ..... [#99])."
Do you think it is possible that there is some kind of memory allocation problem in your DLL? As far as I can see, you are calling an external DLL. Please ignore if you do not call into a DLL. But if you do, perhaps the DLL corrupts the stack?
Would it be possible for you to temporary disable the DLL call(s) to see if this makes a difference? Other than that, I am running out of ideas. LSPack (the underlying de-(compression library) did tens of millions file installs over the last 20 years and it's nearly impossible that there is a bug in this rock solid component. So there must be another reason for the issue in your case.
Friedrich
Friedrich,
Even taking out the DLL call, I am encountering the same result. Here is another set of files with the DLL call removed. Note that "index" is only attempted once, and fails. What else can I provide or investigate?
Seth
Hi Seth,
okay, so you have EXCLUDED "deltaCompression.log" and now the next file is "index" and this fails. That means it is not a specific file problem. I still think it is some kind of stack corruption.
Would it be possible to create a small subset of your installation and send us the .sbp and .sbi (including the source files files to be included) so we can compile and debug it here?
Thank you for your help!
Friedrich
Friedrich,
I will email you a link to download the files. I've narrowed them down some, but they are still > 1 GB in size. I will also trim the script as much as possible.
In summary, what I've found is that with a certain set of source files, if there are 2 (or more?) install commands (non-overlapping), if the first install command is skipped ("If" condition not met), the second install command fails with Decompression Error #99.
Regards,
Seth
Seth,
we received the files, thank you!
Friedrich
Hello Seth,
thank you for the files. We’ll review it, but I think I already see what the problem is.
It’s caused by #3 from my previous answer:
http://www.lindersoft.com/forums/sho...ssion-Error-99
3. The file is > 2GB.
The .EXE file size limit in Windows is 2GB !!! Your installer is 2.4GB.
“The executable "image" (the code/data as loaded in memory) of a Win64 file is limited in size to 2GB. This is because the AMD64/EM64T processors use relative addressing for most instructions, and the relative address is kept in a dword. A dword is only capable of holding a relative value of ±2GB.”
In the upcoming SetupBuilder 11 our goal is to support installations larger than 2GB with multiple-volumes. But one .EXE >2GB is impossible from the Windows technical site-of-view.
Friedrich