the main problem is that it is not easy to find out what causes this.

Yes, it's a decompression error (because it's reported from the LSPack
decompression library) but it's not really a decompression thing. I know
it's a bit confusing in this case...

The problem here in this very specific case is that the installer runtime
checked for write access and the check did *NOT* detect a locked file
scenario. Why? Because it was not locked when the installer checked for
write access. So "replace on reboot" did not kick in, the installer
continued and called the unpack procedure to replace the existing file.
Okay, but suddenly, the CreateFile Windows API in the unpack library failed
with ERROR_ACCESS_DENIED (that is the "5" in the "-200000005" error code.
At this point, it was too late to offer a "Retry" because it's a fatal
decompression error. It's also possible that this happens for new installs
(no replace scenario). The installer creates the file, this succeeded, but
one millisecond after this the protection software locks the newly created
file... All these bugs in the protection software systems are a nightmare!

In short, the installer checked for write access, write access was possible
but directly after the check your protection software (real-time monitoring)
locked the file and BANG......

A typical false-positive bug :-( Users should never see "-200000005".