We've had a 32 bit terminal services computer running some Windows services we constructed using .NET. Recently we moved everything to a 64 bit machine. Most things work. However, we are getting grief from a dll for apachefop.net.
In particular we get the following error
Error: Plugin Transcript Service
Execution Failed: Could not load file
or assembly 'apachefop.net,
Version=0.0.0.0, Culture=neutral,
PublicKeyToken=null' or one of its
dependencies. An attempt was made to
load a program with an incorrect
format.
I'm guessing that this is because it isn't meant to work on a 64 bit machine. Any suggestions about how to rectify this type of situation?
The problems seems to be caused by the fact that your assembly has been compiled with the anycpu setting. In this mode, when run on a 64 bits machine, your process automatically becomes a 64 bits process while your native references don't... And as it is not possible to load 32bits libraries from a 64 bits process you're running into troubles.
To quickly diagnose if it is the case you can use the corflags.exe which is part of the .net framework :
corflags.exe pathtoyourdotnetprogram /32bit+
Then run your program. If your soft is running well, then you should change the anycpu settings in your project to force the compiler to compile to a 32bits assembly.
Related
This problem occurs on some virtual machines under Windows Server 2012 or 2016. I can only run the 32-bit version although it is 64-bit OS.
My DLL supposed to run on ISAPI-DLL mode (therefore called by IIS) also fails (Error 500).
I suspected msolebdsql.dll (SQL Server ODBC driver) to be only 32-bit compatible on these machines, but it seems unlikely.
I've been spending hours on looking for another feature that could be refused by Windows (invalid Windows API call ? There are very few, and it's very common ones). I failed.
Can someone help ?
I have a .NET core application that uses the library of PortSip. So far everything worked fine both locally in my Windows 10 laptop and in an EC2 AWS instance with Windows Server 2019 installed, and now I would like to make this work in a Docker container.
So I used a Dockerfile similar to what's mentioned it this link https://schwabencode.com/blog/2018/08/30/ASP-NET-Core-with-NET-Framework-on-Docker to have a Windows Server Core image with both .NET framework (what PortSip needs) and .NET core (what my app needs) as well as added commands to install C++ Redistributable.
The result is that I'm getting the following error when trying to run my app:
Unhandled exception. System.DllNotFoundException: Unable to load DLL 'portsip_sdk.dll' or one of its dependencies: The specified module could not be
found. (0x8007007E)
The DLLs are there! In addition, when I change them to PortSip's 32-bit DLLs, the error changes to "An attempt was made to load a program with an incorrect format". That means the existence of the DLL is felt, but still, for some reason, cannot be loaded.
Also worth mentioning that with the exact same installations (the .NETs and the C++ redistributable) in a blank EC2 as mentioned above the app works.
What am I missing?
Thanks in adavance
Solved by copying two DLLs, C:\Windows\System32\edputil.dll and C:\Windows\System32\msdmo.dll from my local machine to that docker image.
I made an application with ADO Component and connect to Oracle with it, I don't have any problem when I run it in another machine.
But, when I use ODAC component and TOraSession and connect with it via Direct Connect and run it in another machine I faced to this error:
The Program Can't Start Because dbrtl70.bpl is missing from your Computer. Try to re installing the Program to fix it
As I investigate, dbrtl70.bpl is Delphi package file in System32 folder.
I want to know how can I solve this problem.
I'm going to take a wild guess and suggest that you have a 64 bit machine. You've copied the .bpl files into the 64 bit system folder (System32) where your 32 bit Delphi 7 program cannot see them. Put them in the 32 bit system folder (SysWOW64) instead and all should be well.
To learn more about the issue, read up on the File System Redirector.
If you don't want runtime packages, and all your dependencies support being built without using runtime packages, then simply uncheck the use runtime packages option.
My app was asking for a .bpl package when run on other machines.
Cancelling 'link with runtime packages' didn't solve it until I deleted the runtime packages listed in 'runtime packages'. Then it was OK.
I am having problem in running windows service of 32 bit on 64 bit windows server, query that i have is as following
1) will there be any problem if a windows service( using all 32 bit DLL's) is running on a 64 bit widows server??
2) If yes then how can we make a windows service of 32 bit run on windows server 2003 R2.
every time i try to run the service event log shows me error that attempt a load a program that is with incorrect format.( Exception from HRESULT: 0x8007000B)
Can this be a problem of service having any of its dll's of 64 bit?
You can absolutely run a 32-bit service on a 64-bit Windows OS.
can this be a problem of service having any of its dll's of 64 bit?
If the service cannot find a 32-bit version of DLLs that it references, it would fail to load. If the service is written with managed code, use the Fusion Log Viewer (Fuslogvw) to see if there are any binding failures.
I am trying to compile and run a really really old application on my Windows 7 box.
It seems to need NTWDBLIB.DLL from SQL Server 2000. I can get that file, but it is a 32 bit file. When I try to run RegServ32 on it I get an error message.
Installing SQL Server 2000 Client tools is not allowed on Windows 7.
Is there any way of getting this file? (Short of making a 64 bit VM and installing on it to get the file.)
I just needed to copy the 32 bit version to the SysWOW64 folder rather than the System32 folder.
Kind of lame that the folder with 64 in the name is for the 32 bit stuff and the folder with the 32 in the name is for the 64 bit stuff.
Given the error message, it looks there may be issue with SQL Server 2000 executables in Windows 7. I'd suggest you to install a newer client (2005 or 2008 with all the required SP to be run on Windows 7), they are still able to connect to a SQL Server 2000 server.