I am getting errors in event viewer every time my application runs this line:
Redemption.RDOSession rSession = RedemptionLoader.new_RDOSession();
event viewer error:
faulting application name: (my.exe)
exception code: 0xc0000005
faulting module path: C:\Program Files\Common Files\Microsoft Shared\Office16\mso20win32client.dll
The oddest part is that it proceeds to create the session and makes it to the end of my code if I let it, successfully looking up an email in Outlook. This is in production and has worked for years, but for some months now it has been racking up the same error in Event Viewer. End users don't notice, but IT is seeing thousands of errors now which makes it hard for them to know when other problems might be showing up.
I reproduced this on the first try with:
Windows 10 Home, OS build 19044.1706, Windows Feature Experience Pack 120.2212.4170.0
Outlook: Microsoft® Outlook® for Microsoft 365 MSO (Version 2205 Build 16.0.15225.20172) 64-bit
I added logging in my CS code to make sure this caused the error. The error occurs if set ignoreoutlook to "e", and not if I set it to "d":
Microsoft.Office.Interop.Outlook.Application oApp = (Application)Marshal.GetActiveObject("Outlook.Application");
if (ignoreoutlook.Equals("d")) return;
Redemption.RDOSession rSession = RedemptionLoader.new_RDOSession(); // new Redemption.RDOSession();
if (ignoreoutlook.Equals("e")) return;
As for:
C:\ProgramFiles\Common Files\Microsoft Shared\Office16\mso20win32client.dll
it doesn't exist. There is a dll of that name in both:
C:\Program Files\Microsoft Office\root\vfs\ProgramFilesCommonX86\Microsoft Shared\OFFICE16
C:\Program Files\Microsoft Office\root\vfs\ProgramFilesCommonX64\Microsoft Shared\OFFICE16
If Redemption wants to use that dll, how is it working without it?
Is there a way to configure Redemption to skip that dll and move on to whatever else it must be doing to get it to work after that error?
There are quite a few things going on once the MAPI system (when Redemption loads it and calls MAPIInitialize) initializes common Office runtime, which has a bunch of its own problems, since it loads telemetry and licensing. Some of that functionlity only works when running inside the (virtualized) Office app environment (it patches a few Win API functions etc.)
Check if you see the same problem in MFCMAPI if you log to a profile (to ensure the MAPI system is loaded). If you do, that means the problem is in the MAPI system and you can work with MS support. If not, something is specific to your app.
One thing to keep in mind is that your app must embed a manifest and advertise its support for Windows 10. Otherwise common Office run-time tries to patch wrong Win API functions.
Related
I faced very strange behaviour - after I overwrite .NET exectables with new versions from network drive it cannot start.
When try to start from Windows Explorer it shows me following error:
[Window Title]
C:\Programs\zzz\clients.net\zzzNet.exe
[Content]
C:\Programs\zzz\clients.net\zzzNet.exe
The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail.
I tried to execute following commands:
SxsTrace Trace -logfile:SxsTrace.etl
SxStrace Parse -logfile:SxSTrace.etl -outfile:SxSTrace.txt
And got following result:
=================
Begin Activation Context Generation.
Input Parameter:
Flags = 0
ProcessorArchitecture = AMD64
CultureFallBacks = en-US;en;ru-RU;ru
ManifestPath = C:\Programs\zzz\clients.net\zzzNet.exe
AssemblyDirectory = C:\Programs\zzz\clients.net\
Application Config File = C:\Programs\zzz\clients.net\zzzNet.exe.Config
-----------------
INFO: Parsing Application Config File C:\Programs\zzz\clients.net\zzzNet.exe.Config.
INFO: Parsing Manifest File C:\Programs\zzz\clients.net\zzzNet.exe.
INFO: Manifest Definition Identity is (null).
ERROR: Line 0: XML Syntax error.
ERROR: Activation Context generation failed.
End Activation Context Generation.
It is quite simple .NET application (1 exe + 8 dll files). It was built for .NET 3.5 Client Profile.
I not defined any special "manifest" there. Just clicked "New Windows Forms Project" in Visual Studio and developed it.
Also app.config does not contain anything special - only primitive standard settings - appSettings and userSettings sections.
On PC where I developed it all is perfectly works. Problems only began when I copy these binaries to this particular VM and try to start.
Also please note - these executables were not installed in GAC or such, I just copied them into a folder on VM and started. And when it was 1st time all was working fine.
So, the problem pattern is following:
Copy .NET execuatbles to new VM (it is Win 7 x64), run it, all is working fine. Close it.
Build new version of .NET execuatbles on host PC, copy new .NET execuatbles to VM (with files overwriting).
Try to start - got mentioned problem.
After some shaman-style actions (like OS reboot, etc) it begin to work but why that happened at all?!
Why replacing .NET executables with new versions is causing SUCH HUGE PROBLEMS?!
Also the BIG QUESTION - is there any special procedure to replace .NET executables to keep them working? Because it is a new app development, I do not want lost so much time on every new executables installation. :-\
Could you please help? Because it looks completely weird!
Thank you in adance.
PS. I checked all VS projects - all they have PlatformTarget=AnyCPU. Also in run-time I can see ProcessType=MSIL (I show this info in AboutBox for application). So, there is no mix of x86/x64 binaries.
It seems that was related to mapped network drive behavior.
When I copied new files from network drive folder it copied wrong files - a strange random mess of new files and older ones (which were there before I updated them on VM host).
The scenario to make it working:
on VM: delete all files in a folder on network drive
on VM host: copy new files into a folder which is mapped as network drive on VM
on VM: copy files into target folder
on VM: run application - it works now
Weird thing. I remember I have seen something similar with Windows Explorer on Windows 2008 behaviour when copying updated win32 binaries.
Over the last few weeks I've seen errors appearing in the windows logs quoting the following:
The description for Event ID 100 from source System.ServiceModel.Activation 4.0.0.0 cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.
If the event originated on another computer, the display information had to be saved with the event.
The following information was included with the event:
System.InvalidOperationException: Etw registration failed with error code e.
at System.Runtime.Diagnostics.DiagnosticsEventProvider..ctor(Guid providerGuid)
at System.Runtime.Diagnostics.EtwProvider..ctor(Guid id)
at System.Runtime.Diagnostics.DiagnosticTrace.CreateEtwProvider(Guid etwProviderId)
at System.Runtime.Diagnostics.DiagnosticTrace..ctor(String traceSourceName, Guid etwProviderId)
w3wp
1540
This is a windows server 2008, running sites under IIS and .NET 4
These errors are happening every 30 seconds or so now, and I have no idea where they are originating from.
All of the sites are running under the default ASP.NET v4.0 application pool.
Any one else had this error before?
I don't really want to do anything like a .NET repair unless I have to, as this is a live server and the sites on it are in use.
Thanks for any help.
OK while I never thought in 2012 I would be writing my first ActiveX control (and yes there is a good reason for it) I am struggling with getting it running under Windows 7 (x64).
The Solution Short Story: I was missing /codebase from some of my regasm calls and also mixing up 32 and 64 bit processes, but that wasn't being helped by the standard VS2010 command prompt mixing up 32 and 64 bit paths for regasm and cscript.
The long story follows:
I have been bouncing between
Creating an ActiveX control in .Net using C#
(Oops I had the wrong link .. although it looks like the link I initially supplied was someone copying the original blog page)
Creating an ActiveX control in .Net using C#
and
C# ActiveX control (CSActiveX)
And I appear to be building the projects successfully (for the latter one I had to change the resource compiler location to the correct location).
For the first project I am using the suggested installer, for the second project I am trying to use regasm directly.
But after this it all goes down hill. I try and register the all's but either:
I have no idea how I should be registering them, or:
I have no idea how I should be registering them.
My test case has been a simple JScript file containing
var x = new ActiveXObject( "name of object" );
Which fails with the error:
test.js(1,1) Microsoft JScript runtime error: Automation Server can't create object
I am not sure if this is a permissions issue, or a 32 vs 64 bit issue or a combination.
A lot of sites offering help on ActiveX are assuming you will be accessing it via a web page , so I have tried looking at IE permissions (even though I want to load the control into a 3rd part program).
I know if I use either the 'framework' or 'framework64' versions of regasm I can control where in the registry entries get put - and I have seen some references to running cscript as either 32 or 64 bit (which possible affects what part of the registry is searched) depending on the cmd shell invoked (and I have tried both ways, as well as trying an "administrator" shell).
So basically at this point I have no idea what I am doing or what I should be doing.
My goal is to register an ActiveX control on Windows 7 x64 and have it be able to be loaded by:
A test .js script running from the default Windows command prompt
Load the same control into something like Excel 2007 VBA (for testing only)
Load the control into a 3rd part application (RSView Studio from Rockwell) and have it hosted within a VBA application (and I need to check if this isa 32 or 64bit program .. I suspect the former)
Notes
For the project that users the installer (Creating an ActiveX control in .Net using C#), it installs the code into "c:\program Files (x86)\" and looking with regedit I find entries under "Computer\HKEY_CLASSES_ROOT\Wow6432Node\CLSID\" which I believe is telling me that the DLL was installed as a 32 bit process. I have tried running my cscript test from both a 32 and 64 bit cmd and they both fail. NOTE that the installer was creating the equivalent of "regasm /codebase" when it ran.
For the project where I tried using regasm to register it (C# ActiveX control (CSActiveX)), it has some additional code for registering an ActiveX COM control. This code mentions registering 32 bit in-process servers (see ActiveXCtrlHelpers.cs)
(BTW I'm also cursing auto correct in Safari/Lion at the moment, keeps changing lower case "DLL" into "all")
Edit 2012-08-07
Prompted by Art's answer I discovered:
From standard VS2010 command prompt
When running 'regasm /codebase' through the standard VS2010 command prompt (and as administrator to allow regasm to perform changes), the entries got dumped into the registry under HKEY_CLASSES_ROOT\Wow6432Node\CLSID and the test scripts failed from the same prompt.
However I can see the ActiveX control in Excel 2007 (32 bit)
From x64 Win64 VS2010 command prompt
When running under the VS2010 x64 Win64 command prompt (again as admin) the registry entries appeared under HKEY_CLASSES_ROOT\CLSID but this time the test scripts worked from the same prompt and also from a standard Windows cmd prompt (however they fail from a 32 bit prompt)
But!! I can't see the active X control from Excel 2007 (32 bit)
Now I just need to figure out what the windows equivalent of the *nix 'which' command to ensure which regasm I am using) the 'where' command
Looking at the VS2010 and Windows 7 command prompts:
VS2010 (standard prompt): cscript => c:\windows\system32\cscript.exe
regasm => c:\windows\Microsoft.net\framework\v4.0.30319\regasm.exe
VS2010 (x64 Win 64): cscript => c:\windows\system32\cscript
regasm => c:\windows\Microsoft.net\framework64\v4.0.30319\regasm.exe
Windows 7 std. prompt: cscript => c:\windows\system32\cscript.exe
Windows 7 32 bit prompt: cscript => c:\windows\SysWOW64\cscript.exe
This is all starting to make some of my confusion understandable. I have been unknowingly mixing and matching 32 and 64 bit systems, but the VS2010 standard prompt didn't help either!
(and my latest peeve - VS2010 saving files as UTF-8 with BOM)
I was able to make this work both via IE and vbscript by doing the following:
Create .NET class library named 'ActiveXTest'
Add a class named MyObject which is defined as follows:
namespace ActiveXTest
{
[System.Runtime.InteropServices.ComVisible(true)]
[System.Runtime.InteropServices.ProgId("ActiveXTest.MyObject")]
[System.Runtime.InteropServices.Guid("df2dac4d-ba8a-4ecc-b76e-958c1bc32f1f")]
public class MyObject
{
public string HelloWorld()
{
return "This is Hello World from the COM component!";
}
}
}
Compile the class. Go to the folder where you compiled the class and do the following from a Visual Studio command prompt: regasm /codebase ActiveXTest.dll
To test from a .vbs script, create a file in notepad call test.vbs. type the following into the file:
Dim myObject
set myObject = CreateObject("ActiveXTest.MyObject")
MsgBox(myObject.HelloWorld)
Open a command prompt and navigate to where where you created the Test.vbs and type: wscript test.vbs. A dialog should be displayed stating "This is Hellow World from the COM component"
To test this from IE, I created a TEST.HTML file with the following contents:
<HTML>
<HEAD>
<script language="JScript" language="JavaScript">
var obj = new ActiveXObject("ActiveXTest.MyObject");
alert(obj.HelloWorld());
</script>
</HEAD>
<body>
<span>nothing to see here!</span>
<body>
</HTML>
Open the TEST.HTML file in IE. You will get a warning about the ActiveX control; just say Yes to allow the interaction. You will get an alert dialog stating "This is Hello World from the COM Component".
Similar steps can be used to make it work from a .js file or from Excel VBA. Note that if you change the COM method signature of the ActiveX assembly I believe you will need to re-register it.
My app runs fine on my machine (of course/famous last words). However, when deploying it to another machine on the network, it won't even start up. I ran my EventLog utility on that machine and it told me this:
Type:Error
Source: .NET Runtime
Time Generated: 06/12/2012 15:35:12
Message: Application: duckbilledPlatypus.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.TypeInitialization
Exception
Stack:
at duckbilledPlatypus.PlatypusMainForm..ctor()
at duckbilledPlatypus.Program.Main()
So it's something in my main form's constructor that's the problem, apparently...which, I admit, is a little "busy":
InitializeComponent();
foreach (string arg in Environment.GetCommandLineArgs())
{
if (arg == "-DEBUG")
{
InDebugMode = true;
break;
}
}
SuspendLayout();
tsch = new ToolStripControlHost(dateTimePickerScheduleDate);
toolStripPlatypusMain.Items.Add(tsch);
CreateTableLayoutPanelAndChildren();
LimitPlatypusIDTextBoxesToOneChar();
ShareEventsAmongDynamicTextBoxes();
SetAllPlatypusDataControlsReadOnly();
ResumeLayout();
Does any of this look problematic? (it's all pretty standard stuff, except for the ToolStripControlHost).
Now as to the framework version: does the Event Log report the framework version used to create my app, or the framework version installed on the machine trying to run the app? If the former, and the latter does not have that framework installed, that's a problem, right?
So if that's potentially the problem, how do I determine which version of the .NET runtime is installed on that machine?
UPDATE
I don't know why this is, but I was able to see an err msg after running the app on the remote/deployment only when I right-click and select Run As (and ran as myself, as I don't have any "more special" privileges on that machine). When I did so, I got "Unable to find a version of the runtime to run this application."
If I simply 2-click the app, it dies without a whimper (no err msg).
View the
view the %WINDIR%\Microsoft.NET\Framework directory
to determine which versions of .NET are installed.
http://msdn.microsoft.com/en-us/library/y549e41e.aspx
Try running the Fusion Log Viewer on the problematic machine. It will provide details about binding failures.
http://msdn.microsoft.com/en-us/library/e74a18c4(v=vs.100).aspx
Make sure you run it as administrator. It silently fails if you do not.
UPDATE
Based on your error "Unable to find a version of the runtime to run this application.", I would suggest you don't have the same version of .NET installed on the box that your application targets. Did you verify the installed versions using the steps above?
Also see
.Net framework - "unable to find a version of the runtime to run this application"
I am a .Net developer. New to OPC. When I tried some samples of OPC Client all of them give this error. It seems the DLL is not registered it seems. But I don't know how and where to register this.
error: retrieving the COM class factory for component with CLSID failed due to the following error: 80040154
Even I tried this
regsvr32 Interop.OPCAutomation.dll",
but it also throws error like
The module "Interop.OPCAutomation.dll" was loaded but the entry-point DllRegisterServeer was not found.
Make sure that "Interop.OPCAutomation.dll" is a valid DLL or OCX file and then try again.
I have gone through so many existing forums. So many of them said to change the Platform Target to x86 and still I am having the same issue. FYI, I can see only see 'Active (Any CPU)' in the Platform option from the top of the Build tab of Project Properties.
Here are my environment details:
.Net 2005
OPCAutomation Weapper
Windows 7 64-bit OS
Dell Inspiron 1525 (I hope this is not a 64bit machine, but my engineer installed 64bit OS somehow).
Please help me.
Thanks in advance!
Just in case somebody is dealing with this problem (as I've recently been...) I get through it! After some time, I found out that it's something about the .NET framework running on 64-bit machines. As long as the.NET application works only with 32-bit CLR, we must set .NET framework to load CLR in WOW mode. To do so, type:
C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\Ldr64.exe SetWow
After this you should be able to run the applications.
You can go back and revert .NET Framework as it was before by typing:
C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\Ldr64.exe Set64
If the OPC Client Toolkit SDK (C++) is used, a problem with the remote registry service may cause this error as well.
On Windows 7, by default the Remote Registry service is set to manual and not started. Ensure that the Remote Registry service is started on all of the machines you want to deploy to. This can be done manually or using Group Policy.
The function GetCLSIDFromRemoteRegistry() uses the RemoteRegistryService in order to get the CLSID of an OPC Server. If this service is not started on the client machine, the OPC program may return the error 80040154.
The error you're getting is more than likely due to the OPC server not being properly registered. Make sure it is registered (usually by running it at the command line with a "/regserver" or "/service" parameter). There may also be security issues in which case you'd have to run 'dcomcnfg' (DCOM Config) to make sure the client has access to the server.
This question is a bit dated so I hope you figured it out by now, but I had the same exact issue and wanted to share my solution. In my case, I am using a Kepware server. If you compile and try to run a client application for this server using Interop.OPCAutomation on a machine that does not have the server installed, you will get a dll not registered error and "entry point not found" if you try to register the dll manually.
Solution: Make sure you've got the server installed and running.
Although this is an old post, I would like to share my solution.
My problem was that when I tried to install an application with the OPCAutomation.dll, it gave me 80040154 error because the class was not registered.
This is my solution, always with Administrator privileges:
Copy OPCDAAuto.dll into the "C:\Windows\System32" folder
On the cmd prompt type "C:\Windows\System32\regsvr32 opcdaauto.dll"
You should watch a message like this one:
image
Hope this helps!
The OPC dll only works in 32 Bits, my solution was to change the "Enable 32-Bit Applications" to True in the advanced settings of the relative app pool in IIS.