NS_I_CUB_RUNNING 0X400D0052 – Content Server Won't Start? Here's the Fix

What This Error Actually Means

You're getting 0X400D0052 with the message Content Server %1 (%2) is running. That's Documentum's way of saying the server process has already claimed the repository. You can't start a second instance, and in most cases you don't need to. But sometimes the server is not actually running — the system just thinks it is. That's the real problem.

This shows up when you run dcm start or try to boot the Content Server after a crash, a reboot, or a failed shutdown. The server either didn't release its lock or a background process is still hanging around. We'll sort this out step by step, starting with the quickest check.

Fix 1: Check If the Server Is Actually Running (30 seconds)

Before you do anything drastic, confirm whether the server is alive. On Linux, run:

ps -ef | grep dm_server

On Windows, open Task Manager and look for dm_server.exe or java.exe with Documentum paths.

If you see a process listed, the server might genuinely be running — maybe you started it earlier and forgot. In that case, you don't need this article. Just use the repository as normal. But if you see no process and still get the error, move to Fix 2.

Fix 2: Restart the Documentum Service (5 minutes)

When the process is missing but the error persists, a stale lock file is the usual culprit. The lock file lives in the Content Server install directory, often under install or bin. The exact name varies, but look for something like dm_server.lck or repo_name.lck.

First, try a clean restart of the Documentum service. On Linux:

sudo systemctl restart dcm

If you're using the older init.d style, it's:

sudo /etc/init.d/dcm restart

On Windows, open Services, find the Documentum service (usually named Documentum Content Server or similar), right-click and select Restart.

After the service restarts, wait about 30 seconds, then try to start the repository again:

dcm start repo_name

If you still see 0X400D0052, you have a stuck lock. Move to Fix 3.

Fix 3: Remove Stale Lock Files and Kill Zombie Processes (15+ minutes)

This is the heavy-duty fix. It's safe if you've confirmed the server isn't running, but double-check before you delete anything. A wrong deletion can corrupt the repository. I've seen it happen.

Step 3.1: Identify the Stale Lock File

Navigate to the Content Server installation directory. Common locations are:

• /opt/documentum/dba (Linux)
• C:\Documentum\dba (Windows)

Look for files with a .lock or .lck extension. If you see a file named after your repository, like repo_name.lck, that's the one.

Step 3.2: Kill Any Remaining Processes

Sometimes the process isn't showing in a normal ps because it's defunct. Use:

ps -ef | grep dm_server | grep -v grep

If you see a process with a Z in the status column, it's a zombie. You can't kill it directly, but you can bounce the system or wait for the parent process to clean it up. If there's a normal process, kill it:

kill -9 <PID>

On Windows, use taskkill /F /IM dm_server.exe.

Step 3.3: Safely Remove the Lock File

Now remove the lock file. Back it up first, just in case:

mv repo_name.lck repo_name.lck.bak

On Windows, rename it in Explorer.

Step 3.4: Start the Server Again

Now try starting the repository:

dcm start repo_name

If it starts cleanly, you're done. If it still throws 0X400D0052, there's likely a deeper issue with the repository configuration or the Content Server's internal registry. That's when you need to check the server log files.

When to Call in a Specialist

If you've done Fix 3 and the error persists, check the Content Server log at <install_dir>/logs for clues. Common causes include a corrupted repository cache or a failed upgrade that left the server in a half-started state.

Honestly, if you've gotten this far and haven't fixed it, you're dealing with something beyond a simple lock. At that point, consider contacting Documentum support or your admin team. I've seen this error turn into a full repository recovery, and that's not a 15-minute job.

One last thing: don't ignore this error if you see it during normal operations. If your server is running fine but the error appears in the logs, it might just be a harmless duplicate start attempt. But if it's blocking you from starting, the steps above will get you back online.