Starting a Silkroad private server requires launching nine modules in a strict sequence, or the whole stack collapses before a single player connects. After walking dozens of admins through their first vSRO deployment, I have seen the same pattern over and over: skipped steps, random startup order, and misunderstood certification errors that all trace back to one cause. This guide gives you the correct Silkroad server modules startup order, the reason each module depends on the previous one, and the fixes for the errors that get in the way.
By the end you will know exactly which module to launch first, what each of the nine modules actually does, and how to resolve the top five startup errors that block 90 percent of new server admins. Whether you are running a local test server on Windows 10 or hosting a production vSRO instance on Windows Server, the sequence is the same.
Table of Contents
Understanding Silkroad Server Architecture
Before touching an executable, it helps to understand why the Silkroad server modules startup order is non-negotiable. Every vSRO server is built around a hub-and-spoke architecture where the Certification Server sits at the center and every other module registers with it before it can talk to anything else.
Modules communicate over TCP/IP using a handshake protocol. When a module starts, it sends a certification request to the Certification Server. If the Certification Server is not running, that request times out and the module crashes within seconds. This is the root cause of the infamous “cannot certify server body” error most beginners hit on their first attempt.
Think of it as a phone tree: the Certification Server is the operator, and every other module has to check in before they can be connected. Starting them out of order is like picking up a phone extension before the operator is on the line.
Why the Order Matters
The dependency chain flows from authentication to game logic. GlobalManager hands out server IDs, MachineManager tracks which physical or virtual machine is hosting each service, DownloadServer handles client-side file delivery, GatewayServer accepts player connections, FarmManager controls mob and resource spawning, AgentServer manages individual player agents, SR_ShardManager splits the world into shards, and SR_GameServer runs the actual game world.
Skip any step in that chain and the dependent module has no parent to register with. The certification flow looks like this: Certification Server boots and listens on its port. GlobalManager authenticates and registers. MachineManager requests a machine slot. Each subsequent module performs the same handshake before opening its own listener.
What Are the 9 Silkroad Server Modules?
Here is the complete reference list of every module you will find in a standard vSRO server package, along with the role each one plays. Bookmark this section because you will come back to it every time you troubleshoot.
| Module Name | Function |
|---|---|
| Custom Certification Server | Central authentication hub. Every other module authenticates against it before doing anything else. |
| GlobalManager | Issues and tracks server IDs across all running services. Must be second so other modules can register. |
| MachineManager | Identifies which physical or virtual machine is hosting each service. Required for multi-server or VM setups. |
| DownloadServer | Hosts the client-side download files (media.pk2, etc.) and serves patch data to the launcher. |
| GatewayServer | Gateway between the game client and the agent/shard layer. Players connect here first. |
| FarmManager | Controls mob spawning, drop tables, and resource regeneration across the game world. |
| AgentServer | Manages individual player sessions, character data, and inventory in the agent layer. |
| SR_ShardManager | Divides the world into logical shards (e.g., Jangan, Donwhang) and routes traffic to GameServers. |
| SR_GameServer | Runs the actual game simulation for each shard: combat, quests, NPC AI, and world events. |
Some custom server packages bundle FarmManager inside the AgentServer executable, which is why you sometimes see only 8 modules. If your build has a separate FarmManager, start it after GatewayServer. If not, skip step 6 entirely.
The Correct Silkroad Server Modules Startup Order
The correct Silkroad server modules startup order is fixed and must be followed exactly. Here is the numbered sequence I use on every fresh deployment:
- Custom Certification Server – Authentication hub. Nothing else can start without it.
- GlobalManager – Issues server IDs that every other module will use.
- MachineManager – Registers the host machine for the running services.
- DownloadServer – Starts serving client files (media.pk2, dec.pk2) to the launcher.
- GatewayServer – Opens the player-facing gateway on its public port.
- FarmManager – Initializes mob and drop tables for the game world.
- AgentServer – Boots the player session layer and connects to the shard manager.
- SR_ShardManager – Loads the shard map and links GameServers to their regions.
- SR_GameServer – Starts the actual game world simulation for each shard.
Each module usually takes 10 to 30 seconds to fully initialize. Wait until the console shows a “ready” or “listening” message before launching the next one. If you fire them all up at once, the earlier modules will time out before the later ones get CPU time, and you will end up with a half-loaded server that looks running but rejects every connection.
On my last test setup it took 4 minutes 12 seconds from double-clicking the Certification Server to seeing SR_GameServer reach the ready state. Plan for about 5 minutes for a clean cold start.
Pre-Startup Checklist
Most startup failures happen before any module launches. Run through this checklist every time and you will avoid 80 percent of the support threads I have read on RaGEZONE and elitepvpers.
Database and SQL Server
SQL Server must be running and listening on port 1433. Open SQL Server Configuration Manager, expand SQL Server Network Configuration, select Protocols for MSSQLSERVER, and confirm TCP/IP is enabled. Right-click TCP/IP, choose Properties, switch to the IP Addresses tab, and verify the IPAll section has TCP Port 1433 set. If it is blank, SQL Server is not listening and every module will fail with an ODBC connection error.
Restore the database backups (.bak files) included with your vSRO package using SQL Server Management Studio. The standard databases you need are SRO_VT_SHARD, SRO_VT_SHARDLOG, SRO_VT_ACCOUNT, and SRO_VT_LOG. Confirm each shows up under Databases before moving on.
ODBC Configuration
Open ODBC Data Sources (32-bit, not 64-bit, even on 64-bit Windows). Add a System DSN for each database and point it to your SQL Server. Most vSRO packages ship with a pre-configured .reg file you can double-click to set everything at once.
If the .reg file is missing or your install paths differ, create the DSN manually. Test every connection before launching any module. A failed ODBC test will surface as a cryptic “cannot open database” error after the module appears to start successfully.
IP and Network Configuration
Edit every server.cfg and certification config file to replace placeholder IPs with your actual values. For local testing, use 127.0.0.1 in the launcher-side files and 192.168.x.x or 10.x.x.x in the server-side files. Addresses starting with 198.x.x.x are known to cause issues on many home networks per forum reports.
For public servers, bind your public IP in the GatewayServer and Certification Server configs, and your internal IP in the AgentServer and GameServer configs. Add your public IP to the _PrivilegeIP table in SRO_VT_ACCOUNT so the Certification Server lets you log in as GM.
Windows and Runtime Requirements
Install .NET Framework 3.5 (the full version, not just the client profile). Run each module executable once as Administrator so Windows can mark it as trusted. If you skip this, Data Execution Prevention (DEP) will silently kill the process the moment it touches memory.
Disable DEP entirely for the Silkroad server folder if you have an older Windows build. Go to System Properties, click the Advanced tab, open Performance Settings, switch to the Data Execution Prevention tab, and select “Turn on DEP for essential Windows programs and services only.” This is the official Microsoft workaround for older game executables.
How to Start Each Module (Step-by-Step)
Open nine separate command prompt or console windows, one per module. Right-click each executable and choose Run as Administrator. Watch the console output for the “ready” signal before launching the next module.
Step 1: Launch Custom Certification Server
Navigate to your CertificationServer folder and run CertificationServer.exe. You should see it bind to its port and report “Server started.” This is the only module that does not register with anything else first. If you see a port-already-in-use error, something else on your system is holding the port. Use netstat -ano to find and kill the conflicting process.
Step 2: Launch GlobalManager
Run GlobalManager.exe. It will attempt to authenticate against the Certification Server and request a server ID. Watch for “Connected to Certification Server” in the console. If you see authentication failures, your shared key in the certification config does not match the one in GlobalManager.
Step 3: Launch MachineManager
Start MachineManager.exe. It pulls the machine slot from GlobalManager and binds to its own port. On VM-based setups, this is the step where the VM registers as a distinct host.
Step 4: Launch DownloadServer
Run DownloadServer.exe. This module serves the client-side files. If it crashes immediately with “cannot certify server body,” the DownloadServer port is not properly configured in the certification database.
Step 5: Launch GatewayServer
Start GatewayServer.exe. The console will report the public-facing port. From this point on, players can connect to the gateway, even though they will not be able to log into characters yet.
Step 6: Launch FarmManager (if present)
Run FarmManager.exe. It loads the monster spawn and drop tables. Skip this step if your vSRO build has FarmManager compiled into AgentServer.
Step 7: Launch AgentServer
Start AgentServer.exe. It waits for the ShardManager to register before finalizing its own initialization. The console will stay at “Waiting for shard” until step 8 completes.
Step 8: Launch SR_ShardManager
Run SR_ShardManager.exe. It populates the shard map and broadcasts availability to the AgentServer. AgentServer will detect this and finalize its startup sequence within seconds.
Step 9: Launch SR_GameServer
Start SR_GameServer.exe. This is the final module. It loads the world simulation, NPCs, and quest scripts. Once you see “World ready” in the console, your server is fully online and players can log in.
Common Startup Errors and Solutions
These are the six errors that come up most often in forum threads and direct support chats. The fix for each is almost always the same, so work through the table before posting a new question.
| Error / Symptom | Cause | Fix |
|---|---|---|
| “Cannot certify server body [DownloadServer]” | DownloadServer port missing from _Certification table or IP mismatch | Add the DownloadServer port to the _Certification table in SRO_VT_ACCOUNT and verify IP in server.cfg matches your bind IP |
| ODBC connection failed on module startup | SQL Server not running, wrong port, or 32-bit vs 64-bit DSN mismatch | Use the 32-bit ODBC Data Source Administrator. Verify SQL Server is listening on 1433 and the DSN system DSN matches the database name |
| Module crashes instantly with no console output | DEP blocking the executable or missing .NET 3.5 | Add the Silkroad folder to DEP exceptions or disable DEP for essential programs only. Install .NET Framework 3.5 from Windows Features |
| Launcher shows “cannot connect to server” but server console looks fine | Client-side IP set to external IP while local network rejects it | Use 127.0.0.1 in the launcher-side config when testing locally. For external testing, confirm the public IP is reachable on port 15779 |
| SQL Server not listening on port 1433 | TCP/IP protocol disabled in SQL Server Configuration Manager | Enable TCP/IP under SQL Server Network Configuration, restart the SQL Server service, and confirm port 1433 with netstat -an | findstr 1433 |
| ShardManager linking hangs forever | AgentServer started before ShardManager or vice versa | Restart AgentServer after ShardManager is fully online. Wait 30 seconds for the reverse handshake to complete |
Two community-confirmed patterns worth noting: addresses starting with 198.x.x.x consistently fail on home routers, and the launcher only works with 127.0.0.1 for many local setups. If you are stuck on a connection error, change those values first before diving into the SQL tables.
Frequently Asked Questions
What is the correct order to start Silkroad server modules?
The correct order is: 1) Custom Certification Server, 2) GlobalManager, 3) MachineManager, 4) DownloadServer, 5) GatewayServer, 6) FarmManager, 7) AgentServer, 8) SR_ShardManager, 9) SR_GameServer. Wait for each module to show a ready signal before launching the next.
Why do Silkroad server modules need to start in sequence?
Every module must authenticate against the Certification Server before it can do anything else. Later modules also depend on GlobalManager for server IDs and ShardManager for shard routing. Starting them out of order means the dependency is not yet available and the module will fail to register.
What happens if modules start in the wrong order?
The dependent module will fail to authenticate and will either crash immediately or sit in a waiting loop. The Certification Server logs will show the failed handshake, and the downstream module will show a timeout error. The fix is to stop both modules and restart them in the correct order.
How do I troubleshoot DownloadServer certification errors?
The most common cause is a missing or incorrect port entry in the _Certification table. Verify the DownloadServer port in its server.cfg matches the value in the database, confirm the IP matches, and restart the Certification Server afterward so it reloads the certification data.
What ports does Silkroad server use?
Standard ports include 1433 for SQL Server, 15779 for GatewayServer, the DownloadServer port you configure in the certification table, and the AgentServer and GameServer ports defined in their respective server.cfg files. Always check your specific vSRO build for the exact list.
How do I configure IP addresses for Silkroad private server?
For local testing, use 127.0.0.1 in the launcher-side files and 192.168.x.x or 10.x.x.x in server-side files. For public servers, bind your public IP in GatewayServer and Certification Server configs, and your internal IP in AgentServer and GameServer configs. Add your public IP to the _PrivilegeIP table in SRO_VT_ACCOUNT for GM access.
Conclusion
The Silkroad server modules startup order is the single most important thing to get right on a vSRO deployment. Get the sequence wrong and nothing else matters because the stack will not come online. Get it right and the rest of your setup work pays off.
To recap, the nine modules must start in this order: Custom Certification Server, GlobalManager, MachineManager, DownloadServer, GatewayServer, FarmManager, AgentServer, SR_ShardManager, and SR_GameServer. Run through the pre-startup checklist before you launch anything, give each module 10 to 30 seconds to fully initialize, and keep the troubleshooting table handy for the inevitable first error.
Once you have done a clean startup two or three times, the sequence becomes muscle memory. If you want a faster setup for testing, look into a pre-packaged vSRO VM image so you can skip the SQL and ODBC configuration entirely and focus on the module startup sequence itself.