CODEWITHSUNDEEP
powershelldcom
Padre Pedro
Padre Pedro

Reputation: 24

CoCreateInstanceEx with CLSCTX_REMOTE_SERVER gives access denied from an elevated PowerShell

I have a few .NET tools made in C# using the same DLL. That DLL uses a C++/CLI DLL. There (D)COM is used. When CoCreateInstanceEx is called with CLSCTX_INPROC_SERVER, everything works fine. When it's used with CLSCTX_REMOTE_SERVER, everything is fine as well, except for one of the aforementioned tools, i.e. a set of PowerShell cmdlets.

More precisely, I get an access denied (0x80070005). This happens while using different parts of the tool, where different CLSIDs are used with CoCreateInstanceEx. I do run the PS cmdlets in an elevated way and am testing towards my local machine (but the remote way, so I do use my machine name as the target and this with CLSCTX_REMOTE_SERVER). It does work with other tools (GUI, classic cmd line tool,...). They all use the same underlying DLL in the same way.

I guess there must be something special when using DCOM from PowerShell, no? On the other hand Get-WmiObject, which uses DCOM, works fine with -ComputerName.

Anyone having an idea?

Thanks!

I haven't tried anything special TBH...

Upvotes: -1

Views: 135

Answers (1)

Padre Pedro
Padre Pedro

Reputation: 24

Problem solved! It does work, even remotely from my PowerShell cmdlet (developed with C# and underlying using C++/CLI). I've tried to do DCOM locally and remotely from C# itself and I got the exact same results. However, the problem only arises when the remote system is "localhost" or the explicit name of the local machine. It works great when the system is REALLY a remote system.

There must be something under the PS umbrella that deals with "localhost" or the explicit name of the local machine in a special way, making the whole thing fail. "Special", also because the exact same code works like charm when the application is not a PS cmdlet, but a GUI (WinForms) or console application (Command Prompt).

Luckily, it's not that hard to tweak my PS cmdlet code in such a way the cmdlet can also deal with "localhost" or the explicit name of the local machine (i.e. by making my DCOM call locally in that case).

Just wanted to share this special one with you :-)

Ciao, Pedro

Upvotes: 0

Related Questions