This project is read-only.

DialAsync Timeout errors

Jan 28, 2010 at 10:19 PM

Hi Jeff,

I'm having trouble with the DotRas library crashing my application once the connection timed out during a Asynchronous Dial attempt in Windows 7 x64.

The stack trace is:

DotRas.dll!DotRas.ThrowHelper.ThrowRasException(int errorCode = 668) Line 125    C#
dll!DotRas.RasHelper.HangUp(DotRas.RasHandle handle = {DotRas.RasHandle}) Line 1529 + 0x8 bytes    C#
dll!DotRas.RasDialer.Abort() Line 596 + 0xd bytes    C#
dll!DotRas.RasDialer.RasDialCallback(int callbackId = 0, int subEntryId = 1, System.IntPtr dangerousHandle = 851968, int message = 52429, DotRas.RasConnectionState state = Disconnected, int errorCode = 619, int extendedErrorCode = 0) Line 750 + 0xc bytes    C#


This occurs after the State has changed like follow:
OpenPort, PortOpened, ConnectDevice, DeviceConnected, AllDevicesConnected, Authenticate, AuthNotify, AuthNotify, Disconnected

The error actually occurs a couple of seconds after the state changed to disconnected, since the Timeout value is like 30 seconds and the connection disconnected after like 10 seconds.

My problem is that your library is throwing an error (Code: '668', Message: 'The connection was terminated.'), but I have no idea of where I should catch it?! I have even tried my application with the DotRas 54557 (19 Jan 2010) source.
My source code is available from: I'm doing basically all of the DotRas dialer handling in the VirtualInterface.cs file if you perhaps have the time to look at it.

Help would be appreciated very much. I guess the quickest would be to tell me where to catch the exception if that would be possible. Otherwise I'll "hack" your code until it works :)


Jan 29, 2010 at 3:16 AM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Jan 29, 2010 at 3:20 AM

It was a problem inside the RAS callback that you couldn't have caught anywhere. That callback is used by Windows to report the status of a connection attempt as it changes, which when the error code is not 0 (aka, a failure) the connection must be disconnected or it will be left in an inconsistent state and require the machine to be rebooted before it can be dialed again. With that said, this was one of those errors that had to happen before I could fix it.

I've already got the fix checked in, just grab the lastest from the source code and compile it. You should be good to go.

Let me know if you have any other problems!

Feb 2, 2010 at 12:53 AM

Thanks again for your support & quick response - its greatly appreciated.

I was unable to access DotRas lately due to big international Internet connectivity issues in South Africa :(
I'll let you know if this fix made my app bug free.

Feb 2, 2010 at 2:48 AM

Hi Jeff,

I have no realised that since I've compiled your code (thus after v1.1), an issue slipped in where the stored credentials aren't loaded correctly from the phonebook/wherever Windows saves it.

I've created an Issue WorkItem here:

Thanks for fixing the previous bug!


Feb 2, 2010 at 6:36 AM
Edited Feb 2, 2010 at 6:41 AM

That's actually not a bug, it's a feature with 1.2. You just need to set the AllowUseStoredCredentials property to true on the dialer to enable it. Since there was no way to disable this in 1.1, it could cause a security concern, so I made a way to opt-in to enable the functionality. It's going to be documented as a breaking change on the 1.2 download page when it's released.

Hope that helps.

- Jeff

Edit: It's actually already been documented in the 1.2 release as a feature. If you have any questions about upgrading from 1.1 to 1.2, check the planned downloads. Whenever I make notable changes to the project I make sure to edit the upcoming release.

Feb 2, 2010 at 9:59 AM


I did enable the AllowUseStoredCredentials, but I did that before setting the PhoneBookPath & EntryName. The only difference I saw was that when it was set to false, it timed out after 1 retry, and it didn't timeout when I set it to true.

For some reason it's working 100% when I have it enabled, even if I enable it before setting the PhoneBookPath / EntryName. I think my Wireless connection was just in a poor shape which caused unexpected problems to occur. I'll update my application if everything you've done & said would fix my "bugs".

Feb 2, 2010 at 3:50 PM

AllowUseStoredCredentials just allows the internal dialing method to retrieve the credentials from the credential store if none have been provided to the dialer. If it's set to false and you're not providing any credentials, it's the same as if you were trying to connect to the server without providing a username/password. If you want the dialer to be able to use the stored credentials, set it to true. Rather than the project forcing you to use stored credentials, I've given the developer using it the ability to make that choice for themselves.

Feb 3, 2010 at 4:17 AM

I did a little research this evening to determine exactly what is causing the timeout. From what I've seen, you're hitting the timeout due to not providing credentials to the dialer. This happens because you A) did not set AllowUseStoredCredentials to true on the dialer or B) you did not provide credentials to the Credentials property for the dialer to use during the connection attempt. What's going on is once the Authenticate phase of the attempt completes, you'll start receiving AuthNotify states until some point when an outside source terminates the connection; whether that source is the client or server I do not know.

Since you're using the timeout, the AuthNotify state has repeated enough that it's caused you to progress beyond the duration of the timeout and causing the dialer to cancel the connection attempt itself.

Hope that helps.

Feb 3, 2010 at 11:06 PM

Thank you for the explanaition.

I've compiled your latest changeset and published my app again. It seems like its working 100% now, since I haven't received replies on my topic yet stating that its broken...