CONTEXT_E_NOCONTEXT 0X8004E004: MTS Object Context Missing

You're running an old VB6 or classic ASP application on Windows Server 2012 or 2016. The app calls a COM+ component that uses GetObjectContext() to grab the MTS transaction context. Instead of working, you see this error in the event log or a popup: CONTEXT_E_NOCONTEXT (0X8004E004) - There is no Microsoft Transaction Server (MTS) object context.

This is a classic "I'm running outside a transaction" problem. It hits most often when you've migrated the app from Windows 2000 or XP to a newer server, or when you're testing a component directly with a test harness instead of through the COM+ application.

Why This Happens

The COM+ runtime gives each component an IObjectContext pointer when the component runs inside a transaction. If your code calls GetObjectContext() but there's no active transaction context, you get this error. The component thinks it's participating in a transaction, but nobody started the party.

Common triggers:

• Running the component as a standalone EXE or from a test script outside the COM+ application.
• The COM+ application isn't configured to use transactions (it's set to "Disabled" instead of "Required" or "Supported").
• The client calling the component doesn't start a transaction (like an ASP page missing @TRANSACTION = Required).
• After a server migration, the COM+ application's identity or security settings broke the context chain.

Fix It: Step by Step

I've fixed this exact error dozens of times. Here's the sequence that works:

1. Check the COM+ application configuration — Open Component Services (dcomcnfg.exe), expand Component Services > Computers > My Computer > COM+ Applications. Find your application, right-click it, select Properties. Go to the Activation tab. Make sure it's set to Server application (not Library application). Library apps can't have their own transaction context.
2. Set transaction support correctly — In the same Properties window, go to the Components folder, find your component, right-click and choose Properties. On the Transactions tab, set it to Required if the component must always run in a transaction, or Supported if it can run either way. If you set it to Not Supported, that component won't get a context — but it also won't throw this error. You want Required here for most cases.
3. Verify the client starts a transaction — If your client is classic ASP, the page must have <%@ TRANSACTION=Required %> at the very top, before any HTML or other directives. Without that, the page doesn't create a transaction context for the COM+ component. On an ASP.NET page, you need <%@ Page Transaction="Required" %> or specify the transaction attribute in the Web.config.
4. Test the component properly — Don't test by running the DLL directly with a test script. That bypasses the COM+ runtime entirely. Use the Component Services console to create a test client, or call the component from a web page that's configured for transactions. If you must debug locally, create a simple ASP page with the transaction directive and call your component from there.
5. Check the component's identity — Back in the COM+ application Properties, go to the Identity tab. The account running the component must have permissions to the transaction coordinator. If you're using Network Service or a custom account, make sure it's part of the Distributed COM Users group and has access to the COM+ System Application.
6. Reregister the component — From an elevated command prompt, run regsvr32 yourcomponent.dll to ensure the COM+ registration is clean. Then remove and re-add the component to the COM+ application: right-click the Components folder, choose New > Component, select Import component(s) that are already registered, and pick your DLL.
7. Reboot the COM+ application — In Component Services, right-click your application and choose Shut down. Then right-click again and choose Start. This forces the runtime to reload the context manager.

Still Broken? Check This

If the error persists after all that, you're likely dealing with a deeper issue. Here's what to check next:

• 64-bit vs 32-bit mismatch — Your VB6 components are 32-bit. If you installed them in a 64-bit COM+ application, they won't load the MTS context correctly. Create a separate 32-bit COM+ application (Component Services defaults to 64-bit on 64-bit Windows). In the application's Advanced tab, check Enable 32-bit application on 64-bit computers. Or use the 32-bit version of Component Services from %systemroot%\SysWOW64\comexp.msc.
• Missing MSDTC (Distributed Transaction Coordinator) — Open Services.msc, find the Distributed Transaction Coordinator service. Make sure it's running and set to Automatic. If it's stopped, start it and restart your COM+ application.
• Corrupt component registration — Sometimes a DLL gets unregistered or registered into the wrong location. Unregister it with regsvr32 /u yourcomponent.dll, then re-register it from the correct folder. Then remove and re-add the component in Component Services.
• Legacy MTS dependencies — On Windows Server 2012 and above, Microsoft removed the old MTS runtime. Your component might rely on an older MTS library that's no longer present. Check if the component uses mtxex.dll or references the MTSAdmin type library. If it does, you'll need to update the component to use the newer COM+ interfaces, or run the app on a legacy version of Windows like 2008 R2.

The real fix is almost always the transaction support setting or the client-side directive. I've seen this error turn up after a simple Windows update reset the COM+ application's configuration. Double-check those settings first — they'll save you hours of head-scratching.