Hi Romulus,

we get the same error in one of the client environments (System.Runtime.SEHException (0x80004005)) with the same test code. We tried with MT Desktop 2015 (latest), MT Desktop 2017, with different users having access to different sets of termbases (one of the users has access to no termbases at all). We used the system administrator user for trying this. => same result.

We met this error in the past here and there, but then it was usually solved with an MT upgrade or a system restart. But this time we cannot solve it.

Do you have an idea what to check? Is this some COM permission problem? Should we try to upgrade anything else?

This is the complete test code I used:

var app = new Application();
app.ServerRepository.Location = "http://....";
app.ServerRepository.Connect(user, pass);
foreach (ITermbase tb in app.ServerRepository.Termbases)
    Console.WriteLine(tb.Name);
app.ServerRepository.Disconnect();

Thanks,
Tamas

Hi,

now, we experience this also in one of our systems, right when calling

var app = new Application();

(MT Desktop version 14.2.7.43908)

in another system with 14.0.2094.0 this works still.
Right after upgrading it to the latest 14.2.7.43908 the same error in this system too.
I restarted the system, started this app as administrator, same result. 

Error log is:

Faulting module name: KERNELBASE.dll, version: 6.1.7601.23796, time stamp: 0x59028e59
Exception code: 0xe06d7363
Fault offset: 0x0000c54f
Faulting process id: 0x168c
Faulting application start time: 0x01d4c44b13793ae5
Faulting application path: C:\Users\XXXXXX\Desktop\TestMTApi.exe
Faulting module path: C:\Windows\syswow64\KERNELBASE.dll
Report Id: 53fe5e1e-303e-11e9-907c-005056bccf5e

We experience the same issue with MT 2019 (15.0.2.49020) in the customer's environment as well (new installation). The same version in our environment works fine.

Can you please help?

Hello  

The team took a look at this and concluded the following.

We tried to reproduce the bug, but couldn’t. We accessed a server repository successfully.

    However, in the example given in the SDK and in the code written by Tamás who reported this bug, we noticed that the location is specified after the Connect method is called, which connects the user to the last used repository, not the one that is specified in the .Location Property.

    In the test plugin, we’ve inverted these two and everything works as expected. But even with the strings placed wrong, there’s no error, it just connects to the last used repository.

    Here’s the link to the test plugin which accomplishes this: https://github.com/sdl/Sdl-Community/tree/master/Code%20samples/MultiTermTestPlugin