All Activity

I don't think there will be many users of the 64-bit version that also have an old local DNS resolver, but nevertheless I will downgrade curl_cffi to version 0.13.0 for the next release. Forcing these modern DNS extensions on a legacy-OS target is counter-productive anyway. Meanwhile, here is a 64-bit test version, so we can see if curl_cffi 0.13.0 doesn't give issues for you with 2026.01.19.143412.

thats too new. according to http://ideje.hu/collab/tiki-index.php?page=Windows-UCRT-versions , the last XP compatible UCRT is 16.7 (file version 14.27.29114.0)

Have not been able to test much on real hardware lately since I'm not at home. I feel like it's got to be some interaction between the legacy CSM and interrupts not getting delivered properly when the IRQ is shared. In the worst case I can stop using the buffer completion interrupts and just schedule a DPC every 10ms instead.

That's it!!! Oh lord , what a waste of day doing tests back and forth, searching for alternatives, finding BIND9 stopped support for Windows on 9.17.14.... Anything, but not with the x86 build... I'll end with a correction to myself. I should have said that EDNS is not for security only. I always mix it with DNSSEC (which actually is a feature of the upstream curl utility), despite this requires EDNS, too.But, anyway, there is no need for such implementation, IMHO.

Will experiment. On the computer I am on now, all four are UNCHECKED. I would assume that if the bottom three are UNCHECKED that it doesn't matter if the top is checked or not (I'm not hearing any difference). The bigger test will be on my other computers.

Sweet! I'm so huge into *everything* PORTABLE that I have never installed *any* C++ runtime. None. Naughta. Zilch. I prefer to manually place the SMALL HANDFUL of .dll's that some programs require to be SELF-CONTAINED within that program's OWN ROOT DIR. It's almost always the same two or three or four .dll's and even though my setup has those existing as "duplicates" across my hard drive, it's still MUCH LESS space than the full runtimes. Kind of like how several .dll's land in the root dirs of things like Supermium, Mypal, Serpent, etc.

Disable enhancements over HDMI to avoid over-bassiness.

@johk What happens if you switch to the 32-bit yt-dlp variant for Win7 ? https://github.com/nicolaasjan/yt-dlp/releases/download/2026.01.19.143412/yt-dlp_x86_win7.exe That one doesn't come with the curl_cffi Python module bundled (it's currently only 64-bit); some sites require this module to work, but NOT youtube.com (yet) ... curl_cffi is a Python binding (wrapper) for curl-impersonate, not for "ordinary" curl ; curl-impersonate uses Google's BoringSSL crypto lib (not Libre/OpenSSL), making it incompatible with < Win7 (I have Vista) ... curl 8.15.0-IMPERSONATE (Windows) libcurl/8.15.0-IMPERSONATE BoringSSL zlib/1.3 brotli/1.1.0 zstd/1.5.6 c-ares/1.30.0 WinIDN nghttp2/1.63.0 ngtcp2/1.11.0 nghttp3/1.9.0 Release-Date: [unreleased] Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns ldap ldaps mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp ws wss Features: alt-svc AsynchDNS brotli ECH HSTS HTTP2 HTTP3 HTTPS-proxy HTTPSRR IDN IPv6 Largefile libz NTLM SSL SSLS-EXPORT threadsafe Unicode UnixSockets zstd

OK, it's fixed! The portable version worked fine, and in fact if I ran the firefox.exe in the portable version's program folder, rather than firefoxportable.exe, it opened fine using my normal Firefox profile! So, I started comparing the two installations, and found that some DLLs in my Firefox program folder appeared to have been disabled by renaming 'DLL' to 'D~L'. That's my normal way of disabling a file, changing the middle character of the extension to '~'. Why I had done that is lost in the mists of time in this case, but one disabled DLL file stood out, and that was msvcp140.dll, which is a C++ Runtime file of course. That reminded me that I had recently updated my C++ 2015-2019 Runtime to 14.29.30139, following a recommendation elsewhere on MSFN. Thinking perhaps this could be the issue, I simply renamed the msvcp140.dll file in the Firefox folder back to normal, and everything came good! So, I guess the new system runtime file versions may not actually be compatible with all programs, so I will now be on the lookout for any other seldom-used programs which no longer work. Thanks everyone for the help as always! Cheers, Dave.

Good stuff

It is actually the curl stage, as it is what it fails when can't do an OPT DNS query type 41 hex (65 is the decimal conversion)). No, my DNS server/resolver software doesn't support it. I should have told, but I got tired of test, renames, edits... oh dear... I know the software is old, but trusted, but, also, there shouldn't be need to hardcode EDNS queries on curl. Too paranoid, in my opinion. I tested with the "--force-ipv4" and it is the same. If the curl update is really necessary... I'll have to change the software, but it is really dumb reason :/ It works if I redirect queries to an external resolver (example: 1.1.1.1)... but defeats the purpose of using a local one in first place Do you know what is really curious? That I almost always perform formats queries first, and it does this without a problem (querying correctly an A record for www.youtube.com), but when queries it again (or direct download, without query formats first) for download... In other words, it happens at download time In the version of curl I have I don't have such an EDNS option to test.

It could be, that the issue has arisen because I updated to the module curl_cffi 0.14.0. What happens when you add the `--force-ipv4` flag to your yt-dlp command?

No, Firefox was not open when I uninstalled Malwarebytes. I hardly ever use it now. Thanks for the link to the portable version, I will give it a try and report back.

What is the output of : nslookup -querytype=TYPE65 www.youtube.com (this checks if your local resolver/OS handles Type 65 queries correctly outside of yt-dlp) And what is the output of a --verbose log?

I have little to no understanding of networking, so I'm afraid I can´t help you with this particular issue. I just tested a random video from YouTube in my Windows 7 VM and all went fine.

Oh, and I didn't think about asking this earlier, but when you tried to uninstall Malwarebytes and it resulted in your computer REBOOTING itself (prompting a Safe Mode uninstall of Malwarebytes), was Firefox OPEN when Malwarebytes uninstall crashed your system into a reboot?

If it does NOT launch, then clench your fists, pound one sternly but in full control of anger level on desktop but make sure you miss keyboard and mouse, grab something in the other hand and controllably throw something without breaking it or anything it hits, raise your voice level approx 15 decibels (whereas 30 decibels is the increase of a raging uncontrolled shout), and shout out this phrase, "Curse You, Malwarebytes, You Did This!"

If it DOES launch, then you should be able to REPLACE all of the .exe/.dll/etc root dir files/folders of your "installed" version and it should now also launch.

Try the PortableApps Portable Legacy 52 and see if it launches. It will not affect other Firefox installs/profiles. https://portableapps.com/apps/internet/firefox-portable-legacy-52

OK, I tried disabling the current Firefox profile (by renaming its folder and making a new empty folder with the same name). Firefox still didn't start, with the same immediate error. I think that means the issue is nothing to do with anything in the profile.

r3dfox (and firefox) will still upgrade the connection to HTTPS, even if the relevant setting, HTTPS-Only Mode, under "about:preferences#privacy", has been manually set to "Don’t enable HTTPS-Only Mode" ... https://support.mozilla.org/en-US/kb/https-only-prefs https://support.mozilla.org/en-US/kb/https-upgrades I had to first enable HTTPS-Only Mode in all windows, and then configure an exception just for "o.rthost.win" ...

As I don't think that it is fair to report this to yt-dlp, as I'm using your builds under Windows 7 (and the officials aren't valid for this), and so, just in case, the fault is in this build, I want to tell that your latest, this is 2026.01.19.143412, but not the previous, this is 2026.01.18.152406, there is a problem with DNS resolving. Instead request the OS to resolve an A DNS record (this is the IPv4 IP) for the host of the video www.youtube.com (after re-review is not the host of the video, it doesn't even reach that step, is www.youtube.com), requests a ?65? DNS record (question mark, 6, 5, question mark), that is absolutely invalid (there is no such record in the standard and so replies the Google DNS server). I use my own DNS resolver (local resolver, I mean, not external) and so I can inspect what is going on with DNS requests and so I'm seen it and reporting it. Where is the fault coming? I don't have the knowledge to tell. Just that in the 18th of January, it works OK. Regards. EDIT: just to add up, I double checked the hash and file download isn't corrupted. EDIT2: now that I think about it... 65 matches to the decimal value of the character A (capital A)... Might be some sort of UTF or ASCII thing? DNS is pure ASCII (or maybe ANSI), so no clue what has been introduced this issue. LAST EDIT: ok I wasted the time digging it, using wireshark in loopback mode, and 65 means code 41, which means EDNS. Why on earth yt-dlp is now requesting an EDNS record for www.youtube.com :-?

The article I linked to, https://habr.com/ru/articles/856602/ is, supposedly, intended for free-tier users, with an addition in the end "For paid CloudFlare users" ; but I'm not sure disabling ECH works anymore, as this statement from June 2025 indicates: https://github.com/win32ss/supermium/issues/1485#issue-3189002561 ...

VK crash is known even in upstream, so far there is no solution or workaround. better using chrome-based browser for this.

basilisk52-g4.8.win32-git-20260117-3219d2d-uxp-aace8fa8c0-xpmod crashes when opening https://vk.com: