Not a RedFox Issue Error 12029: Unable to Connect to Internet (VSO Downloader killing Internet connection)

[Ivan]

Feel free to write a hate letter to VSO.

Some hate posts might help, I found this thread in VSO forum:

VSO Downloader changes Internet settings - VSO Software Forum

It seems that VSO Downloader 6 changes my internet settings. After using VSO Downloader I cannot download icons in Office (uses http) and images in received mail.

Downloader sets up a proxy to be able to capture traffic. Some services might not be accessible while Downloader is on Radar mode.

"Some services might not be accessible..." - tssssss....

 

[coopervid]

@James , @Pete and @Ivan : YOU guys should actually address this big f..k-up to VSO directly. I don't think that they did this intentionally.

 

[James]

I don't think that they did this intentionally.

No. They destroy your computer unintentionally.
I suggest folks use software, that actually works and behaves nicely instead. Let me think... AnyStream!

 

[James]

Downloader sets up a proxy to be able to capture traffic. Some services might not be accessible while Downloader is on Radar mode.

I don't remember enabling any "Radar mode". Just installing VSO Downloader 6, starting it once, exiting it.... And Windows' Internet settings are destroyed. And they will stay destroyed after uninstalling this (insert bad words here) software.

 

[Esphyx]

Wow, workarounds for this in several Redfox software, that is what I call going the extra mile in supporting customers!

 

[Lukas]

I stopped using VSO when they set up an aggressive subscription purchase policy I'm proud of software like ANYDVD and ANYSTREAM for their great user support

 

[Whitehair]

I registered here just to pass this along. A few years ago when I had VSO products on my computer but had pretty much stopped using them, I ran into a similar problem as the OP and some others here. Somehow or other I figured out that those VSO programs were causing it. I simply uninstalled all of them and thought I was done with it. Not so. Long story short, I had to use another VSO program called CleanVSO.exe to remove all the hidden junk left over. It worked. I just did a search and VSO still has it at their site - To CleanVSO.exe

 

[James]

I registered here just to pass this along. A few years ago when I had VSO products on my computer but had pretty much stopped using them, I ran into a similar problem as the OP and some others here. Somehow or other I figured out that those VSO programs were causing it. I simply uninstalled all of them and thought I was done with it. Not so. Long story short, I had to use another VSO program called CleanVSO.exe to remove all the hidden junk left over. It worked. I just did a search and VSO still has it at their site - To CleanVSO.exe

CleanVSO.exe is from 2016. I assume it removes the infamous patin-couffin driver, but I doubt it adresses the "VSO Downloader killing the Internet" problem.

 

[vso_team]

Hello, I'm from VSO Software support team. I'll not engage in quality discussion, just provide some pure technical feedback on what was mentioned in the thread.

About the Patin-couffin driver:

It is a very old driver historically used at first for Win95 and when there was no way in the OS to obtain an exclusive use of the burner - which is something needed when burning a media. The burning software must ensure that no other software can send command to the burner that may disrupt the burning task. And yes, it may have conflicted with the then CloneCD/CloneDVD driver.

However, since Microsoft finally implement a documented way to obtain exclusive use (from Windows XP SP3 if I remember correctly), Patin-couffin was no longer needed. We kept it for some time for backward compatibility, as of today, all of our installers are removing the driver if it's there.

Long story short: if present patin-couffin driver can be safely removed. If an installer find it, it'll remove it without notice.


About VSO Downloader:

The "Radar Mode" start a local proxy (pitiproxy.exe) which when enabled will route all http/https traffic through it. It's done by modifying the system settings for proxy. As soon as it's disabled or the software is closed normally, the system's proxy setting is restored to the initial value, in anyway not to capture packets to local proxy.

What could go wrong ? If the proxy process is killed uncooperatively by external mean it may not have the opportunity to reset the system proxy setting to the initial value.
In such case, it's true that the internet connection will not be available. When it's happening, simply start VSO Downloader and stop it cooperatively (with the close button not from the task manager). It should fix the situation.

I find important to state here that we do everything to avoid the situation. Both downloader and the pitiproxy must be unresponsive, killed uncooperatively or crashed at the same time, as they both check their presence and if anything goes wrong ie one of the two is no longer there and responding, the system settings for proxy is reverted to the original state.

To sum it up: yes, downloader when using radar mode set a local proxy, and as soon as the radar mode is disabled the proxy is shut down. That's the only thing that may impact the entire system behaviour. All the other operation are completely sandboxed and don't modify anything on the host computer.


Last but not least: We always did our best to work cooperatively with other installed software.

Sorry for the TL-DR; I hope this helped a little bit.

 

[Pete]

Hello, I'm from VSO Software support team.

Hello vso_team,
thanks for posting here, I think that will do a lot to regain trust in you and your software.

I'll give you some technical information in return.
Patin-couffin was just mentioned in passing and is not really an issue here.
What you explained regarding the proxy process makes sense, but is also not really what this is about.

When starting up your software, the system-wide proxy settings are altered in a way, that breaks HTTP communications, at least partly. Even with no proxy active.
The VSO Downloader does this using InternetSetOptions(INTERNET_OPTION_PER_CONNECTION_OPTION) as far as I can tell and the result is that a vital (and mysterious) flag gets unset.

Very technically:
The registry setting
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Connections -> DefaultConnectionSettings
contains a binary string, holding, among others, the proxy settings.
The byte at offset 8 (0-based) is a bit field with bits 1 to 3 specifying the proxy method (manual, direct, auto, ...).
Bit zero is undocumented and I haven't found any source revealing its meaning, but it is always set to 1. No matter what options you change through the control panel.

VSO Downloader sets it to zero (without ever activating any Proxy or the "Radar Mode") and that is when the trouble starts. Our HTTP connections stop working (unless we ignore Proxy settings entirely).
The control panel will automatically reset it to 1, once simply opened and then closed again, so that is a clear indicator, that this bit should not be zero at all.

Maybe you can figure out, how to avoid clearing that bit, when setting the proxy options.

BTW: this whole bit-zeroing happens, if you just start VSO Downloader right after the installation and don't even interact with it ever in any way. The pure startup of an unconfigured, freshly installed VSO Downloader does this.

EDIT: also - if you manage to find out the actual meaning of that bit, please let me know, I'm curious about this.

 

[James]

BTW: this whole bit-zeroing happens, if you just start VSO Downloader right after the installation and don't even interact with it ever in any way. The pure startup of an unconfigured, freshly installed VSO Downloader does this.

... and the worst thing, even after uninstalling VSO Downloader the destroyed Internet settings remain. @vso_team please fix this problem as soon as possible. Every program using wininet is affected. You might consider releasing a "repair tool" to fix this, or at least publish repair instructions like I wrote here:

Not a RedFox Issue - Error 12029: Unable to Connect to Internet (VSO Downloader killing Internet connection)

Okay this makes perfect sense. Somehow I can't find that driver anywhere on my hard drive after some pretty thorough searching, and still getting the same problem. Remember I am only guessing, I said "if VSO is the issue" I believe this could be the problem, this driver has been problematic in...

forum.redfox.bz

 

[vso_team]

... and the worst thing, even after uninstalling VSO Downloader the destroyed Internet settings remain. @vso_team please fix this problem as soon as possible. Every program using wininet is affected. You might consider releasing a "repair tool" to fix this, or at least publish repair instructions like I wrote here:

Not a RedFox Issue - Error 12029: Unable to Connect to Internet (VSO Downloader killing Internet connection)

Okay this makes perfect sense. Somehow I can't find that driver anywhere on my hard drive after some pretty thorough searching, and still getting the same problem. Remember I am only guessing, I said "if VSO is the issue" I believe this could be the problem, this driver has been problematic in...

forum.redfox.bz

Thank you for these clarifications they will be definitively investigated .
We added it in our bug tracking (not sure I can post direct link to it in anyway it's #14303 ). We will post here an update as soon as a fix is available.

 

[Pete]

Thank you for these clarifications they will be definitively investigated .
We added it in our bug tracking (not sure I can post direct link to it in anyway it's #14303 ). We will post here an update as soon as a fix is available.

Links are fine here, as long as it's not advertising or potentially dangerous (malware) sites.

Some additional information - as James just narrowed down.
Affected applications are ones that

• use WinHTTP and
• access http (unencrypted) pages and
• use the system proxy settings (i.e. no direct or application-specified proxies)

WinHTTP is not widely used anymore, but you can easily reproduce the problem by running Edge in "Internet Explorer mode" and accessing an http-page (not https)

 

[vso_team]

Thank you for these clarifications they will be definitively investigated .
We added it in our bug tracking (not sure I can post direct link to it in anyway it's #14303 ). We will post here an update as soon as a fix is available.

[...]

EDIT: also - if you manage to find out the actual meaning of that bit, please let me know, I'm curious about this.

We think it's a disable bit. If set, proxy is disabled.

As you correctly guessed, we use only InternetQueryOptionW and InternetSetOptionW to get/set the system proxy state.
But what we restore is the configuration that we read when starting up the software - with a check that if when we startup we detect that our proxy is set then we reset immediately the connexion to disabled (so to cover the case of a crashed proxy that have not cleaned up the state).
But if we read a configuration such as to produce this bit to zero, it's probable that on exit we rewrite it exactly as we read it (and it's true that we do it systematically without any consideration of modification).

The tech team that has started some test tell me they can't reproduce the issue of the byte set to 0 in DefaultConnectionSettings of the registry - tested on 2 different computer that doesn't have your software installed.

Maybe a better approach is needed from our side, ie an explicit proxy setting to be used when our proxy is switched off.

 

[Pete]

We think it's a disable bit. If set, proxy is disabled.

It doesn't seem to be that.
If, for example, you configure a specific proxy, the entire byte is 3. So the bit is still set.
As I wrote above, that bit is always set. No matter what proxy settings you configure. Proxy on, proxy off, proxy manual, direct, auto, ...

Or let me put it this way: I have found absolutely no way to unset that bit through the control panel. Only running VSO Downloader will do that.

 

[Pete]

I moved the discussion with @ocd here: https://forum.redfox.bz/threads/no-connection-to-internet-using-version-1-6-8-0.88741/
to avoid confusion, because it's not about the original problem with VSO.

 

[vso_team]

It doesn't seem to be that.
If, for example, you configure a specific proxy, the entire byte is 3. So the bit is still set.
As I wrote above, that bit is always set. No matter what proxy settings you configure. Proxy on, proxy off, proxy manual, direct, auto, ...

Or let me put it this way: I have found absolutely no way to unset that bit through the control panel. Only running VSO Downloader will do that.

well, we only use InternetSetOptionW (the Unicode variant) which is btw the recommended way in the Microsoft documentation.
To setup the proxy we set PROXY_TYPE_PROXY (2), and to reset PROXY_TYPE_DIRECT (1) of the option INTERNET_PER_CONN_FLAGS_UI
The bytes 8-13 reflect in fact exactly what is set in this option.

Here attached a little video demonstrating this.

Edit: after a closer look at the Microsoft documentation (https://learn.microsoft.com/en-us/windows/win32/api/wininet/ns-wininet-internet_per_conn_optiona) they state INTERNET_PER_CONN_FLAGS (the older variant) must be used to restore the connexion type. So we'll try this plus a few extra checks.

 

[Pete]

A

Here attached a little video demonstrating this

Alright, thank you very much for that demo.
I'll tinker with InternetSetOption a bit myself, to see how it impacts the bit.

But - just so we don't confuse bits and bytes: as seen in your video, when you activate your proxy, the byte is set to 2, meaning, that seems to already be an invalid value, because bit 0 is 0. Of course, there is some uncertainty in this, because nobody knows, what that bit really does.
But if you'd configure your proxy manually through the control panel, you would most probably see the byte being set to 3, not 2.

Just for you to reproduce better. My setup was:
Windows 10 VM, absolutely clean, nothing extra installed, not even AnyStream.
The respective byte is 9 in this initial state (auto-detect proxy).

Then

1. install VSO downloader
2. run it - don't touch anything, just have it start

after a few seconds the byte changes to 8. Note, that no proxy has been configured, nothing was done to activate your proxy.

 

[vso_team]

A

Alright, thank you very much for that demo.
I'll tinker with InternetSetOption a bit myself, to see how it impacts the bit.

But - just so we don't confuse bits and bytes: as seen in your video, when you activate your proxy, the byte is set to 2, meaning, that seems to already be an invalid value, because bit 0 is 0. Of course, there is some uncertainty in this, because nobody knows, what that bit really does.
But if you'd configure your proxy manually through the control panel, you would most probably see the byte being set to 3, not 2.

Just for you to reproduce better. My setup was:
Windows 10 VM, absolutely clean, nothing extra installed, not even AnyStream.
The respective byte is 9 in this initial state (auto-detect proxy).

Then

1. install VSO downloader
2. run it - don't touch anything, just have it start

after a few seconds the byte changes to 8. Note, that no proxy has been configured, nothing was done to activate your proxy.

We definitively assume PROXY_TYPE_DIRECT(1) is exclusive to any other values as microsoft say "The connection does not use a proxy server" so it's logical to think it's not set when any other bit is set - and it's probable that somewhere in our code we enforce this.

If we need to leave it set then be it - it'll be done.

 

[Pete]

We definitively assume PROXY_TYPE_DIRECT(1) is exclusive to any other values

Yes, I would read it the same way. Still it somehow screws things up.
Considering, that the values are all powers of two (1, 2, 4, 8), it does indicate, that they are meant to be combined.
Still doing some testing... I'll let you know.