History: The history of this error, which has mostly gone unsolved, dates back to Windows 2000.

Platforms affected: Windows Server 2008 R2, Server 2008, Server 2003 R2, Server 2003, Server 2000 (both 32-bit and 64-bit installs are affected).

Error Messages

  1. Event ID: 7024 The Routing and Remote Access service terminated with service-specific error 2 (0x2).
  2. Event ID: 7024 The Routing and Remote Access service terminated with service-specific error 31 (0x1F).
  3. Event ID: 7024 The Routing and Remote Access service terminated with service-specific error 20205 (0x4EED).
  4. Event ID: 7024 The Routing and Remote Access service terminated with service-specific error 193 (0xC1).
  5. Event ID: 20103 Unable to load C:\WINDOWS\System32\iprtrmgr.dll . (32-bit installs).
  6. Event ID: 20103 Unable to load C:\WINDOWS\SysWOW64\iprtrmgr.dll . (64-bit installs).
  • You're welcome to post a question and self-answer. As this is written now, a question only, it's a bit of a mess to sort.
    – jscott
    Jun 19, 2012 at 19:58
  • Everyone stand back! I'm about to try and edit this thing into coherence... (but seriously, next time glance at the formatting of the question text. You're not endearing yourself to anyone with WALL-O-TEXT.)
    – Wesley
    Jun 19, 2012 at 19:58
  • @WesleyDavid Whew, thanks for that. Tried to sort the question bits from the answer bits, but mostly I was getting too anxious with the scalpel.
    – jscott
    Jun 19, 2012 at 20:02
  • I beat you all to it :)
    – growse
    Jun 19, 2012 at 20:03
  • @growse I hate you. Except I'm going to steal the answer and post it as my own now! MUHAHAHA!!!
    – Wesley
    Jun 19, 2012 at 20:03

4 Answers 4


(This is KCotreau's original answer, but he included it in the question. Re-posting as an actual answer)

Cause: There are two basic causes for this error.

  1. An incorrect key in the registry if you are running IPv6.
  2. TCP/IPv4 corruption.

Related causes

This has happened to me on a couple of Dell Windows 2003 R2 64-bit servers that had Broadcom NetXtreme II adapters. My problem was the second cause above, TCP/IP corruption, which I believe that happens for some reason when you install the driver for the Broadcom adapter. It certainly may happen with other adapters, but there were definitely a high number of unsolved cases on the Internet with various Broadcom adapters.

Additional factors

This happened even on clean installs as I tested using both the Dell-specific Windows Server 2003 R2 media, and Microsoft media downloaded from the Volume License site. It happens with either media.

Troubleshooting that did not work for me, or most people on the Internet:

  1. Reinstalling clean.
  2. Running sfc /scannow (I got no errors).
  3. Comparing, and replacing, the iprtrmgr.dll’s from a working server.
  4. Reinstalling the NIC’s after deleting them from Device Manager.
  5. Running NETSH INT IP RESET C:\reset.log or NETSH RESET WINSOCK.
  7. Checking for ghost adapters after setting devmgr_show_nonpresent_devices=1 and then showing hidden devices in Device Manager (I had none).
  8. Reregistering Oledb32.dll and Oledb32r.dll , and renaming C:\Windows\System32\ias \dnary.mdb, and ias.mdb files and restarting RRAS. Those files are located in the C:\Windows\SysWOW64 directory on 64-bit systems. This was in KB840696 http://support.microsoft.com/kb/840686.


  1. If you have Server 2008, and are running TCP/IPv6, your problem is probably not TCP/IPv4 corruption, but rather that you have this extra key, HKEY_LOCAL_MACHINE\System\currentcontrolset\services\remoteaccess\routermanagers\IPV6, which you will remove after you back it up by exporting it. Removing this key was an easy solution that widely helped many people on the Internet. If you still want to use the TCP/IPv6 protocol you may have to do more. Since I did not apply to my server, and I could not test it, you may still have IPv6 corruption, and may want to troubleshoot by removing and reinstalling the TCP/IPv6, akin to the solution below. The above solution may just be masking potential corruption by avoiding the issue.
  2. If you are not running IPv6, the chances are that you have TCP/IPv4 corruption, and the solution is to reinstall it. If you have never noticed, if you try to uninstall TCP/IP, it is grayed out. To get around that, I followed KB 325356: http://support.microsoft.com/kb/325356 . That says it is for a domain controller, but works on member servers also. The steps are:

    • Just in case, disable RRAS in the RRAS mmc, as this will uninstall it.
    • Backup your registry.
    • Ignore steps 1-4, and step 21 if you are just on a member server.
  3. Restart the domain controller.
  4. When the BIOS information appears, press F8.
  5. Select Directory Services Restore Mode, and then press ENTER.
  6. Use the Directory Services Restore Mode password to log on.
  7. Click Start, and then click Run.
  8. In the Open box, type regedit, and then click OK.
  9. Locate the following registry subkeys:
    • HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Winsock
    • HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Winsock2
  10. Right-click each key, and then click Delete.
  11. Click Yes to confirm the deletion of each key.
  12. Close Regedit.
  13. Locate the Nettcpip.inf file in %winroot%\inf, and then open the file in Notepad.
  14. Locate the [MS_TCPIP.PrimaryInstall] section.
  15. Edit the Characteristics = 0xa0 entry and replace 0xa0 with 0x80.
  16. Save the file, and then exit Notepad.
  17. In Control Panel, double-click Network Connections, right-click Local Area Connection, and then select Properties.
  18. On the General tab, click Install, select Protocol, and then click Add.
  19. In the Select Network Protocols window, click Have Disk.
  20. In the Copy manufacturer's files from: text box, type c:\windows\inf, and then click OK.
  21. Select Internet Protocol (TCP/IP), and then click OK. (Note: This step will return you to the Local Area Connection Properties screen, but now the Uninstall button is available).
  22. Select Internet Protocol (TCP/IP), click Uninstall, and then click Yes.
  23. Restart your computer, and then select Directory Services Restore Mode as mentioned in steps 2 - 4.
  24. In Control Panel, double-click Network Connections, right-click Local Area Connection, and then select Properties.
  25. On the General tab, click Install, select Protocol, and then click Add.
  26. In the Select Network Protocols window, click Have Disk.
  27. In the Copy Manufacturer's files from text box, type c:\windows\inf, and then click OK.
  28. Select Internet Protocol (TCP/IP), and then click OK.
  29. Restart your computer.

Configure and Enable Routing and Remote Access. At this point, your RRAS should start.

Related problem and solution:

When I would enter a static IP address, although it would hold the static, the properties would reset back to "Obtain an IP address automatically". Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Network and delete the Config key. Reenter your static settings, and they should hold, and rebuild that Config key.

I hope this solves this difficult problem for many of you.


I know this is a hecking old post, but the same unhelpful error comes up even in Server 2016.

Luckily, for me the cause was mismatched certificates between IIS and RRAS.

The fix was to use the same certificate for the default IIS site as I was using in RRAS.

  • How do you see the RRAS certificate?
    – NickG
    Feb 14, 2020 at 13:49
  • I noticed something similar. I could Remote Desktop into the machine, but a certificate trust warning was shown. I added that certificate into my PCs Trusted Root CAs, but when I went to the server's IIS HTTPS site, it showed a certificate with a different expiration date. In RRAS, I opened the server's properties and checked/enabled 'SSL Certificate Binding: Use HTTP. Then I was able to start RRAS. Feb 28, 2021 at 0:40

RRAS on Server 2019 and 7024 or 20269/20153 events from RemoteAccess, after 4405 event from NPS

I changed the LogFile path in NPS -> Accounting. Afterwards RRAS started.

  • Just want to add that this solution fixed the issue for me. I simply had to change the log file from daily to monthly and it worked for me. I guess by changing this setting must have reset something. Here's a screenshot in case it might help others: 1drv.ms/u/s!AkqySLt4R-Jdk-V5a8-84l9iYBHYkQ?e=HtrDSX
    – user35072
    Oct 4, 2019 at 9:17

The solution in my case was quite simple:

  • Deactivate Routing and Remote Access server
  • Reactivate and configure Routing and Remote Access server. Fortunately, we do not have a complicated configuration...

Not the answer you're looking for? Browse other questions tagged or ask your own question.