We appreciate the contributions many of you have been able to make towards repairing the storm damage and keeping a roof over our heads. With your help we’ve been able to complete much of the critical work. There is still work to be done to secure the house and your continued support will be a huge help.
Guests have read-only access to our forums. If you wish to participate you will need to register. Be sure to activate your account from the email sent to you when you register.
I did some more testing today following the above screenshot.
Win 11 Home 25H2, Build 26200.6899
The bad_cast error occurred 4 times in the following circumstances:
1. While downloading a driver pack
2. After completion of downloading indexes
3. During driver installation of a Realtek ethernet driver
4. While download indexes
Of note is the fact that doing exactly the same steps does not reproduce the error. My feeling is it's not necessarily related to what the foreground is doing.
The other thing I note (which may or may not be related) is that after a driver pack download is finished, the process cpu usage is up around 15% while idle.
So the bug remains unreproducable despite me having seen it. I acknowledge all the useful bug reports thus far. However, I'm yet to see a convincing pattern or a set of steps that will always reproduce the bug except that it seems to happen during or after a driver pack download so the bug could be in the libtorrent library somewhere (!).
The 15% CPU Mystery: Concurrency and Multithreading
I reckon what Glenn mentions about the CPU usage jumping up around 15% during idle is a classic symptom of an infinite loop or a hung thread (a race condition).
Torrent downloads run on separate processing threads so the program’s UI doesn't freeze up while you're downloading. Once that massive 56 GB file finishes downloading, the download thread is supposed to wrap up and hand the file over to the verification thread. If the network library gets stuck waiting for a response from a port or an IPv6 address that was butchered by the DNS translation, that thread can end up trapped in an infinite retry loop at full throttle. That's likely what's chewing up that 15% CPU on a single core, right until it eventually hits the wall and throws the std::bad_cast.
That’s probably why Glenn had such a tough time replicating it; it depended on connection speeds, the exact millisecond the packet finished, and how the user's router handled those network requests right at that very moment. A proper headache for a dev, no doubt!
Just adding my experience with this same error. I found that selecting each of the three driver paks one at a time will bypass this issue. I too am running Windows 11 25H2 🤔 Grok concluded that the solution that worked for most was to disable IPv6 on your active network adapter
instead disabling whole IPv6 , blocking IPv6 outbound with address 2000::/3 in Windows firewall for SDIO process works here.
Whatever is happening "seems" to be occurring whenever the SDIO*# packs are being downloaded. That's been my experience and remains so with my current clean install of the latest version of Windows 11. I did in fact choose to download all the relevant driver packs via Torrent just to avoid any issues. Placing the files in the drivers folder inside the main SDIO folder triggered the application to index the files and then install the ones that were needed without any issues.
Edition Windows 11 Home
Version 26H1
Installed on 7/6/2026
OS build 28000.2340
Experience Windows Feature Experience Pack 1000.26100.315.0
I'm getting this error on a laptop.
What is the fix?
I managed to get past the error.
I noticed that when I clicked on Expert Mode, it would crash when downloading drivers. When I opened it again, Expert Mode wasn't enabled.
I opened SDIO again and enabled Expert Mode, then immediately closed it before any crashes. sdio.cfg was created, and when I opened SDIO again, Expert Mode was enabled this time, and I was able to download drivers without any crashes.
I am guessing this crashing is related to sdio.cfg.
I found that the problem is 64bit exe of snappy driver, i use 32bit version of exe and the problem disapper.