Error -17501 - Could not connect to TSAutoMgr.exe

[bienieck]

Hello,

I'm having the following error message when starting TS2019 from OI (only first time). Does anyone knows what can be the problem? This started after customer IT installed some "security stuff". I would like to ask for a support explaining how to fix it and also explaining what happened 🙂 (I would like to avoid random clicking). I don't have permanent access to the PC 😕

Unable to load test environment adapter 'flxCVIadp.dll'.

Run setup to re-install or remove this adapter.

Could not connect to TSAutoMgr.exe server. DCOM permissions might be incorrect because of configuration changes for remote execution. To fix this issue, ensure that the current user is in the default DCOM access permissions or that no users are in the access permissions section of the dcomcnfg.exe dialog box. You can use the dcomcnfg.exe program, located in Windows System directory, to change DCOM access permissions.

Error Code: -17501, Unexpected Operating System Error.

---

[J.Willems]

I found this as another reply.

Maybe this can be the solution.

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA03q000001Djl8CAC&l=nl-BE

[Mr._Jim]

@bienieck / Michał,

I know it's been a few years, but do you remember what the solution to this was?

I've tried the KB suggestion of configuring the DCOM Identity for TSAutoMgr.exe, but I'm not having any luck.

I'm even running Process Monitor to figure out where it might be choking, but I can't find anything.

Thanks,

Jim

[Mr._Jim]

I tried NI's KB that was linked to.

I also reinstalled TestStand. It didn't help. This is on Windows 11 x64, and when switching to TestStand 2021. (We're migrating to 26)

I have a solution, or at least part of one.

Please note that I am not responsible for anything you try here. This is just information and attempting any of this is at your own risk.

Right before I arrived at this solution, I had the following symptoms:

• If I ran the TestStand Version Selector (TSVerSelect.exe) as my ordinary non-admin user, then pressed the "Launch 64-bit" button, I would immediately get the error dialog.ErrorDialog.png

The sequence editor would open. Then, once I closed TestStand, I'd get a warning about 3 leaked ActiveX references.

• If I ran the Version Selector as an admin user, everything went great with no error.
• If I ran TestStand (seqedit.exe) directly as a non-admin user without using the version selector, the sequence editor opened without any error dialog.

The (Partial?) Solution

In my case, I did the opposite of what the KB article suggests. Here are my steps with screenshots that are newer than those from 2006:

Open Component Services as in the article, or launch dcomcnfg.exe as an admin / elevated user.

In the left-hand pane, open the tree and select DCOM Config.

Optional, but highly recommended: Switch the view to a list using the appropriate button in the upper toolbar (see illustration below)

00.png

 

In the right-hand pane, scroll down until you find "NI TestStand AutoMgr".

Right-click, and select Properties in the context menu.

01.png

 

In my case, selecting "The Interactive User" solved the problem.

02.png

 

It might be more complicated.

I went around and around with a company internal instance of Gemini, and while I took a lot of notes and there's a chat log, it's not 100% clear to me the exact steps I took that worked.

It was a long and painful process. Here are some of the general steps I took, in varying order. I can't say for certain which helped, unfortunately.

In the Windows Event Viewer, I looked under "Windows Logs"->"System" for DistributedCOM Warning events. The general wording will look like 

The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID

{9EA82395-E31B-41CA-8DF7-EC1CEE7194DF}

and APPID

{2ED83BAA-B2FD-43B1-99BF-E6149C622692}

to the user NT AUTHORITY\NETWORK SERVICE SID (S-1-5-20) from address LocalHost (Using LRPC) running in the application container Unavailable SID (Unavailable). This security permission can be modified using the Component Services administrative tool.

You can then search for the GUIDs in the registry to identify which applications they go to.

I did this for a lot of entries, but honestly, I suspect it just had me going off course.

Next, per Gemini, I started fussing around with permissions that enabled me to change DCOM permissions.

Here is the exact wording Gemini gave me: (Yeah, sorry, this is long)

---

Step 1: Take Ownership of the Registry Keys

You need to grant yourself permission to modify the DCOM settings for this specific AppID.

1. Press Win + R, type regedit, and run as Administrator.
2. Navigate to: HKEY_CLASSES_ROOT\AppID\{2ED83BAA-B2FD-43B1-99BF-E6149C622692}
3. Right-click the folder {2ED83BAA-B2FD-43B1-99BF-E6149C622692} and select Permissions.
4. Click Advanced.
5. At the top, change the Owner from TrustedInstaller to the local Administrators group.
6. Check the box "Replace owner on subcontainers and objects" and click OK.
7. Back in the Permissions window, select the Administrators group and check Full Control. Click OK.

Step 2: Grant Permissions in Component Services

Now that you have registry authority, you can modify the DCOM activation settings.

1. Press Win + R, type dcomcnfg, and press Enter.
2. Navigate to: Component Services > Computers > My Computer > DCOM Config.
3. Locate WaaSProtectedSettingsProvider. (Note: If you can't find it by name, look for the AppID {2ED83BAA-B2FD-43B1-99BF-E6149C622692}).
4. Right-click it and select Properties.
5. Go to the Security tab.
6. Under Launch and Activation Permissions, select Customize and click Edit. (If "Edit" is still greyed out, ensure you performed Step 1 correctly and restarted dcomcnfg).
7. Click Add, type NETWORK SERVICE, and click OK.
8. With NETWORK SERVICE selected, check the box for Local Activation.
9. Click OK on all windows and restart the machine (or the specific service, though a reboot is cleaner for DCOM).

---

I went back and forth with Gemini and tried this in several different locations and with permissions for my own user and couple of system user like "NETWORK SERVICE".

If you try this, proceed with caution. I honestly don't know if it helped.

I pored over SysInternals Process Explorer logs. It's a fantastic tool and has helped me solve complex problems in the past, but in this case, nothing was really jumping out at me. (yet)

I tried a custom debug log via logman.exe and that turned up with nothing.

That's when I gave up for the night.

When I resumed this morning, I gave Claude Opus 4.8 a turn. (I am blessed with a fantastic internal LLM portal with several models to choose from)

I gave Claude a specifically worded prompt and attached the chat log from Gemini.

Claude gave me much more concise information and informed me that I was on the wrong track yesterday.

After it gave me a highly technical diagnosis which is too long to paste here, it recommended the following:

---

What to actually try, in order

1. Confirm the real HRESULT first. Instead of the DCOM ETW provider (which was silent because there's no access denial to log), watch the process:

• Run Process Monitor as your domain user, filter Process Name is TSAutoMgr.exe.
• Trigger the Launch. You should see TSAutoMgr.exe start and then exit. Look at the operations just before it exits — you're hunting for ACCESS DENIED or NAME NOT FOUND on a registry key or file path. That single line is your true root cause.

2. Check the AppID Identity for TSAutoMgr.

• In dcomcnfg → DCOM Config → find the TSAutoMgr / TestStand Automation Engine entry → Identity tab.
• Note what it's set to. If it's "The launching user," try temporarily setting it to "The interactive user" and re-test as the domain user. If that changes behavior, you've confirmed a context problem.
• (TestStand-specific note: NI's automation server is typically registered to run as the launching user so it inherits the caller's session and licensing context. Forcing a fixed identity can break licensing/session handoff, so treat "The interactive user" as a diagnostic, not necessarily the final fix.)

---

There were more steps beyond step 2, but step 2 worked.

This is ridiculously long, and aside from the solution I posted at the start, there may or may not be some useful bits in the verbose explanation above.

In any case, this took me many hours to troubleshoot, and if you appreciate this post, please give me a kudos. Thanks in advance.

Jim

[Mr._Jim]

Edit: I meant to say "Process Monitor," not "Process Explorer."

I also don't know why my dialog screenshot ran away, but I can't edit the last post.