Error 663 connecting to VPN


  • I have upgraded my 8.1 system to Windows 10. I have getting since error 663 while connecting to VPN. Checking for port 1723 does not show any process. The only way to restore VPN is to restart. Please help.


    Wednesday, October 8, 2014 10:03 AM

All replies

  • Hi markgoldin,

    My name is Adam and I am with Microsoft Beta support. I assume you are getting "The media .INI file refers to an unknown device type" then correct? I would recommend performing the following steps:

    • Check System/Application Event Viewer logs to see if any events are logged at the same time you are thrown the error message.
    • Gather more logging for using 'netsh ras set tracing * enabled' from powershell and then reviewing the logs at %systemroot%\tracing.
    • Gather procmon trace to look for *.ini in the area path to determine what infi file its attempting to locate.

    Let me know what you find. If you need assistance looking through the data, let me know and I can provide an email address for you to send the data to.


    Adam Rudell | Sr Support Engineer | Windows Beta | Microsoft Corporation

    Wednesday, October 8, 2014 2:56 PM
  • No, I am not getting "The media .INI file refers to an unknown device type" .

    I am getting:

    Error 633: The modem (or other connecting device) is already in use or not configured properly.

    Wednesday, October 8, 2014 3:04 PM
  • Hi markgoldin,

    Thanks for the clarification. When you are encountering the error message, what do you get when running the following command?

    • netsh int ipv4 show tcpconnections localport=1723

    Also, have you tried the steps listed in KB 885959 to reserve the port and use netstat -ano to locate and terminate any PID that might be associated with that process?


    Adam Rudell | Sr Support Engineer | Windows Beta | Microsoft Corporation

    Wednesday, October 8, 2014 5:23 PM
  • I will run this particular command. But running netstat-a or something that lists all ports did not show port 1723 being used.
    Wednesday, October 8, 2014 5:28 PM
  • Sounds good! Keep me posted! The main reason for the netsh command is its just a more targeted approach rather than looking through a list of ports. The other thing would be to create the registry key to reserve the port and monitor to see if issue persists.

    If issue persists, then issue isn't actually anything to do with an application using port, but might be a driver issue from what my research has shown me.

    Adam Rudell | Sr Support Engineer | Windows Beta | Microsoft Corporation

    Wednesday, October 8, 2014 5:38 PM
  • I am almost sure that nothing keeps 1723 busy. Tell me how to modify Registry, please. also is there a way of resetting this port?
    Wednesday, October 8, 2014 5:41 PM
  • The steps to configure the registry are outlined in KB 885959 to set the ReservedPorts key. Once the key has been configured, reboot the machine and then monitor. If for some reason you get the error message again, then run the netsh command previously recommend to see if anything already using the port. 

    Essentially the best way to close a port is to identify and terminate the process that is listening on that port. netstat is ideal for that and if issue happens again, this would be another command to run and output results to text file 'netstat > c:\netstatout.txt' so we can then look to determine the state of the port. 'netstat -ano' would output the ports and the process id which then you can use 'taskkill /PID ## /F' to terminate the process.

    Adam Rudell | Sr Support Engineer | Windows Beta | Microsoft Corporation

    Wednesday, October 8, 2014 5:53 PM
  • But 1723 is NOT allocated, that is the beauty of my situation.   
    Wednesday, October 8, 2014 5:57 PM
  • Can you perform the registry key steps just to confirm this is not a quick fix to get around the issue?

    Like I said, if this is not the actual cause like you are indicating, then further digging would be necessary into why it believes the port is already in use. Also can you answer the following?

    • Can you reproduce the behavior on demand? You indicate that you have to restart in order for you to reconnect VPN. Does issue only happen after you have connected to VPN previously and then either terminate VPN connection or let machine go to sleep? The more detailed the steps are to reproduce the behavior the better.
    • Are you using a 3rd party VPN software at all such as Cisco or SonicWall or another provider?

    Adam Rudell | Sr Support Engineer | Windows Beta | Microsoft Corporation

    Wednesday, October 8, 2014 6:38 PM
  • I am using Microsoft. Yes, usually it happens on a second run or so.
    Thursday, October 9, 2014 1:02 AM
  • I'm having the exact same issue.

    The following is logged in the event viewer when trying to connect:

    Source: RasClient

    Event ID: 20227

    CoId={65B1D8D0-BF50-4655-8030-0D2388A2969A}: The user SYSTEM dialed a connection named ***** which has failed. The error code returned on failure is 633.

    Steps to reproduce:

    Works after a reboot.

    Put computer to sleep

    Wake computer from sleep

    Error 633 occurs when connecting to VPN 

    Works again after a reboot

    Tracing logs available here: http://1drv.ms/1vOwiNI

    Thursday, October 9, 2014 7:56 AM
  • Exactly the same here. After bringing computer back it fails with

    CoId={EAF31CF9-26DB-4755-8B36-4687CDE3845C}: The user SYSTEM dialed a connection named xxxx which has failed. The error code returned on failure is 633.

    Thursday, October 9, 2014 10:43 AM
  • Just noticed that even shutting down doesn't work, only a reboot solves the problem
    Saturday, October 11, 2014 6:13 PM
  • The problem is on Remote Access Connection Manager

    When you start VPN RACM is running and you can't Stop it

    When you stop VPN RACM still running but You can Stop it

    If you hybernate PC when RACM is running at wakeup you can't stop RACM and VPN is not active then 633

    WHY  ?

    I think this is a BUG on RACM

    (P.S.) Also for me 

    OS Name:                   Microsoft Windows Technical Preview
    OS Version:                6.4.9841 N/A Build 9841

    Sunday, October 12, 2014 8:10 PM
  • SOLVED !!! :))

    Go to C:\windows\system32 and copy svchost to svchost-w1

    Edit registry for Service Remote Access Connection Manager and use svchost-w1.exe -k netsvc

    Now you can start VPN and Hybernate PC , at WahkeUp if VPN give 633 error bla bla bla 

    You go to Task Manager and on Tab Detail kill svchost-w1.exe process

    Now VPN start ...

    the worst workaround than ever but for me WORK

    Monday, October 13, 2014 7:42 PM
  • Thanks for the feedback and workaround to the issue that you have identified! I am working on reproducing the issue myself in house and will then be passing along the feedback to the product group for further review.

    Adam Rudell | Sr Support Engineer | Windows Beta | Microsoft Corporation

    Monday, October 13, 2014 8:55 PM
  • I have the same issue on a clean install of Windows Tech Preview x64 Enterprise. TCP port 1723 not in use. Port reserved. On a first boot from home I get the error 633 when I try to connect to work VPN. If I reboot it works. Always have to reboot to connect to VPN from home.
    Wednesday, October 15, 2014 1:05 AM
  • I'm having the exact same issue, error 663.  Only a restart will allow me to connect to VPN.
    Thursday, October 16, 2014 2:13 PM
  • For reference, there's more info on this issue in this thread, along with an apparent workaround, though as I pointed out there I have no idea why that would work.

    Instead, I merged tenshin8488's solution above with a variant on the Task Scheduler idea. In rough form:

    -Make the suggested file copy to \windows\system32.

    -Do the rename for your new file here (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan)

    -Create a new administrative scheduled task: the Trigger should be "On an Event" and geared to the System Log with a Source of Power-Troubleshooter and an Event ID of 1 (meaning resume from sleep). The Action: taskkill /F /IM svchost-w1.exe /T.   Check the box for "Delay" task for 1 minute. Making it a "Hidden" task should work, so you don't see the black box, but I haven't tried that yet. 

    Friday, October 24, 2014 4:25 PM
  • Not fixed in 9879, in case anyone was wondering.
    Saturday, November 15, 2014 9:26 PM