I suggest to write an email to supportatcloudberrylabdotcom regarding that and provide a screenshot/photo of the error message you see on BSOD.

There's no ETA yet, but we're working on that.

Sorry, not sure what you mean by "URL that should be allowed when using CloudBerry Explorer", but if you're referring to WEB URLS for the files they would have this format:
http://bucketname.s3.amazonaws.com/pathtothefile/file.txt

The first thing to try is to follow the suggestions in this article: https://www.digitalcitizen.life/command-prompt-fix-issues-your-boot-records

This functionality is not yet available in web dashboard, but it's definitely on our road map.
I've added you to the list of clients to be notified upon its release.

We use ports 443 and 80 in our software. As for the addresses of your cloud storage provider, they should have this info on their web side.

Here's the link: https://www.cloudberrylab.com/blog/back-network-shares-macos-linux/
Also, you might want to try this method to mount the share: https://www.digitalocean.com/community/tutorials/how-to-use-sshfs-to-mount-remote-file-systems-over-ssh
In version 2.6 the procedure will be more streamlined.

You can actually try disabling it, but since I don't know what the issue is, it's difficult to recommend something:
- Click Drive tray icon and choose Options
- Select a mapped drive and press Edit > Edit advanced options
- Uncheck "Use file cache" option
- Find the cache directory in Options > Advanced
- Navigate to that directory with Windows Explorer and delete all its contents

This guide might help: https://www.cloudberrylab.com/blog/backup-to-another-computer-over-the-internet/

To make this more efficient, make sure to send the logs from both machines in that session with reference to that ticket.

Cache directory is used to store files locally before they will be uploaded to a cloud. Due to technical limitations of a virtual disk driver and the way how cloud storage providers work it's not possible to upload files on-the-fly. If you're transferring large amounts of data the software would require larger cache size, but again, you might want to tweak this option if you experience any issues during upload operations. The default values should work fine on most configurations.

That is pretty much correct, your data is safe, but you need to decide if you want to continue using file name encryption or not.

Not sure I understand your issue, so if possible, please reiterate the question.

As for the file name encryption, it is disabled by design when "Track local file deletes in backup storage" option is enabled due to how the whole process works.

Increasing thread count might help when transferring large amount of small files but the results may vary depending on your configuration. The default parameters should work fine, but you can experiment with the values to see which ones work out the best in your environment.

Sorry, as I've mentioned, there is no way to do that due to how cloud storage providers work. This is not implemented in S3(and in any other cloud storage, afaik) on API level.

The procedure is automatic in the PRO version, the files will be decompressed during the download operation.

it is currently not possible to change the state of the files from compressed to uncompressed in the cloud on the fly due to how cloud storage providers work.

I'd suggest to re-generate creds on the receiving end, copy them, click on the "..." button on the connecting end like on the screenshot and re-enter credentials

If that still doesn't work we would need the diagnostic logs from both machines for investigation. You can send them via the diagnostic menu.

All of the advanced options like encryption/compression are not available in the Freeware version, this is a conscious design decision, so I'm afraid the only option is to use the commercial version to decompress/decrypt the data.

No, we already see your address, you'll be sent a message via email regarding that.

That appears to be simple connection issue, you can even see the IP address the software is trying to connect to(although it starts from 127, which is odd). Make sure your cloud provider endpoints are reachable from the machine and software executables are white-listed in Antivirus/firewall applications.