I don't know if this project is still being worked on, I noticed instructions related to development in the site, but the repo is nowhere to be found at the moment so I can't look into this myself. There are at least a couple of discussions on this as well in the Discussion tab :(
The exception occurs when the program is launched and indexes are to be downloaded, I checked with the current release, 1.23.9, and no configuration whatsoever so it uses the defaults for everything. I am running it in Windows 10 22H2 fully up to date and my Internet connection is IPv4 and v6 enabled, in case that has something to do with it.
As it stands, the program is unusable for me I'm afraid, I even checked with Defender and other protections disabled as well in case it was interfering somehow but got the same outcome.
Some ISPs block connections to get updates, in the next update I will try to use a different server for updates
Oh! Thank you, it's appreciated!
I had attached the part of the log where that exception happened in a comment because I had forgotten to in the bug report, but it seems the comment didn't go through.
I wonder if it has to ISPs or there is a problem in the code that handles the connection when IPv6 is present (does Windows default to if both v4 and v6 have valid links?). I noticed yesterday that disabling IPv6 support in the adapter properties made it work, re-enabling it triggered the exception once again.
I'd also mentioned it that comment, perhaps SF didn't like that part of the log contained a URL :/
Hi,
same problem.
Here is a description for source:
http://www.sdi-tool.org/development/
svn:
http://svn.code.sf.net/p/snappy-driver-installer/code/trunk/
would apreciate it, if you could share youre solution.
Thanks B.
Sorry for the delay! I just saw both yours and Sam's messages. I don't think that code is up to date, the last entry in the log is from 2017...
My workaround is to disable IPv6, if I only have an IPv4 link it works as expected. Run "ncpa.cpl" or go to the Network Connections part of the Control Panel, right click your adapter and choose Properties, lastly untick "Internet Protocol Version 6 (TCP/IPv6)".
Disconnect and connect to the network again, just so the OS knows to use IPv4 only and try again.
Check this version - https://driveroff.net/sdi/SDI_R2408.7z
I just checked but behaves the same: if I have IPv6 enabled for the network adapter I get the bad cast exception. Disabling IPv6 and having only IPv4 makes it work.
I don't think the logs are much to go by, but I have attached them to this message, first 2 were when IPv6 was enabled, the last one when I was only using IPv4.
Updated the version - check https://driveroff.net/sdi/SDI_R2408.7z
Hi! Thank you for all of the test builds, I checked a couple of minutes ago, but I'm afraid I am still seeing the same behavior.
I looked into it a bit more, all 3 domains are accessible from my network, nslookup reports the correct IPs and I can get to them through a web browser, for example. Just in case, I checked from networks of 3 other ISPs (Orange, Vodafone and Digi, none block access), their default resolvers also point to the correct addresses.
The only thing I can think of as to why it works for me if I take down the IPv6 link and use IPv4 only, is because Windows defaults to IPv6 first if there is native support for it on the network it is connected to, and none of the domains seem to have AAAA records (only A, only IPv4). I wonder if that has something to do with it, their A records are okay, and the DNS resolvers report their IPv4s correctly. I checked with several resolvers in a web service and compared to the local outputs.
Perhaps we could try adding something else to the log, to try to find which one is the cast that is invalid.
Thanks for the test, I'll see what I can do with the domain settings
Found out, unfortunately our hosts don't provide IPv6, only IPv4
Updating did not help. I still get ERROR: Exception: std::bad_cast
---
Log part:
Saving state in 'logs\2024_09_14__13_37_57__namePC_state.snp'...Listen port: 10240 (connected)
Download limit: 0Kb
Upload limit: 0Kb
Torrent: sdi com ru/SDI_Update.torrent
Waiting for torrent.OK
*** FINISH secondary ***
}2Sync
........DONE
Latest Version: R2408. Up to date.
Updated DriverPacks available: 62
torrent_resume
{torrent_start
ERROR: Exception: std::bad_cast
---
The driverpack seeding also doesn't work.
Russian Internet provider “Rostelecom”
Everything works perfectly fine on the other provider.
A crutch way is to disable IPV6 in the connection settings in windows networks for the duration of the program.
Last edit: Nik 2024-10-02
Same problem behind firewall that need authentification to acces to internet.
I haven't check if I had ipv6 enable on computers having this error.
Thank for the informations.
Last edit: Julien Meyer 2024-10-01
why does the program crash instead of issuing a warning?
Same issue; "Exception: std::badcast The program will self terminate now."
Windows 11 24H2 (build 26100.3194), no VPN.
the solution is still the same - use IPv4 instead of IPv6
Do you when the bug will be fixed?
I doubt my (very new) ISP is blocking the content and causing the app to hard crash.
It is a fact that disabling IPv6 helps. In many countries IPv6 is not supported by ISPs at all, so IPv6 support needs to be introduced very carefully, but yes, it is worth doing.
Last edit: Sam Bounce 2025-03-04
Please check this new version https://driveroff.net/drv/SDI_1.25.3.7z
Same issue, unfortunately.
Thanks, I'll post another version later to check it out as well
Updated, please check https://driveroff.net/drv/SDI_1.25.3.7z
Same again, unfortunately.
The error hasn't gone away. It's still there. Maybe should add a function that will enable and disable the use of traffic via ipv6 ?(additional checkbox in settings)
For now I will have to put on pause the solution to this problem because I do not have IPv6 for a full-fledged test and now a lot of work to update driver-packs, I will release a version without this fix, by the next version I will try to find a solution.