I have a DLL created in VS 2008 and written in C#.
The dll project builds with the "Any CPU" flag.
When it is deployed and run on a Dell/Intel Windows 7 x64 machine it starts up OK, but it crashes when it tries to start using cryptography -- TDESAlgorithm.CreateDecryptor();
This is part of the mscorlib.dll.
I've built the app as targeting x64, but it also crashes in the same place. It runs fine on 32 bit machines.
How can I get this to run successfully on x64?
I ran into similar problem with windows services created in .NET. It was throwing exception and the Windows log file indicated errors in mscorlib.dll and kernel32.dll (if I remember correctly). No external 32 bits dll or special codes was used, only plain .NET.
The solution I got is to compile as x86 and then run it (as 32 bits) application on the 64 bits machine. This could be a solution as long as you don't need 64bits to run your app.
The solution I got is to compile as x86 and then run it (as 32 bits)
application on the 64 bits machine. This could be a solution as long
as you don't need 64bits to run your app. - Gaël Mo
I'd just like to point out that compiling and running for x86 on a 64 bit machine is NOT an answer... Joe would like to know why its crashing in x64 mode... obviously running in x86 mode works on x64 machines. If you couldn't get your car to run with a certain after-market part, would you consider it a valid answer if I told you to simply run the car without the part in it? Obviously not... Think carefully about your answers before posting them ok?
Does it run on the x64 machine if you build it for x86? If so, they
something isn't 64-bit ready. – sgmoore
I agree... I'd like to add that if you do not have the source code (you probably don't) then you are out of luck I'm afraid... I found THIS article that explains more fully... Apart from that, you may need to look into a different DES decryption library... OpenSSL/SSH perhaps?
Related
I have a c# project which is linked with c++ project. I am running my application in 64 bit machine now. How to configure the c# project to 64 bit? There is some compatibility issue I am facing in 64 bit machine now.
Previously I was running my application in 32 bit machine. It was working perfectly. In 64 bit machine the linking fails as part of my c++ code is giving the right output. when the c# linking code is hit the execution stops without throwing any errors.
You might have to set-up your project to target x86 or x64 specifically (depends on your C++ library).
I am trying to create a webservice where the functions are performed by a 64 bit DLL. When I try to build this service i get the error "An attempt was made to load a program with an incorrect format."
But when I run a 32 bit DLL it works fine.
I am trying to run in a visual studio 2012 on .net 4 framework in C#
I have tried changing the app pool settings in IIS and changed build platform target to any cpu. Cannot identify where the problem is coming from. Please provide you assistance. Thank you
Right click on the application pool you are using and go to Advanced Settings. Under (General) there is a setting called Enable 32-Bit Applications. If you're running on a 64 bit OS and this is set to true then the app-pool will be a 32bit process, and therefore your 64bit DLL won't load. Set it to false to make your app-pool a 64bit process.
Also, check the dependencies of the DLL you're building as 64bit. It may be using a 32bit dll/assembly. If you've got any [DllImport] attributes in your code then look at the .dlls they refer to and ensure they're 64bit compatible.
If your web service references 64 bit dlls it must be compiled to x64
Try not to mix AnyCPU compilation with 32 or 64 bit DLL (DLL can be compiled as 32bit or 64bit or both) - behavior will depend on platform and in some environments it will work, in some not.
I did a program in C# which runs perfectly in my machine and in another one, of 64 bits, which have the .NET Framework.
When I try to run the program in a 32 bits machine It explodes and I get:
In this link (http://geekswithblogs.net/steveclements/archive/2008/04/30/error--eventtype-clr20r3.aspx) I found some solutions, but none worked for me. I already deleted the not used DLL, in particular those involving MySQL.
Do you have any suggestions?
Thank you.
This question requires more error details like exception information, VS version, What kind of exe (Winforms, WPF, etc), but you can start by answering the following questions:
- Is your exe built for anyCPU?
Is the same .net framework version installed on both 64-bit and 32-bit PC?
Are you having any code that uses 64-bit dll?
Are you having any code that uses 64-bit constructs? (checking pointer size)
What VS/.net framework/OS version does your developer PC has? The 32-bit PC?
This question relates to these previous question on SO
Any CPU question 1 and Any CPU Question 2
I have a application which was originally built on Win XP using Visual Studio 2005 (don't laugh!). This app calls into our win32 C++ dll. The C# components which call the C++ dlls were built with the "Any CPU" configuration and have been happily working on Win XP without any issue.
We are now moving to Win 7 and the release version of our app (which was built on Win XP with VC 2005) works fine. However with the roll out of win 7 to our users we have now taken the opputunity to move to VS 2010 and I have built the C# components on win 7 with VC 2010 but now when running this version I get lots "unable to load abc.dll" where abc.dll is our win32 c++ components.
I understand that recompiling the C# assemblies with x86 config will solve the problem but what I don't understand is how the release version c# assemblies built with Win-XP/Visual studio 2005 (Any CPU config) are able to run on Win 7 without any issues? Surely these C# assemblies built with "Any CPU" should JIT to 64 bit code when loaded in Win 7 and cause BadImageFormatException or other errors because they call Win32 C++ dlls.
UPDATE : I have Some more information that have been requested in the comments below.
On my Windows 7 box I right click on my computer and look at the properties. The System information says "System Type : 64 bit operating system" confirming this is a Win64 OS.
Opening up the solution in VC2005 on Windows XP When viewing the configuration manager for the solution I can confirm ALL the C# projects are platform type "Any CPU".
When running the release build (which was done on VC2005/win xp) on 64bit Win 7 machine, I task manager shows the image name as "Test.exe *32", this confirms it is jit'd and loaded into 32bit process.
Under Win7, the process is 64-bit. 64-bit processes cannot have 32-bit DLLs in them, that's a pretty fundamental design limitation of Windows.
And the fact that this managed code EXE calls into a 32-bit DLL is not obvious from the get-go - P/Invoke, as well as COM interop, works via late binding. So the EXE is loaded, the loader does not check the dependencies - for one thing, the dependencies might be conditional - then the DLL loading time comes, wackiness ensues.
So yeah, if you have managed code with known 32-bit dependencies, you better specify a 32-bit CPU at compile time. Or recompile the C++ parts to 64 bits, that's also an option.
I can confirm that you should get BadImageFormatException. Is it possible that the compilation on XP was monkeyed with badly enough that it's not actually building AnyCPU but rather builds x86 labelled as AnyCPU. I can also confirm it's possible to monkey with a project file badly enough that it would do that and the project upgrade component chokes on that.
One possible explanation is that one of your projects in the solution on the 32-bit development system had a binary reference to a 32-bit assembly, which would force it to be loaded as a 32-bit process even on 64-bit systems.
My .NET 2.0 application imports unmanaged 32 bit dll.
The dll is loaded (first interop call happens) when user opens a file via a dialog within the application.
When I deploy the application via clickonce with target platform "Any", users on 64 bit windows get BadImageFormatException when trying to open files from the application (at the moment the unmanaged dll is loaded). I understand this is due to incompabible bitness of the 64 bit process and the 32 bit unmanaged dll.
I have redeployed the application using x86 as target platform. As I understand it, this should solve the bitness problem.
BUT
When I run the deployed application built for x86 on 64 bit system, I now get BadImageFormatException immediately before the application even starts. Tested on at least three 64 bit machines. On 32 bit machines, it works with no problem.
When I run the application directly from VS (or not directly, just a normal build, not going via ClickOnce), there is no problem on 64 bit windows when using x86 target platform. The application starts and user can load file - the interop call succeeds.
I have been debugging this for 2 days straight with no result - I have tried on different computers. It seems to consistentnly work on one of the computers I have tried. However, I do not have permanent access to this computer.
I have managed to build the ClickOnce deployment on my computer once and it worked on a 64 bit machine. This was single of maybe 100 tries! Nothing has changed, the only changed variable was that I did the successful build immediately after computer restart.
I did clean/rebuild/restart VS/restart windows MANY times. I have reinstalled VS 2008 and now also the whole OS, it did not help.
EDIT: I have just managed to get one good build (out of next 100 :)) and did comparison between the deployed directories.
The source of the problem is that ClickOnce generates the wrong target platform in the manifest of the main .exe:
<asmv1:assemblyIdentity name="app.exe" version="1.0.4.18" publicKeyToken=".token here." language="neutral" processorArchitecture="<b>msil</b>" type="win32" />
processorArchitecture should be x86.
So the question is how to consistently force VS to generate the correct processorArchitecture in the manifest when deploying.
Can anyone help please?
This was resolved by installing VS 2008 SP1 on 64 bit Windows 7. VS2008 SP1 on XP had the problem on two machines I have tried with.
I had this problem as well, using VS2008 SP1.
In my case I had a 32 bit DLL which had to be compiled as 32 bit and an application that was using it in the same solution.
Even though I specified X86 as the build target for the release build, when I published a 64bit application was compiled and included in the installer.
I found a slightly brutal solution to the problem:
Go into the configuration manager and remove all possible configurations except the one that you want it to build (Debug and release versions).
After doing this I found that the clickonce installer was generated with the correct application.
I hope this helps someone else, I have been battling this problem on and off for months.
I'd suggest to use Reflector to open the main exe deployed by ClickOnce and see the dependencies to make sure you are not deploying the 64 bit version of the dll by mistake.
You must resolve to run 32-Bit Applications in IIS 7. See http://www.fishofprey.com/2009/04/badimageformatexception-in-iis-70-on-64.html
Sometimes the ClickOnce publishing process seems to cache old files from previous Any CPU or x64 builds. Doing a Clean and Rebuild All didn't fix this problem for me. I needed to delete all of the bin and obj folders from my projects and reopen Visual Studio.
We ran into this problem and determined that the subdirectory of the user profile to which ClickOnce deployed our application must have become corrupted, because we were able to deploy the application successfully with ClickOnce when logged in as a different user on the same machine.
We were able to solve the problem simply by deleting the subdirectory of C:\Users\<user>\AppData\Local\Apps under which ClickOnce was deploying our application. In our case, this was C:\Users\<user>\AppData\Local\Apps\2.0.