Fix ERROR_CLASS_ALREADY_EXISTS (0x582) in Windows

Cause 1: Your app is registering the same class name twice

This is the one I see most often. Somewhere in your code you're calling RegisterClassEx or RegisterClass with the same lpszClassName value more than once. The second call fails with ERROR_CLASS_ALREADY_EXISTS (0x582). It happens a lot in apps that initialize their window class in multiple places—like on startup and then again when a new window is created.

The fix is simple: check if the class is already registered before registering it again. Use GetClassInfo to see if it exists:

WNDCLASS wc = {0};
if (GetClassInfo(hInstance, _T("MyWindowClass"), &wc)) {
    // Already registered, skip
} else {
    RegisterClassEx(&wx);
}

Or better: move your class registration to a single function that's called exactly once, usually in WinMain before creating any windows. That way you don't have to rely on checks.

If you're using a third-party UI library (like MFC or Qt), it might be registering classes internally. In that case, you're probably not calling it twice—the library is. In MFC, each CWnd derived class has a static CRuntimeClass that registers a window class. If you create multiple instances with the same name, you might hit this. The trick is to make sure each class has a unique name, often by using the AFX_MSGMAP_ENTRY or overriding PreCreateWindow to change the class name.

This also happens in games that use SDL or SFML if you accidentally initialize the video subsystem twice—don't do that. Initialize once at startup, check the return value, and move on.

Cause 2: A previous instance of your app didn't clean up

If your app crashed or was killed without unregistering its window classes, the class name stays in the system's internal table. Windows doesn't automatically clean these up on process termination for some legacy applications—especially if the process was terminated forcefully via Task Manager or an unhandled exception.

The system actually removes window classes when the process that registered them exits. But here's the catch: if you have a zombie process still running in the background, it will keep the class registered. That's why you see this error when you try to start a second instance of your app while the first is still alive (but maybe not visible—check Task Manager).

Fix: open Task Manager, sort by name, and kill any leftover processes of your app. If it's a service or a background process, use tasklist | findstr yourApp.exe to find it, then taskkill /F /IM yourApp.exe.

In your code, make sure you're calling UnregisterClass when you clean up. It's not strictly necessary because Windows cleans up on exit, but it's good practice—especially if your app creates temporary windows dynamically.

Also: check if you're using a DLL that registers a class and then gets unloaded but the class isn't unregistered. That's a classic source of this error. The DLL might be reloaded in a new process, and the class name persists from the old one. To avoid this, give your class a globally unique name that includes a GUID or version number.

Cause 3: Name collision with another application or system class

Less common, but it happens. Your app is using a generic class name like "Static" or "Button"—those are system classes, and you can't register them. But more subtle: two different third-party DLLs in the same process might both register a class with the same generic name like "MyCustomWindow". The second one gets 0x582.

This is a classic problem with plugins. You load a plugin, it registers a class, you unload the plugin but forget to unregister, then load another plugin that uses the same class name—boom.

Fix: make your class names unique. Prefix them with your company or app name, or better, use a GUID:

TCHAR className[128];
StringCchPrintf(className, 128, _T("MyApp_%s"), _T("3F2A9B7C-1D4E-4F6A-8B3C-9D5E7F1A2B3C"));

If you're dealing with a third-party library that hardcodes its class name, you can't change it—you'll need to ensure only one instance of that library is loaded per process. Check for duplicate DLL loads with LoadLibrary and use a reference counter.

Another workaround: use RegisterClassEx and if it fails with ERROR_CLASS_ALREADY_EXISTS, just use GetClassInfoEx to get the existing class and proceed. This works if the existing class is compatible with what you need. But don't do that unless you're sure—you might end up using a class with different window proc and breaking things.