The problem
We have a native application, that integrates with Outlook through COM/interop.
Intermittently we experience different errors relating to COM, MAPI, Redemption and the Windows Registry. And this is only at a single client installation.
It works 95-99% of the time. This percentage is extrapolated from looking at our log files.
We have quite a few other client installations, that never get the errors with the same version (same code) of the native application. We only experience the errors at this one client installation.
That leads me to believe the problem is likely to stem from something different at the client installation and not the code. But this is of course only a hypothesis.
Errors
Error one
Exception from HRESULT: 0x8002801D (TYPE_E_LIBNOTREGISTERED)
When calling:
var outlookApp = (Application) Marshal.GetActiveObject("Outlook.Application");
var mapiObject = outlookApp.GetNamespace("MAPI").MAPIOBJECT; // <-- This line causes the error
at Microsoft.Office.Interop.Outlook.ApplicationClass.GetNamespace(String Type)
Error two
Interface not registered (Exception from HRESULT: 0x80040155)
When calling:
Microsoft.Office.Interop.Outlook._MailItem.get_Attachments()
Error three
Error in MAPILogonEx: MAPI_E_LOGON_FAILED
When calling:
Redemption.IRDOSession.Logon(Object ProfileName, Object Password, Object ShowDialog, Object NewSession, Object ParentWindowHandle, Object NoMail)
Tried so far
Reinstalling the entire machine from scratch
Reinstalling Office
Repairing Office
Checked the registry to see if multiple version of Office are present
There is only one version - "9.6" (Microsoft Office Standard 2019)
Run regsvr32 on the Redemption dll
Info:
Skype/Skype for business is not installed
Exchange Online is used, not om premise
Windows, Outlook and our native application are all x64
The strange thing is that is works most of the time. If it was a problem with the registration (registry), i would expect it to fail every time.
It looks like it might be a MAPI problem, but again it works most of the time.
I have been researching the problem for a few days now and haven't been able to find out why the problems are occurring intermittently. I have found a lot of information on the different errors, but they all seem to occur consistently; the errors occur every time the code is called in the error scenarios i have found.
Has anyone experienced anything similar or know why it might be happening?
Your machine is corrupted or any malware is presented. The problem is not related to the Redemption library because even the Outlook object model gives errors related to windows registry keys required for the COM interoperability.
TYPE_E_LIBNOTREGISTERED and REGDB_E_IIDNOTREG errors are a pretty strong indication that some COM registry keys are missing. Try to completely uninstall and then reinstall Outlook (not just Repair).
Related
I'm building a website in VS2015 (C# using Razor)
I see many posts where people say that they receive this error on their server, but not localhost - my issue is the opposite. I'm seeing this error in every *.ashx file preamble in this specific Website only while running Localhost on my development machine:
ASP.Net runtime error: Loading this assembly would produce a different grant set from other instances (Exception from: HRESULT 0x80131401)
This error prevents me from using Intellisense in the file - and I really need it for this next handler.
What I've Determined: - The issue is specific to this Website. I have other websites that do not produce this error, so there isn't a need to modify registry or change PC configurations.
What I've tried:
IISReset (Restart PC) [*before I realized problem was local]
Changing Registry by adding LoadingOptimizer DWORD [*before I realized problem was local]
Compared XML of a working Web.config file. (Other than assembly differences I played around with other differences and still nothing)
Any suggestions?
We are extensively using COM Interop with MSOffice applications, and one of them - MSProject 2013, is behaving very unstable and strange.
Sometimes it starts just fine, and works fine, but from time to time it is bugging us with following error:
Retrieving the COM class factory for component with CLSID
{36D27C48-A1E8-11D3-BA55-00C04F72F325} failed due to the following
error: 80080005 Server execution failed (Exception from HRESULT:
0x80080005 (CO_E_SERVER_EXEC_FAILURE)).
This can happen at any time, does not matter if windows was rebooted a few seconds ago, or uptime is several hours and MSProject was opened and closed several times.
What can we do to solve, or at least diagnose root cause of such a behavior?
this is a generic the best answer
Using DCOMCNFG.exe. Open it and go to: Component Services -> Computers -> My Computer -> DCOM Config -> Microsoft Excel Application.
Open the properties, select Identity tab and select the interactive user.
come from this link Server execution failed (Exception from HRESULT: 0x80080005 (CO_E_SERVER_EXEC_FAILURE))
but the actual error caused a memory issue which leaded to the exception from hresult 0x80080005 error.
check if maybe open file and didn't close it after reading msProject check the behavior of the code.
Also i recommend to change COM and read MsProject from XML to be faster and more clear than interop
Having trouble connecting from a C#/.NET program to a Development (non-live) iSeries
Getting the following failure when trying to open a new connection:-
"Exception of type 'System.ExecutionEngineException' was thrown."
HResult -2146233082
Managed Debugging Assistant 'FatalExecutionEngineError' has detected a problem in 'C:\Users\sclose\Documents\Visual Studio 2015\Projects\iSeries1\iSeries1\bin\Debug\iSeries1.vshost.exe'.
Additional information: The runtime has encountered a fatal error. The address of the error was at 0x71ccec3c, on thread 0x28bc. The error code is 0xc0000005. This error may be a bug in the CLR or in the unsafe or non-verifiable portions of user code. Common sources of this bug include user marshaling errors for COM-interop or PInvoke, which may corrupt the stack.
Just a very simple noddy program which sets a connection string and opens a new connection:-
string ConnectionString = "DataSource=MACH03Y;UserID=sysmon;Password=xxxxxxxxx;LibraryList=U1SCLOSE;Naming=System";
_connection = new iDB2Connection(ConnectionString);
Have iAccess for Windows 7.1 installed and am able to connect and sign on to the iSeries through System i Navigator
Tried:-
1) Various combinations of UserId's and Library lists (valid and invalid)
2) Valid and Invalid DataSource values
3) Different IBM.Data.DB2.iSeries.dll versions including the latest
Always the same failure
We know the same code works successfully in a live environment but this is maybe first time it's been tried in a dev environment!
Normally in dev it uses a mock service and goes nowhere near a real iSeries
I have more experience on the iSeries side than the .NET side
Thinking it's maybe a Network/Firewall issue?
Any help gratefully received
Whenever I have seen this error, it has been a problem with the Visual Studio Debugger. I do not think it is a problem with your code or the IBM.Data.DB2.iSeries.dll.
Error code 5 is an access violation in Windows. These debugger crashes are usually fixed by upgrading Visual Studio or applying the latest service pack. VS2015 is screwy in lots of ways, since it was a ground up rewrite, and I had these errors a few years ago until they fixed them. Try a service pack first. If that doesn't help, try either version 2012 or 2017. There also conceivably could be a Windows update that broke this. It has happened before.
See also: "vshost32.exe has stopped working" OR "fatal execution engine error" in Visual Studio
I got the exception mentioned in the title, and its inner exception contains this text:
Retrieving the COM class factory for component
with CLSID {609E6B75-5664-11D4-958C-080009D5C296}
failed due to the following error: 800401f9.
This problem occurrs on my 64 bit computer (Win 7), after I moved an entire solution (with 3 projects) from another machine (also 64 bit, Win Server 2008).
There was no problem on the source machine when the building was in progress (the target platform is Any CPU in both cases). The solution was built properly. But on my computer it throws an exception when I start the program.
The project refers to 6 DLLs (written in .NET, but I don't know them well).
I didn't find the mentioned CLSID under HKEY_CLASSES_ROOT\CLSID on my computer, but those are there on the source computer (but I don't know how they got there...). I kind of stuck. I would appreciate any suggestion, advice how to get through this. Thank you.
I am trying to change the Terminal Services settings programmaticly. I learned that you must use tsuserex.dll. Being c# i ran tsuserex through tlbimp and created TSUSEREXLib.dll then registered it with regasm. I got it working and wrote a framework program with it as a prof of concept. However today after I made some changes when I run my program I get the error
Unable to cast COM object of type 'System.__ComObject' to interface type 'TSUSEREXLib.IADsTSUserEx'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{C4930E79-2989-4462-8A60-2FCF2F2955EF}' failed due to the following error: No such interface supported (Exception from HRESULT: 0x80004002 (E_NOINTERFACE)).
it thows the exception on the line
IADsTSUserEx iad = (IADsTSUserEx)((DirectoryEntry)user.GetUnderlyingObject()).NativeObject;
This exact line worked fine in the test project. I know user is a valid UserPrincipal, Googleing I found this is usually just needs the dll re-registered, but even after unloading and reloading it it still will not work. What am I missing to cause my dll to stop working.
I know this is an old thread but since I had trouble recently finding all the required steps to get the Terminal Services components working on Windows 7, I wanted to share what I found. I think the steps below are more reliable than copying the tsuserex.dll from a server and trying to register it.
From what I understand, on any operating system you need Remote Server Administration Tools (RSAT) installed in order to modify Terminal Services attributes of a user account programmatically. On some versions of Windows this requires a download. But on Windows 7, RSAT is already installed.
But you may need to enable it using the configuration options in Control Panel (appwiz.cpl). Under "Turn Windows features on or off" goto "Remote Server Administration Tools" then ensure that "Remote Desktop Services Tools" is checked.
After I did this (and rebooted) I was able to use the components from tsuserex.dll via PowerShell (e.g., Set-QADUser -Identity testUser -TsHomeDirectory "c:\tshome"), and by adding a reference in Visual Studio 2010 (to "tsexusrm 1.0 Type Library").
You almost certainly need to re-register your TLB on the target machine. What likely happened is you have your assembly, interface or type GUID not hard coded in the application and hence it's changed on every rebuild. So after rebuilding and deploying your type no longer matches up with the previously registered TLB.
The correct answer is that I am a idiot for not reliseing that my build environment did change. I moved to a new workstaion that was windows 7 corprate instead of server 2003 when i started on the project. Win7 corp does not have tsuserex.dll in its system.
Visual Studio Build Setting „Platform target“ disable=> “Prefer 32-bit” solve the Problem.