I have been assigned a problem where Borland C++Builder 6 is used.
Building a DLL project in my development environment on my laptop works fine, and using the DLL on the target machine works fine.
The problem arises when the DLL is built on a build machine that also creates the install package. That machine uses the exported makefile from C++Builder's .bpr file to build the DLL. Running the same program as previously with this DLL does not work OK (a call to a constructor seems to be hanging since debug printouts after the call are never seen).
I have built the DLL using the exported makefile on my own machine too, just to test, and that DLL does not work, either.
So, in short, the DLL works fine when built in Borland C++Builder 6, but NOT when built using the exported makefile. No code changes made.
Does anybody have any ideas what the problem might be? This is a very vague question, but the problem is very strange too.
Related
I have two problems with DLL compiled with VS2015 XP toolset when called from non VS2015 exe.
First and most serious is that using in such DLL-s tls variables (like statics declared inside function results in GPE on XP/Server 2003R2). Works fine on Windows 7+ and/or when called from VS2015 exe. Looks like something in runtime isn't initialized when called that way.
The second problem is with side by side installation of W10SDK/runtime DLL. Everything works fine with EXE but doesn't load from DLL path. You have either to install runtime or to copy DLLs to exe directory.
Can anyone suggest a solution especially to the first problem (second is annoying but can be handled).
Found a duplicate for first problem with workaround
Crash in CAtlStringMgr::GetInstance under Windows XP
What concerns second one - solved it with writing a VS2012 DLL proxy that chdirs to proxy directory, loads the library and then chdirs back (and then calls through all calls to VS2015 DLL. But would be glad to find more elegant solution
I'm developing a C++ application that dynamically link against Qt, boost and Assimp. I compiled it in Release mode with /MD and it works fine on my computer. However, if I try to run it on another machine I get the 0xc000007b error (The application was unable to start correctly). I use Windows 8.1 on both machines but Qt5.3 and VisualStudio2013 are only installed on the 1st machine.
I built boost with
bootstrap.bat
b2 variant=release
I then used Cmake GUI to configure/generate a solution for Assimp that I later built using Visual Studio 2013.
Qt (32-bit version) was installed via the online installer. So everything (including my application) is built with a target 32-bit.
The folder that I copy to the other machine includes:
MyApp.exe
platform/
accessible/
assimp.dll
icudt52.dll
icuint52.dll
icuuc52.dll
kernel32.dll
opengl32.dll
libEGL.dll (cannot be found in Qt/5.3/msvc2012_opengl/)
libGLESv2.dll (same)
msvcp1XX.dll
msvcr1XX.dll
The Qt libs that I need (Core, GUI, Widgets, OpenGL)
If I copy these .dll/folders from Qt/5.3/msvc2012_opengl/, the app requires msvcp110.dll to start. If I add it and run it, I get the 0xc000007b error. But why msvcp110.dll instead of msvcp120.dll???
And if I copy the files from Qt/tools/QtCreator the app actually needs msvcp120.dll to run. But when it runs, it crashes at the beginning with:
QEGLplatformContext::init: eglError: 3005, this: 0x2e806b0
Which I guess is normal as you're not supposed to copy them from this location.
Does anyone know what I am doing wrong?
PS: I also ran vcredist_x86.exe on the machine without VS2013 before running my app. It installed successfully but nothing changed.
Thanks for your time and your help!
I wrote a program in C++ using Visual Studio 2010
But when I run it on some computers with WinXP it says
"Cannot start because MSVCP100.dll wasn't found"
How do I prevent such dependencies on dlls that do not come with windows?
Thank you.
you cannot prevent this dependency, as it's the core runtime library of Visual C++. Instead, include the Visual C++ 2010 Redistributable package with your application (usually a separate link is enough since most people have it installed already)
However, if in fact your program cannot start because a dll with D at the end such as MSVCP100D.dll then you need to build your program in release mode, which by default switches the run time to a non-debug version. You need to be careful to nut out any other included static and dynamic libraries you're including in your project to make sure all debug or all release versions match for your builds.
If you are having trouble finding which sub-projects are referencing the debug versions, you can download and run depends.exe and browse through the exe file to see.
Sorry for the late respones, but yes you can prevent this dependency, just go to solution property of yopur project, go to C/C++ > Code Generator and in Runtime Library change it from MDd to MTd, will include statically the dependent libraries, and not in run time, like this avoid Run time errors while try to run the Dll.
I'm getting an 'AccessViolationException' 'Attempted to read or write protected memory' when calling a method in an x86 dll when running on an x64 platform (Windows 7). Everything works great on x86 platforms.
I've read many, many posts about similar problems but haven't been able to get my code to work.
I'm in the process of trying to make our old x86 app work happily on Windows 7 (x64) and Server 2008 R2 (x64). The app is an assortment of VB6 , VB.Net, C#, MicroFocus COBOL and C++. (We couldn't think of any other languages to throw in at the time). The DotNet code was originally written in Visual Studio 2003 for DotNet 1.1. I've ported the code up to Visual Studio 2010 and DotNet 4.0. I've set the target for all the projects to x86. When I call into un-managed 32 bit dll's I get the above error.
Our InstallShield setup routine is installing the x86 dll's into C:\Windows\sysWOW64 instead of C:\Windows\System32. This behavior seems correct. The dll's are some COBOL object code and runtime components linked together into a 'C Style' dll. I don't think the problem has to do with COBOL or the linking process as I also ported up a sample app from Code Project with a VB.Net WinForms app that calls a simple C++ dll, all targeted to x86. I get the same error there. I've also tried building a C++ command line app to call the dll. The Load Library succeeds. GetProcAddress succeeds. Calling the function pointer for the particular method fails. Our VB6 apps can call the dll's just fine when running on Windows 7 x64. I've also tried turning off UAC and setting the requestedExecutionLevel in the manifest to the highestAvailable. I've tried running as administrator.
Seems like this should work, but not sure what to try next. Any ideas?
On x64 .net programs will be run as 64-bit programs and cannot call 32bit-dlls.
Try compiling the application with target x86 instead of "Any Target". You can also force the
target of the built .exe with the .Net CorFlags.exe utility to run in 32bit-mode.
Of course your program will then run in the 32bit environment, especially it will only have a maximum of 2gb of RAM.
Good news,
We investigated DEP as a possible cause of the problem as we saw that even our VB6 code will fail when DEP is turned on. We noticed that the VB.Net code was failing in the same way as VB6 when DEP was on. Apparently our COBOL dll's do something that DEP isn't happy with. Unfortunately the DotNet assemblies don't seem to respect the operating system DEP setting, so you have to turn off DEP with using editbin.exe:
editbin.exe /nxnocompat:no
I still have to test it on our full application, but it looks like we have a solution!
I have a mex64 dll compiled on my machine. I used Matlab 2009b with VS2008 Pro to compile the dll. The dll works fine on my Matlab installation.
I want a colleague to use the dll so I sent it to him and he gets the following error message when trying to use the dll:
??? Invalid MEX-file 'filename.mexw64': The specified module could not be found.
My current assumption is that this is caused because he uses an older Matlab version or missing a dll that I have. I ran dependency checker and asked him to check that he has all the listed dlls.
I am still waiting for him to confirm his Matlab version.
What other reasons can cause this and can the Matlab version make a difference? (I mean R2009a when I have R2009B and not a huge version diff)
The other person has Matlab R2009a. Shouldn't the mex just work if I compile it on my computer and deliver it to him?
Does this only leave a missing dependent dll?
The issue is strange, but I can confirm it exists.
Using pre-built libraries for matlab that are correctly installed and in the path, I sometimes get the same error. If I type in the function name at the command-line, the function is visible and will auto-complete. However, the function will not initialize until I 'cd' into the directory with the .mexw64 library file.
>> AndorInitialize('')
Invalid MEX-file 'C:\Program
Files\MATLAB\R2011b\toolbox\andor\AndorInitialize.mexw64': The
specified module could not be found.
>> path
MATLABPATH
C:\Program Files\MATLAB\R2011b\toolbox\andor
C:\Program Files\MATLAB\R2011b\toolbox\andor\camera files
C:\Program Files\MATLAB\R2011b\toolbox\andor\m files
... etc
It turns out this is due to missing dependencies, which shouldn't be missing. To resolve the issue, use dependency walker (free, lightweight) to identify what's missing. The mathworks explains this.
http://www.mathworks.com/support/solutions/en/data/1-2RQL4L/
In my case, two DLL's weren't showing up properly, even though they were on my system and in the path. I copied the DLL's into the windows/system32 folder and the library functions now work correctly. What's particularly strange is that the same library worked on my computer a few days ago (prior to the moving the DLL's).
In general, MEX files should work across different versions of Matlab; in particular, they should be forward-compatible. You're right; sounds like a dll problem.
If you built it with Visual Studio, it may be linked to the Visual C++ Runtime. This is a set of libraries that is not installed on Windows by default. The "redistributable" for it can be downloaded here; having your coworker install that could resolve the problem. If that doesn't work, you can use Dependency Walker to check for other unsatisfied DLL dependencies.
Normally, configuring Matlab's "mex -setup" to use the Lcc compiler that's distributed with Matlab could be a way around this, but it's not supported for 64-bit Windows AFAIK.
Also, are you sure he has the 64-bit version of Windows?
Another possible source of the problem could be that you compiled in debug mode. The Visual C++ redistributables only support release mode.
The Dll was a wrapper for MySql access. We ended up using Matlab's ODBC and the MySql Connector.