I built an application in c# vs2005 .net .
Everything works fine when i run the application in win 32 bit, But
when running the application in win 64 it crashes while trying to call
the pinvoke interlockedexchange(which is within the kernel32.dll) function .
This is the exception :
unable to find an entry point named 'interlockedexchange'
I didnt find the interlockedexchange function within the kernel32.dll under system32 directory but it was found under the syswow64 directory(in the kernel32.dll) .
I guess that the .net runtime is configured to the system32 directory and not to the syswow64 .
How is it possible to change this configuration ? Can you think of any other problem that could cause this?
any help would be appreciated!
thanks ,
Miki Amit
If you are set on using InterlockedExchange and want the 32-bit version, you can change your project settings to force it to run as 32-bit. Go to the "Build" tab in the project settings and change "Platform target" to x86. It will then run as 32-bit.
This does not directly answer your question, but why not call System.Threading.Interlocked.Exhange() rather than resorting to P/Invoke?
Related
I have a simple application using a product activation system offered by cryptlex (cryptlex.com).
The program works correctly on my computer, but when I try to run the program on another machine it returns this error:
I've already made sure that the dll is inside the executable folder and everything looks OK.
When I remove all part of cryptlex the program works perfectly on any machine (x86-x64)
I used depencywalker to check for errors and found these two in the executable that uses cryptlex:
Windows 7 64bits,
.NET Version: 4.0
You can use Process Monitor to record all file activities of the program. Set a filter for your executable. After reproducing the error, save the log as XML file.
Then run ProcMon Analyzer (note: I'm the author of it). It will analyze the file and give a list of DLLs that were not found.
You could also do that manually, but note that some DLLs may not be found at first, but later be found when looking in the %PATH% environment variable etc. The tool will remove all those entries which have PATH NOT FOUND first but SUCCESS later.
While the DLL is present, have you checked the bitrate?
Most C# projects default to building against Any CPU - if the DLL is specific to a bitrate (ie x86 or x64) then it might be that the program picks the wrong bitrate on end machines (usually x86) but the right one on your machine (x64). This is usually best resolved by building out different x86 and x64 versions; it's messier, but only .NET itself is good at using the Any CPU paradigm.
The exception should have detail about what DLL in particular was not found - maybe look closer?
GPSVC and IESHIMS missing should not be a problem; as indicated by the hour glass, they're deferred dependencies anyway.
I was working on a WPF application in Visual Studio 2015 and all went well until unexpectedly the build dropped me the CS2012 error inform me that it cannot access/update the executable in the /Debug directory.
I tried the following and it didn't work:
Restart
Close VS and open the application again
Build->Clean
I couldn't find any solution in the web so I tried:
1. to move the whole project directory to another location.
2. creating a new WPF project and assembling it file by file with copy/pastes.
The weird thing was that in both cases the application worked in the new location. I continued the experimentation (in the original directory) and i tried to build a "Hello World" Console application in the same directory. The result was that the trivial console application didn't work and produced the same problem as the WPF application (CS2012 error).
Since I haven't noticed any activity of another program (i.e., antivirus) trying to quarantine (or changing the file/folder permissions of) this folder, I assume that this has been done by VS somehow but I don't know why. Perhaps it is a bug.
Is anyone has a logical explanation about this problem? And a way to fix it?
I found that my other running solution was referencing the same < executable path>.
Just make sure that no other process is using the referenced folder/file/dll
Try to close all processes, move the project to a different folder (on a different disk) b restart the computer and everything will work as it should. It worked for me without any problems. Hope this helps someone
I wanted to quickly test something in a .NET Core Console Application Solution and ran into this issue due to BitDefender blocking the resulting binaries.
I've named the app client which actually was the culprit. Renaming my solution fixed this.
Sometimes antivirus softwares can block copying an exe file from a folder to any path. You can manage by settings or the easiest way is to shut down live protection while you are coding and debugging.
:)
Deactivate your anti-virus for a while and try again.
This works for me.
I have developed an C# application that run very well in local.
But there is a problem when i put on the server.
The application uses a DLL library in his references (A.dll) and in a point of the execution the A.dll creates in the Temp directory another DLL (embedded in it, let's call it B.dll).
But when the A.dll try to load the B.dll an exception is threw:
system.invalidoperationexception: failed to load B.dll
I have not access at the DLLs source, are libraries.
So recap:
The process have the full control permission on the file and path.
(cheked)
Is running like Administrator. (checked)
In my application if I try to open the dll in binary mode, the
operations have no problems.
Runs well on every OS that i have tested (Windows 8_64 / XP_32 /
2008_32 / 7_64), but fails with 2008 R2 64.
I have tried to ReDownload, rename, reinstall the B.DLL, i have putted the program in the same path of the B.DLL, etc etc, with no results.
So at this point I think that is a security problem on the server, like "Processes cannot load DLLs" or something similar.
The exception:
http://i.imgur.com/NmB2Fth.png?1
Anyone can suggest me any solution? Would i check better? Where?
P.S
IF i try to register the dll i got the same error of this:
Register DLL file on Windows Server 2008 R2
The solution was simple.
I have used a very useful tool named Event Viewer (Start->Execute->eventvwr.exe)
When i started my application a new error event was showed on the Windows Logs->Applications:
Activation context generation failed for "C:\Temp\APP\myfile.dll".
Dependent Assembly Microsoft.VC90.CRT,processorArchitecture="x86",
publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8" could not be found.
Please use sxstrace.exe for detailed diagnosis.
A quick search and the result was that the server needed the Visual C++ Runtime for x86 (x86 because my application works in the 32bit application pool)
Once installed this package: http://www.microsoft.com/en-us/download/details.aspx?id=5582
Everything worked like a charm.
I hope this will help anyone to save some time!!
I'm trying to use DLLImport in my Mono Mac project in order to use my own .dylib but I get the DllNotFoundException. I'm guessing it has something to do with my .dylib since I'm able to do this with existing .dylib files such as the libmojoshader.dylib.
Here's how I use DLLImport
[DllImport("libtestDylib.dylib")]
static extern int libsum(int a, int b);
I then call the libsum function in order to see if it works.
I've found that running the app through the terminal with the MONO_LOG_LEVEL="debug" MONO_LOG_MASK="dll" mono myGame.exe command is a great way to debug issues like this, however I can't get my app .exe to run. I've tried using both the .exe in build folder and the one in the .app/contents/MonoBundle, I've also tried running file in .app/contents/MacOs as this is referenced in some places I've found while researching.
The last file throws a "File does not contain a valid CIL image." and the two others "No Info.plist file in application bundle or no NSPrincipalClass in the Info.plist file".
So, I would guess that the first step is to manage to run the app through the terminal in order to get proper debug information as for why my .dylib can't be found.
The .dylib I made is an empty BSD C lib made in XNA4.
Edit
I can't even seem to get the existing dylibs to work now.
I found the problem by making a new Mono Mac project with a single c# file which I then compiled through the terminal and ran it with the debug command. With the terminal feedback found out where the program was searching for the .dylib, and that the lib I made was built with the wrong architecture which was simply solved by building for 32-bit systems.
I've created a WPF Window with a lot of buttons, each of them run a different program. To run MS Word, for instance, I used:
System.Diagnostics.Process.Start("C:\\Program Files (x86)\\Microsoft Office\\Office14\\WINWORD.EXE");
But when I try to run the Windows 7 Snipping Tool the same way it doesn't work. It was supposed to be like this:
System.Diagnostics.Process.Start("C:\\Windows\\System32\\SnippingTool.exe");
I'm sure the path is correct, but always appears a message saying the file wasn't found. I would like to know why is this happening.
Important: I use Windows 7 64 bits.
Use this:
// if the build platform of this app is x86 use C:\windows\sysnative
if(!Environment.Is64BitProcess)
System.Diagnostics.Process.Start("C:\\Windows\\sysnative\\SnippingTool.exe");
else
System.Diagnostics.Process.Start("C:\\Windows\\system32\\SnippingTool.exe");
The problem is in your build platform (x86) and the automatic redirection of the folder C:\Windows\System32\ on 64-bit OS'es.
Basically, for several reasons, in vista/windows 7 64-bit OS'es when a 32 bit application try to access to C:\Windows\System32\ it is automatically redirected to the folder called C:\Windows\SysWOW64\. Hence, you cannot start snippingtool.exe because it is not present in that folder.
The only way is to use C:\Windows\sysnative\ and bypass the redirection.
My psychic debugger tells me that you are running a 32-bit program on a 64-bit version of
Windows, so your call to %WINDIR% (C:\Windows) is actually being re-routed to C:\Windows\SysWOW64.
Use the environment variable instead of hard-coding paths to directories that may move around depending on the environment and/or Windows version..
You should use an environment variable instead. Likely you are running it on a 64 bit system and C:\Windows\System32\ is getting redirected.