I have a problem with import clr that crashes the .exe of my small program.
Here are the imports I use in my program:
import sys
from matplotlib.figure import Figure
from matplotlib.backends.backend_qt4agg import FigureCanvasQTAgg as FigureCanvas
from PyQt4.QtGui import QApplication, QMainWindow
from PyQt4.Qt import QGridLayout, QWidget
import clr
executablePath = 'E:\\PythonWS\\MyDll\\'
sys.path.append(executablePath)
clr.AddReference("MyDll")
import MyDll
Basically the program compile fine and I get an executable thanks to cx_freeze, but when I launch it with a log, it crashes when comes import clr
I don't know what to do to make it work, if anyone has an idea?
EDIT:
I added a try-except around the import clr like this:
try:
logger.info('in try')
import clr
executablePath = 'E:\\PythonWS\\MyDll\\'
sys.path.append(executablePath)
clr.AddReference("MyDll")
dllPath = clr.FindAssembly('MyDll')
import MyDll
ts = MyDll.TestSystem('127.0.0.1', '127.0.0.1')
print ts.mainBoard.isConnected()
except Exception as e:
logger.info("Unexpected error: {}".format(e))
But even with the try the appplication crashes... That leads me with 2 options,
either my try except isn't good and then why?
there is a real problem with clr and I need help about it.
EDIT2:
I tried importing other module that are from .pyd thinking it might be that the .exe could not find them but all the import I've tried were done without any problem.
EDIT3:
SO! After looking on other posts, I've seen that there were other ways to import dll: by using ctypes for example.
Problem is: my dll is in C# and apparently the import is not supported very well by ctypes... I got errors like WindowsError: [Error -532462766] Windows Error 0xE0434352 which did not help me much since it seems to be a very general error in windows, but this made me think maybe the thing that makes my program crash when importing clr is the same.. Does anyone know what could the error be related to?
So I am back to using .NET clr, but still no luck
For the record: I have tried both python 32 bits and 64 bits. Here are some more information
#with python 32 bits
platform architecture: ('32bit', 'WindowsPE')
sys.platform: win32
os.name: nt
#with python 64 bits
platform architecture: ('64bit', 'WindowsPE')
sys.platform: win32
os.name: nt
So I eventually made it work:
In the end, pythonNET was installed correctly but it seems the version wasn't the best (not sure if not the latest, or not the right version, or bit), so I deleted every file of pythonNET (that I had copy-pasted here and there to be sure it was seen) and downloaded the .whl (here) of a latest version (which wasn't the one pip was downloading).
And eventually the import clr worked...
I hope this helps some of you :)
Related
We have to deal with a problem on several computers, mainly with Windows 7 pro, but lately occurs with Windows 10 home too.
Our software try to access video file to work with, file located on the computer, and throw an error :
Unable to load DLL 'EvrPresenter32.dll': The specified module could
not be found. (Exception from HRESULT: 0x8007007E)
System.DllNotFoundException: Unable to load DLL 'EvrPresenter32.dll':
The specified module could not be found. (Exception from HRESULT:
0x8007007E)
This seems to occur when calling the function : Presentation.Windows.Controls.DirectShow.EvrPresenter.DllGetClassObject32(Guid, Guid, Object&)
However, EvrPresenter32.dll is present in the software directory where it is supposed to be, alike to computers where all works fine.
This happens with any video format (.wmv, .mp4, .avi...) or video access path.
We've try to manually register the .dll in C:\Windows\sysWOW64\ with regsrv32.exe, but this give an error :
The module EvrPresenter32.dll failed to load. Make sure the binary is
stored at the specified path or debug it to check for problems with
the binary or dependent .DLL files. The specified module could not be
found.
Drivers are up to date.
System is up to date.
Could you please, give us some tips to investigate and solve this problem ?
When ever we are moving the DLL's from one system to another system DLL will get blocked. So you are getting this issue.
How to Unblock DLL:
Right click on the DLL
Properties >> General
At the bottom you will see unblock click on it.
See the link for details explanation
Hans Passant Nov 9 at 10:47
This is a wrapper for DirectShow, written in C++/CLI. It has a
dependency on vcruntime140.dll, easy to overlook.
Next to Wai Ha Lee comment that helped us incriminate msvcr120.dll, we found this DLL is part of Microsoft Visual C++ 2013 Redistributable package.
After installing it on the system, our software video usage works properly !
Remind to the link to download it from Microsoft :
https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads
Added to prerequisites for our software...
Thanks a lot for your concern and help !
I couldn't figure this error out either it worked fine on Windows 7, but on Windows 10 it doesn't work. I fixed the problem though it had nothing to do with missing dependencies or Runtime redistributable packs.
The problem was I had to pack the DLL with upx and it started working again.
Something with the file being unpacked and compiled on old Windows XP operating system created a bad PE Header or Bad file format or something, but packing it with UPX did the trick works fine now and the DLL got 3x smaller haha.
I am getting what seems to be a common issue in my C# program.
I have been looking online in many places and tring different solutions. ALl of whihc have so far failed.
I came across this post and tried their solution which did not work:
Unable to load DLL The specified module could not be found
I downloaded dependancy walked to see if I was missing any other dlls which, it is reporting that I am but those dlls are the win-API dlls. Which according this link: https://social.msdn.microsoft.com/Forums/en-US/a28331ae-19a3-4a34-b3ba-1e8fd4430375/missing-apimswincore-dlls, it doesn't matter if dependency walker reports those as missing.
I have also downloaded and installed the VC++ redistribute 2015 x64 and x86 and I am still recieving the same error.
There was another post that recommended that I install the windows SDK. I did this for windows 10 and again, still the same error.(Missing dlls on 64 bit Win).
I have even tried placing the dll in system32 folder but again, no issue
I am running out of ideas on how to solve it so if anyone else ran into the same issue, any help would be appreciated.
For those wondering, I am developing on win 10 using VS2015.
EDIT:
The name of the DLL that I am using is called: SLABHIDtoUART.dll
My code for importing the functions is a as follows:
[DllImport("SLABHIDtoUART.dll")]
public static extern int HidUart_GetNumDevices(ref uint numDevices, ushort vid, ushort pid);
Here is the exact error:
System.DLLNotFoundException: Unable to load DLL 'SLABHIDtoUART.dll': The specified module could not be found (Exception from HRESULT: 0x8007007E)
Oh and I did change the compiler settings in VS from Any CPU to x86. Technically, I did not have that as an option by default and I needed to add a new option for the x86. After a recompile with the x86 compiler, the program still doesn't seem to be working.
I even moved all of the DLLs that the SLAB dll depends on and ran the program and the program still did not run. (SLAB dll depend on hid.dll, setupapi.dll, and kernal32.dll)
I apologize for not posting an update to this question!
I eventually figured out the issue. It would appear the I was using a 64-bit version of the dll for a 32-bit application. Once I loaded in the 32-bit version of the dll, I was able to compile without any issue!
I'm trying to find out using C# if MSOnline PowerShell module is available at OS.
From the first look - nothing difficult. We can invoke PowerShell methods from C#. But for some reason all code snippets I tried to use do not get result with MSOnline module.
For example we use method http://www.codeproject.com/Articles/18229/How-to-run-PowerShell-scripts-from-C and pass command like:
Get-Module -ListAvailable -Name (here is the name)
So if we run it for TLS module - it works fine. On the picture below we see how it works in C# console application and on the right - how it looks in PowerShell. Looks fair.
But everything changes if we try to lookup MSOnline module:
As we see - C# program gives no results, while PowerShell itself shows us that module is available.
I'm really confused. I thought that is something with my PC, but I have checked on some different ones including Server 2012 R2. Result is the same - this module can not be looked up via C# even if we use exactly the same command as in PS.
Has anyone seen such problem? If yes - what solution can be done to detect via C# if MSOnline PS module is present.
Thank you.
Actually I found a solution for my own question:
You need to make sure that your program and module has both 32 or 64 bits.
MSOnline is running x64 and if your programm is targeting 32 bit system or has Any CPU and runs 32 bits during runtime - you will get zero result.
That's it.
I have imported a DLL into Unity, and I am confident it has imported successfully. I have defined a function on the DLL for Unity to use, however whenever it is called, Unity throws me a:
DllNotFoundException: k8055d.dll
The DLL's function is defined through
[DllImport("k8055d")]
public static extern int Version();
and I get the error when this line is run:
Debug.Log (Version().ToString());
The reason I know it has found the DLL is that if I set the DLL to use both x64 and x86 architectures within the import settings, I get this error:
Failed to load 'Assets/Plugins/k8055d.dll', expected 64 bit architecture (IMAGE_FILE_MACHINE_AMD64), but was IMAGE_FILE_MACHINE_I386. You must recompile your plugin for 64 bit architecture.
But this error disappears when I set it to only use an x86 architecture within the import settings, the console just gives the DLLNotFoundException.
Information about the DLL can be found here.
First google result for IMAGE_FILE_MACHINE_I386. You must recompile your plugin for 64 bit architecture. tells you to try to install and use the 32-bit version of Unity (Editor) to work with your 32 bit dll (right here).
Googling a second time for your specific dll ("K8055D.DLL x64") brings up a forum post where some people compiled your dll for x64 (here, direct downloadlink here) and also interesting stuff going on here. Hope this gives you some pointers.
What should be simple has turned into a convoluted mess of ugliness. So here's the story. I downloaded the awesome Box2D, took out the important c++ files and added an interface for SWIG. I then proceeded to create the Swig wrapper by using a makefile
CC=g++
CFLAGS=-c -Wall -fPIC -I../
LDFLAGS=-shared -o box.dll
SOURCES=<OMITTED>
OBJECTS=$(SOURCES:.cpp=.o)
EXECUTABLE=box2d.dll
all: $(SOURCES) $(EXECUTABLE)
$(EXECUTABLE): $(OBJECTS)
$(CC) $(LDFLAGS) $(OBJECTS) -o $#
.cpp.o:
$(CC) $(CFLAGS) $< -o $#
swig:
swig -csharp -c++ -outdir Wrapper Box2D.i
clean:
-rm Collision/*.o
-rm Collision/Shapes/*.o
-rm Common/*.o
-rm Dynamics/*.o
-rm Dynamics/Contacts/*.o
-rm Dynamics/Joints/*.o
-rm Rope/*.o
Pretty normal stuff, and it works fine (After fixing %includes and not #includes in the interface file). So I "make swig" in cygwin, no problems there (had to re-order includes so base classes came first). Then I loaded it up in VS.NET 2012, copying all the wrapper .cs files into the solution and moving the DLL over. This is where it gets nasty.
First time round, I believe it was mixed x86 and x64 that was causing great issue. I could instantly see that this was the problem and was in no way confused by the highly descriptive error message:
System.BadImageFormatException: An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)
In my attempts to fix this, much of the Googling resolved that perhaps the calling convention was the culprate, so I changed the SWIG wrapper cpp file to export the functions into the dll as __cdecl rather than __stdcall, and updated the wrapper appropriately.
Anyway so I eventually fixed the x86/x64 mixing by making a new x86 build profile, and then upon calling any function in the dll, the program just hanged. So I decided to revert back to basics and simply compile with __stdcall, no wrapper mods, and just see if it would work.
It didn't.
Now it complains that it's missing entry points:
{"Unable to find an entry point named 'SWIGRegisterExceptionCallbacks_box2d' in DLL 'box2d'.":""} System.Exception {System.EntryPointNotFoundException}
Upon dumping the exports of the DLL, the functions are correctly mangled according to __stdcall
CSharp_b2_aabbMultiplier_get#0
...
SWIGRegisterStringCallback_box2d#4
SWIGRegisterExceptionCallbacks_box2d#44
etc. etc.
Now the C# wrapper end doesn't seem to find this a problem and goes straight ahead and ignores the mangling
[DllImport("box2d", EntryPoint="SWIGRegisterExceptionArgumentCallbacks_box2d")]
So I tried this out of desperation
[DllImport("box2d", EntryPoint = "SWIGRegisterExceptionCallbacks_box2d", CallingConvention = CallingConvention.StdCall)]
Which was met with the same problem. The solution? Stick the mangled name in.
[DllImport("box2d", EntryPoint="SWIGRegisterExceptionArgumentCallbacks_box2d#44")]
... for all 1392 DllImport attributes. Not a solution.
I've tried compiling DLLs with both minGW and Cygwin, so I doubt that the way the DLLs are compiled is much of an issue.
Does anybody have any idea what I'm doing wrong?
So it turns out that C# cannot into Cygwin or MinGW dlls, so I recompiled with VSC++ and everything went fine.