CO_E_NOTINITIALIZED (0X800401F0) – CoInitialize Not Called Fix

Quick Answer

Call CoInitializeEx(NULL, COINIT_APARTMENTTHREADED) at the start of each thread that uses COM, and CoUninitialize() before the thread exits. That's it.

Why This Happens

Every time you see error 0x800401F0 (CO_E_NOTINITIALIZED), it means a thread tried to use a COM object without initializing the COM library first. COM isn't automatic—you have to tell Windows, 'Hey, I'm going to use COM on this thread.' If you don't, any CoCreateInstance, CreateObject, or New on a COM class will blow up with this error.

I've seen this most often in old VB6 apps, PowerShell scripts, and custom .NET code that spawns worker threads. Had a client last month whose entire print queue management app crashed every time they kicked off a background job. Turned out the developer forgot to call CoInitialize on the worker thread. One line of code fixed it.

Step-by-Step Fix

1. Identify the thread causing the error. Look at your stack trace—it'll show exactly where the COM call failed. If you're in a multi-threaded app, the offending thread is usually a background worker or a timer callback.
2. Add CoInitializeEx at the start of that thread's function. Use this exact call before any COM work:
   

   CoInitializeEx(NULL, COINIT_APARTMENTTHREADED);

   For most single-threaded apps, COINIT_APARTMENTTHREADED is the safe choice. If you're building a multi-threaded server that creates COM objects from many threads, use COINIT_MULTITHREADED—but that's rare and requires careful handling.
3. Pair it with CoUninitialize. When the thread is done with COM (typically at the end of the function), call:
   

   CoUninitialize();

   Skipping this can leak resources and cause weird crashes later. I've debugged apps that ran fine for hours then randomly died because of missing CoUninitialize calls.
4. Test the fix. Run the app and reproduce the scenario that triggered the error. If it still fails, double-check that you're calling CoInitializeEx on the same thread that makes the COM call. COM initialization is per-thread—not per-process.

Alternative Fixes

If the main fix doesn't work or you can't modify the code, try these:

• For PowerShell scripts: The New-Object cmdlet automatically initializes COM on the main thread. But if you're using [activator]::CreateInstance or calling COM from a runspace, you need explicit initialization. Wrap the COM code in a script block and use Start-ThreadJob with the -InitializationScript parameter that calls [System.Threading.Thread]::BeginThreadAffinity() and [System.Windows.Forms.Application]::OleRequired().
• For .NET apps: If you're using BackgroundWorker or Task.Run, call CoInitialize inside the delegate. An easier path: use STAThread attribute on the main thread and ensure all background work runs on an STA thread. Set Thread.CurrentThread.SetApartmentState(ApartmentState.STA) before starting the thread.
• For VB6 or legacy COM clients: Wrap the COM object creation in a On Error Goto block, call OleInitialize from ole32.dll as a fallback. But really, the proper fix is to call CoInitialize at your app's startup or in each thread's entry point.

Prevention Tip

The easiest way to avoid this error: make it a habit to call CoInitializeEx at the entry point of every thread that might touch COM—even if you think it doesn't need COM. I do this in every new project's thread pool init code. Also, wrap your COM calls in a try/finally block that ensures CoUninitialize runs. A simple RAII wrapper in C++ or a using block in C# can save you hours of debugging later.

One more thing: if you're using .NET, the CLR calls CoInitialize automatically for your main thread if it's STA. But worker threads are MTA by default, so you still need to initialize COM manually. Don't assume the framework handles it.