This project is read-only.

Unexpected disconnects

Nov 27, 2010 at 6:50 PM

My application is managing the RAS dialup connection

via GPRS modem (COM1). Only one network dialup connection

is configured. Looks like everything is working fine, but - from time

to time the connection unexpectedly dropped by someone (not sure who is

resposible for these disconnects). I see the 'Disconnected'

status at the 'Network connections' in the control panel. But

no 'Disconnected' notifications received via RasConnectionWatcher.

Moreover, after such a disconnects the dialup connection become completly

unusable. Any further attempt to dial using this connection entry (from my application

or even from the control panel) lead to 633 (The modem (or other connecting device)

is already in use or is not configured properly) or even 1727 (something related to rpc)

errors. After such a disconnect only reboot can help.


DotRas latest 1.2, WinXp SP2. net fw 3.5 sp1.


Any help will be very appreciated.

Nov 28, 2010 at 3:22 AM

The Disconnected event raised by RasConnectionWatcher should only occur once the connection has been fully established and gone to the connected state. So if RasDialer is still reporting the connection is underway, it wouldn't be raised. The RasDialer component does report what happens during a connection attempt via the OnError (if something happens while processing one of the events raised on the background thread), or by StateChanged and DialCompleted when dialing asychronously. Synchronous dialing will simply throw an exception. The component doesn't terminate a connection unless there is an error while connecting, and it will report what that error was from the DialCompleted event.

As for the 633 error, are you ensuring you're disposing of the component? The RasDialer component uses unmanaged resources, and failure to do so can corrupt the connection state machine in Windows which would cause the 633 error you're seeing.

Nov 28, 2010 at 7:02 AM

The application contains only one instance of RasDialer - never disposes it and never tries to create new one (btw - the app must be running very long without reboot - days or so).

Dialing is always synchronous. When i try to manage the connection outside my app, for example - from control panel from right click menu - Connect/Disconnect - i can see the correct events

and can handle them accordingly (actually, at the moment i'm only write the log entries - nothing more). Also the connection entry is configured to do not drop the connection when it is idle (at least the corresponding combobox in connection entry

configuration uses 'never' value, to be sure i'm also set it manually on startup in app code: IdleDisconnectSeconds = 0). So i'm really don't know who is responsible disconnecting the communication link (and i'm also think that it is not important

because there are a lot of other reasons why the connection can be dropped).

The main pain is not in the outside disconnects - but in 633 and 1727 (sometimes 1722) errors when such a disconnects happens (but not when i'm connect/disconnect manually using control panel - everything is working as expected). The 1727 is thrown not only when i'm trying

to (re)dial the connection, and even when i'm trying to detect the status of the active connection: DotRas.RasConnection.GetActiveConnections() throws DotRas.RasException with code 1727 (btw, the control panel shows the 1727 too).

Any further dial attempt fails with 633 (both from my app and control panel).


Nov 29, 2010 at 9:44 PM

We had an issue similar to this with the RC1 release for 1.2 that was fixed for asynchronous calls, but it looks like it also exists within synchronous as well. Basically the problem is there's an error being thrown from the dial method, and the connection handle isn't being released.

This is definitely a code problem, I just glanced at it and the handle would never be released if an exception is thrown during a synchronous connection attempt. Normally what'll happen is a 668 error is returned indicating the connection was closed (if trying to dial too soon), and that handle is then left open. Any subsequent attempts to dial the same connection result in a 633 error being thrown indicating it's already being dialed.

You should be able to confirm this by adding a timer with a 3-5 minute interval between when the RasConnectionWatcher disconnected event is raised, and when the dial method is called on the dialer. Here's a link to a similar discussion when dialing asynchronously:

Nov 29, 2010 at 9:46 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.