Odd bug with VPNs

This is more of a minor thing, but when I have a VPN tunnel open, using the built-in Windows client, tvrename tries to use the VPN to contact sites, even when it is not the default gateway route. This ends up causing it to not get the proper response from the TheTVDB site. If I disconnect it, then it works properly. Don't know if there is something you can do to fix it, or if this is caused by .Net. Figured I would at least make you aware of the problem.

That's definitely weird. I occasionally use TVRename while a VPN tunnel is connected (like you, not as default route) and its ok.

Does internet explorer behave correctly (i.e. not use the VPN), and/or is there anything in it's proxy settings?

Is this on XP or Vista?

How do you know its trying to use the VPN? Does the VPN block internet traffic, causing all lookups etc. to fail?

This is running on XP, and IE works fine. There are no proxy settings. I know it is going through the VPN because I used wireshark to trace down what it was doing. The other end of the VPN does have a transparent proxy, but the it works fine when I run it in that actual network. (The machine having the problems is my work PC, and I have a VPN to my home.) When it tried to do the theTVDB lookup it causes the app to produce unhandled exception. In retrospect, I should have sent the exception details the first time.

Here is the details:

See the end of this message for details on invoking
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.Xml.XmlException: '', hexadecimal value 0x1F, is an invalid character. Line 1, position 1.
at System.Xml.XmlTextReaderImpl.Throw(Exception e)
at System.Xml.XmlTextReaderImpl.Throw(String res, String[] args)
at System.Xml.XmlTextReaderImpl.ThrowInvalidChar(Int32 pos, Char invChar)
at System.Xml.XmlTextReaderImpl.ParseRootLevelWhitespace()
at System.Xml.XmlTextReaderImpl.ParseDocumentContent()
at System.Xml.XmlTextReaderImpl.Read()
at TVRename.TheTVDB.ProcessTVDBResponse(Stream ms)
at TVRename.TheTVDB.Search(String text)
at TVRename.TheTVDBCodeFinder.bnGoSearch_Click(Object sender, EventArgs e)
at System.Windows.Forms.Control.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ButtonBase.WndProc(Message& m)
at System.Windows.Forms.Button.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)


************** Loaded Assemblies **************
mscorlib
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.1433 (REDBITS.050727-1400)
CodeBase: file:///C:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll
----------------------------------------
TVRename
Assembly Version: 1.0.0.0
Win32 Version:
CodeBase: file:///C:/Program%20Files/TVRename/TVRename.exe
----------------------------------------
msvcm90
Assembly Version: 9.0.21022.8
Win32 Version: 9.00.21022.8
CodeBase: file:///C:/WINDOWS/WinSxS/x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww_d08d0375/msvcm90.dll
----------------------------------------
System.Windows.Forms
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.1433 (REDBITS.050727-1400)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.1433 (REDBITS.050727-1400)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Drawing
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.1433 (REDBITS.050727-1400)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
System.Deployment
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.1433 (REDBITS.050727-1400)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Deployment/2.0.0.0__b03f5f7f11d50a3a/System.Deployment.dll
----------------------------------------
System.Xml
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.1433 (REDBITS.050727-1400)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Xml/2.0.0.0__b77a5c561934e089/System.Xml.dll
----------------------------------------
System.Configuration
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.1433 (REDBITS.050727-1400)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Configuration/2.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll
----------------------------------------
Microsoft.JScript
Assembly Version: 8.0.0.0
Win32 Version: 8.0.50727.1433
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/Microsoft.JScript/8.0.0.0__b03f5f7f11d50a3a/Microsoft.JScript.dll
----------------------------------------

************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.

For example:

<configuration>
<system.windows.forms jitDebugging="true" />
</configuration>

When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.




It looks like something is messing up the XML coming back from thetvdb when you do a search. Can you connect your VPN, then try visiting the following URL in IE, and see how it goes:

http://www.thetvdb.com/api/GetSeries.ph ... nguage=all

Either it'll come up with an XML error (which means its not my fault ), or it'll work and you'll see some XML on screen.

Let me know how it goes. If it works ok, let me know what version of Windows (XP, Vista, Vista 64), and IE (e.g. 6, or 7) you've got installed.

Ok, I finally had a chance to test it.

Fortunately/Unfortunately everything worked fine.
The system in question is running Window XP Pro SP3, my primary IE is 7, however I also have 6, 5.5, 5.01, and 4 installed too. And I checked it all of them and aside from 4 which doesn't understand XML, it worked fine.

Ok, I just did some checking with wireshark and I think I know what the problem is. My home network is configured to use the auto-configure proxy system built into most browsers. Even though that setting is disabled, in the main browser, when your program calls it, it is getting used. That makes it download wpad.dat which returns a http 302 code (with some HTML), which I believe is causing it to bomb. (it redirects it to a version that uses ASP) Just to be sure, I ran the test again with the normal browser and found that it does not make the call. Although it is odd that it does not have a problem when I run it from within my own network, I will have to do some tests to see if it is calling it there, or if it is some bizarre combination of things.

At the very least it might be wise to add some error handling for a 302 code.
Hope this helps.

Hi..

I've better error handling into the next release, so it will now report whatever errors are encountered during downloading.

According to the documentation, "...the Internet Explorer proxy settings are used to detect the proxy." Can you check your IE6 settings as well, and see if they have the auto proxy detection turned on. .NET may be using IE6 instead of IE7.

Another thing you could try is to create a text file called "TVRename.exe.config" in Program Files\TVRename (i.e. alongside the exe) and put in it:


<configuration>
<system.net>
<defaultProxy enabled="false" />
</system.net>
</configuration>

In theory (I haven't tested it), this will tell .NET to not use a proxy, or attempt to auto-detect one.