I have a service that I've built using the C# ServiceBase class. It works when I run it in Windows 7 and Windows Server 2008; however, it doesn't work on Windows XP.
I created the service using sc create PBUService binpath= "C:\PBULogger.exe". This is the correct path.
Nothing is logging in the Event Viewer under anything and my exception handling code doesn't fire either.
I thought maybe I didn't have the correct .NET version installed, but I have 4.0 installed on the XP machine. However, I created this project using Visual Studio Express 2012, which I'm pretty sure uses .NET 4.5 by default. Is this causing an issue? All the classes I'm using are version 4.0.
I have stripped down all my code to the base methods and this still doesn't work. Here is my code:
namespace PBULogger {
class PBULoggerService : ServiceBase {
protected override void OnStart(string[] args) {
try {
base.OnStart(args);
} catch (Exception ex) {
EmailUtility.sendEmail("Service Error", ex.Message + ex.StackTrace);
}
}
protected override void OnStop() {
base.OnStop();
}
}
Since it doesn't log in the event viewer, it tells me it isn't even trying to start the service.
I found these entries in my registry for the service under 'HKEY_LOCAL_MACHINE/System/ControlSet001/Enum/Services/PBUService/Enum'.
Not really sure what it means.
Anybody know what's going on?
You must have compiled your exe either for .Net 4.5 or for 64-bit architecture (or both). This is the explanation of error code you run into from WinError.h:
// %1 is not a valid Win32 application.
//
#define ERROR_BAD_EXE_FORMAT 193L
Make sure you have compiled it for x86 platform or Any CPU, and whatever version of .Net Framework you compiled against is installed on the machine.
I found this after googling the windows service error number:
*Generally the error message means that the service manager couldn't find the exact .exe path to run the service. Sometimes, the service is installed from a directory with multiple words for the directory name. So the registry path to the service needs to be placed with double quotes.
Click ‘Start’ and type ‘services.msc’ and hit Enter
Check for the multimedia class scheduler and audio endpoint builder service.
Check for the path under "path to executable:" for both the services. Make a note of the same.
Also make a note of the service name for both the services.
The services are as follows:
AudioEndpointBuilder - AudioEndpointBuilder
Multimedia Class Scheduler - MMCSS
Now, let’s check if the paths under these two services are the same as well in the registry.
Click ‘Start’, type regedit and hit Enter
Locate the following key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\
Under services, check for these services: MMCSS and AudioEndpointBuilder.
Corresponding to the above two services, the Image path (on the right pane) should be same as the path in ‘services.msc’*
I found it here
In our case this happened after a server crash and the exe file got corrupted. We re-deployed the binaries and then the service started successfully.
In my case, this was due to building with target of 64-bit only. I forgot that one of my test servers running Server 2003 was 32-bit. My service runs fine on the 64-bit Server 2008 R2 box.
I think that there is a compatibility problem with .net framework that you use and windows server 2003.Do you use .net 4.5? Windows server 2003 can't run applications which target net framework 4.5.
http://www.microsoft.com/visualstudio/eng/products/compatibility
So you could change your target framework to 4.0.
Related
Okay, i've written a Console application and it works. This is the code.
static void Main(string[] args)
{
IceMain.Instance.Start();
Console.ReadLine();
IceMain.Instance.Stop();
IceMain.Instance.Term();
}
Now, when i write a C# Windows Service, and try to start the service. It didn't work. This is the Windows service code...
public partial class Service1 : ServiceBase
{
public Service1()
{
InitializeComponent();
}
protected override void OnStart(string[] args)
{
IceMain.Instance.Start();
}
protected override void OnStop()
{
IceMain.Instance.Stop();
IceMain.Instance.Term();
}
}
Of course, i gave it a service name, sid, and setup things correctly.
But when i did the net start sid it gave me:
Microsoft (R) .NET Framework Installation utility Version 4.8.3752.0
Copyright (C) Microsoft Corporation. All rights reserved.
Exception occurred while initializing the installation:
System.BadImageFormatException: Could not load file or assembly 'file:///C:\Project\sptrader_dotnet\ICEService\IcePrice\bin\Debug\IcePrice.exe' or one of its dependencies. An attempt was made to load a program with an incorrect format..
The service name is invalid.
More help is available by typing NET HELPMSG 2185.
All I know is that the underlying application also depends on several x64 C++ DLLs.
But i did set my service to compile in x64 platform, and made sure those Dlls are in the sample folder, but the service still cannot run, while in the Console application, it works.
How is that, and how can i fix it to run on a windows service?
It doesn't seem like it has anything to do with my service name, as I've written many windows service before and it all works, but for this case it involves some C++ DLLs.
The exception System.BadImageFormatException is normally associated with 32 bit Vs 64 bit mismatches.
Possible scenario:
Your service (IcePrice.exe) is a 64 bit process, (i.e., it was built as x64)
But the "actual service registration" is 32 bit, i.e., installed using the 32 bit InstallUtil
Try to install your service using the 64 bit InstallUtil tool
The 64 bit InstallUtil is normally in:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319 (note the '64' in the path)
https://learn.microsoft.com/en-us/dotnet/framework/tools/installutil-exe-installer-tool
When using the 64-bit CLR, use the 32-bit Installer tool to install 32-bit assemblies, and the 64-bit Installer tool to install 64-bit and Microsoft intermediate language (MSIL) assemblies. Both versions of the Installer tool behave the same.
I have an Elipse E3 Studio (build 5.0.434) server with a bunch of tags (running on a x64 windows) and I want to read then from a .NetCore (3.0) console application (same machine). The thing is Elipse works with COM (as far as I know) and .NetCore can't natively handle it. Gotta use some Interoperability Library or something. .netCore3.0 Release Notes at Windows Native Interop
To make the Elipse server work I used a hardkey so the server was running locally.
I have named my tag "A1" and set the value inside Elipse.
To make the access I made a C# program using e3DataAccessLib and referenced it on the .csprj.
The Program.cs is as follows :
using System;
using E3DATAACCESSLib;
namespace ElipseNetCore{
class Program{
static void Main(string[] args){
try{
E3DataAccessManager e3DA = new E3DataAccessManager();
e3DA.Server = "localhost"; //kinda pointless but still
object Value = new object();
object Timestamp = new object();
object Quality = new object();
e3DA.ReadValue("A1.Value", ref Timestamp, ref Quality, ref Value); //ReadValue is a Elipse Server method that takes in a "tag" and place the result in the ref's
Console.WriteLine($"Value: {Value}, Timestamp: {Timestamp} and Quality: {Quality}");
}//end try
catch(Exception ex){
Console.WriteLine("the mother funking error now is :" +ex.ToString());
//regsvr32 C:\Users\lucas.battistella\Documents\Desenvolvimento\ElipseNetCore\ElipseNetCore\obj\Release\netcoreapp2.2\win-x64\ElipseNetCore.dll
}//end catch try
}//end Main
}//end Program
}//end namespace
The Error I get is the following:
System.Runtime.InteropServices.COMException (0x80040154): Retrieving the COM class factory for component with CLSID {80327130-FFDB-4506-B160-B9F8DB32DFB2} failed due to the following error: 80040154 Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)).
Other answers point to a x32 on a x64 or vice-versa issue.
However I've already tried making sure everything is running on x64.
Then I tried everything on x32/x86.
Also tried manually registering the .dll with regsvr32 (as show in the commented out line in the first code block and also the E3DATAACESSLib.dll), got and error popup saying "the said dll was loaded but the entry point DllRegisterServer was not located. Verify if the said dll is a DLL or OCX file"
I've been entangled with this problem for a few days now and since I'm new to all this I don't even know if I'm tumbling in the right direction. I would really appreciate any explanation and please excuse my typos.
How do I retrieve data from an Elipse server? Have I missed something?
UPDATE: I have tried that exact same code on Visual Studio running on .Net Framework 4.7.2 and it worked.
Also tried (still on Visual Studio) on .NetCore and got the aforementioned error.
Work Around:
Forget about NetCore and migrate to NetFramework 4.8. Forget about VSCode and keep rolling with VS.
Every time I look back at this problem it intrigues me. The E3DATAACCESSLib was build against x32 and for NetFramework (which mean Windows necessarily). The weird bit is that it ran on my machine targeting x86 (VS and NetFramework 4.8) but not on VSCode and NetCore. I read conflicting information on libraries built for NetFramework working (or not) on Core.
Today I tried running the built working code on a different machine (virtual and remote) and it showed me the exact same error message. And I fixed it by installing the E3 program and restarting the machine, simple as that.
If that ring any bell to you please share the light.
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"
We've created a C# class library assembly and made it COM visible to be able to call its methods from PHP. This used to work fine, but now we wanted to install it on a Windows Server 2008 server and we keep walking into the error "Class not registered".
To rule out any dependency problems I made a tiny little test class library in C#. The class library is built for Any CPU and it is COM visible (also set COMVisible to true in AssemblyInfo.cs). The test class library only contains one class with one method. The class is called TestLib and the namespace is also called TestLib. The method is called Test and only returns a string.
What we have done is the following:
- built the TestLib.dll
- copied it to the Windows Server 2008 machine
- registered the dll with: regasm /codebase TestLib.dll
- the regasm tool returns a success message
- in PHP we simply try to create a new COM instance:
try
{
$test = new COM("TestLib.TestLib");
}
catch (Exception $e)
{
die($e->getMessage());
}
when we call this test script from either the browser or the commandline (php -f test.php) we get the error "Class not registered" in both cases
I also tried adding TestLib to the GAC by using gacutil -i, but to no avail; still the class not registered error.
Then I tried compiling the testlibrary with .NET 2.0 instead of 4.0 as the target framework, same result. The .NET framework 4.0 is installed on the server by the way.
Any ideas?
Okay, so after some more research I figured it out. The php.exe process is 32 bit. The COM visible assembly is compiled for Any CPU so it should be accessible to both 32 and 64 bit applications.
The problem is that on a 64 bit OS php.exe, and any 32 bit process for that matter, searches in HKEY_CLASSES_ROOT\Wow6432Node\CLSID instead of HKEY_CLASSES_ROOT\CLSID and in HKEY_LOCAL_MACHINE\Software\Classes\Wow6432Node\CLSID instead of HKEY_LOCAL_MACHINE\Software\Classes\CLSID. The registry entries in the Wow6432 keys aren't created by regasm that is shipped with .NET framework v4 on Windows Server 2008. On Windows 7 they are created, don't ask me why.
It also turned out that if I create a little test assembly for .NET v2.0 and register it with regasm that ships with .NET framework v2.0 that it does create the Wow6432Node entries on Windows 2008. Strange.
So my solution is to create a basic registry file on the server using:
regasm /regfile MyClassLib.dll
This creates a file MyClassLib.reg with only the 'normal' 64 bit entries. Then I exported the Wow6432Node keys from a Windows 7 machine and added it to that .reg file. Now when I import that reg file into the registry on Windows 2008 everything works fine.
For more info on the Wow6432Node entries check out: http://msdn.microsoft.com/en-us/library/windows/desktop/ms724072%28v=vs.85%29.aspx
Hope this saves someone else some time and headaches.
If you are trying to call a 32-bit COM DLL on 64-bit Windows, you will need to register it.
Copy your 32-bit DLL to C:\Windows\sysWOW64
Run C:\Windows\sysWOW64\regsvr32.exe your_com_32.dll
A bit more info with screenshots.
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.