I am working with SDL2 and its add-on libraries SDL2_image and SDL2_ttf, using Visual Studio 2017. The libraries, and the .dll files that come with them, are in another folder (C:\SDL2.0\lib\x86), which is in the system path.
When I run, it fails, with this error message:
The procedure entry point InterlockedCompareExchange#12 could not be located in the dynamic link library C:\SDL2.0\lib\x86\SDL2.ttf.dll.
I can fix this by putting libfreetype-6.dll, which comes with SDL2_ttf, in the same folder as the .vcxproj file; or in the Debug folder. I can also fix it by putting the .dll into c:\windows\SysWOW64. But I want to distribute my code, and I don't want to put that file in each folder or require users to have admin access (to access c:\windows\SysWOW64); I want Windows to find it in the PATH, as it does with the other .dll files it's using here.
A few things I tried as I looked around the web for solution (to no effect):
Recompiling libfreetype-6.dll
Downloading the latest versions of all associated libraries
Rearranging the .lib files in Project Properties, Linker, Input, Additional Dependencies. Admittedly I may not have tried all possible arrangements as there are several dependencies
regsvr32 libfreetype-6.dll. This led to a different error message:
The module "libfreetype-6.dll" may not be compatible with the version of Windows that you're running. Check if the module is compatible with an x86 (32-bit) or x64 (64-bit) version of regsvr32.exe.
I saw here that maybe I should use the version of regsvr32 in the system32 folder; when I do that, I get
The module "libfreetype-6.dll" was loaded but the entry-point DllRegisterServer was not found. Make sure that "libfreetype-6.dll" is a valid DLL or OCX file and then try again.
So: is there a way to get the program to find libfreetype-6.dll in another folder in the PATH, and eliminate the error message about the procedure entry point?
The program I'm testing on now is from the TrueType tutorial from the LazyFoo website (source).
I have a vb6 project, and when i tried to run the source code I got an error which points to the CMWImpt.dll.
I tried to put the dll in the System32, sysWow64, and project folder, and registered it. But this is the error:
CMWImpt.dll was loaded, but the DllRegisterServer entry point was not was not found. This file cannot be registered'
anyone who encountered this before?
thanks
What's the error message?
Not all dlls are registerable. Only COM dlls have registration. And they are usually but not always in the dll (sometimes in another dll).
Error messages that mention dll names are not COM errors mostly. COM errors are of the type "Cannot create activex object", unless correctly registered and the file deleted.
So your file is either corrupted or not a COM dll.
The WinAPI uses dynamic linking. DLL stands for Dynamic Link Library, COM dlls have 4 or so standard dynamic functions to controll COM like DLLRegisterServer.
So you need to provide more detailed info on the problem.
I have a very simple jar file and I'm trying to convert it to a mono dll using ikvmc, but I'm getting the message "Error: unable to load runtime assembly".
My command line is:
ikvmc -target:library test.jar
My jar contains only one class, that simply has a method returning a String.
I'm just trying to experiment with ikvmc at this point before starting to develop some more complicated things.
I'm using:
Open Suse 11.3, 32 bits
kernel 3.11.6-4-desktop
ikvmc version 0.44.0.5
mono 3.0.6
Any hints?
Ok, I've got it working...
I've copied all files on folder "/usr/lib/mono/ikvm" to folder "/usr/lib/ikvm".
Apparently, ikvmc searches for runtime assemblies on the same folder where ikvmc executable are located.
If someone knows a workaround or a unkown (for me, at least) setting that avoids such copy, I really would like to know.
I am creating a C++/CLI dll that will be loaded into a legacy c++ application. The legacy application does this with a traditional call to LoadLibrary. Both the application and the C++/CLI dll are compiled in 64 bit mode.
When the LoadLibrary call happens, it fails with error 193. This usually means that some non-64bit component is trying to load. When I look at the dll load output in visual studio 2010, I see the the failure is occurring when mscoree.dll is being loaded (to be exact, I see my dll loaded, then mscoree loaded, then mscoree unloaded, then my dll unloaded, then the error returned). Specifically C:\Windows\System32\mscoree.dll is being loaded, when I examine this mscoree.dll, I find that it is targeting I386.
How can I ensure that my application will link against the correct mscoree.dll? I understand this could be done with a manifest, but I can't find any good information about setting one up. The ideal solution would allow compilation in 32bit or 64bit mode and target the correct mscoree.dll.
As a side note, I found an mscoree.dll in a side-by-side folder that I verified is 64bit mode and copied it into my application directory with the hopes that it would pick up that one first. This didnt work and the C:\Windows\System32 version was still loaded.
Thanks,
Max
Output of CorFlags.exe on the C++/CLI dll
Microsoft (R) .NET Framework CorFlags Conversion Tool. Version 4.0.30319.1
Copyright (c) Microsoft Corporation. All rights reserved.
Version : v4.0.30319
CLR Header: 2.5
PE : PE32+
CorFlags : 16
ILONLY : 0
32BIT : 0
Signed : 0
Output of pedump.exe on C:\System32\mscoree.dll
PS C:\Windows\System32> pedump.exe .\mscoree.dll
Dump of file .\MSCOREE.DLL
File Header
Machine: 014C (I386)
Number of Sections: 0004
TimeDateStamp: 4B90752B -> Thu Mar 04 22:06:19 2010
PointerToSymbolTable: 00000000
NumberOfSymbols: 00000000
SizeOfOptionalHeader: 00E0
Characteristics: 2102
EXECUTABLE_IMAGE
32BIT_MACHINE
DLL
...
(pedump goes on from here to describe imports and exports but thats not important here)
Extended loading information
This is the full output from failed load.
Note: The C++/CLI dll is called DsfClr.dll
the output was obtained by running gflags.exe -i [exename] +sls and examining the results in a debugger
http://pastebin.com/FyumUiMN
UPDATE:
Using a tip posted in a below comment by Reuben, I was able to determine that mscoree.dll is indeed targeting AMD64, but pedump is providing invalid information because it is being run in WOW64. That being said I still cannot load this library, if anyone has any suggestions they would be greatly appreciated.
One more thing I have tried: I made a new C# application and referenced the C++/CLI dll, then, in the main() function, I instantiated a class in the C++/CLI dll. This caused an access violation exception before the main() function is called. When I remove the instantiation, the main function runs fine. My guess is that the instantiation is causing a delay load of my C++/CLI assembly, which causes the same load error I was seeing from the native assembly.
In case anyone runs across this error, it turned out that it was caused by my native libraries use of boost::threading. The boost::threading library uses some weird compilation settings. The result is a static library that is incompatible with clr or mixed-mode binaries. Of course, visual studio has no idea of this, so it happily links boost in and crashes when the dll is loaded.
The solution is to dynamically link in boost::threading. The easiest way to do this is to define BOOST_THREAD_DYN_LINK in your project settings. Once I defined that, the dll loaded fine.
A quick google search of C++/CLI boost threading will give plenty more information about this error
I just has a similar scenario.
LoadLibrary failed with 193.
My DLL is a managed C++/CLI DLL called from a native application with LoadLibrary.
However I only get the error on win7 systems. It loads fine on win10. The date of this original question suggests it was win7.
I narrowed it down to a thread_local class.
It appears win7 only supports basic types such as C pointers as thread_local. Anything more complex, even std::shared_ptr which win10 accepts, generates error 193 on Dll load.
For the record, the compiler is VS2015, and the code style is c++11.
I have tried to use the following code:
cd c:\windows\system32
regsvr32.exe dllname.ax
But this is not working for me. How can I register a DLL file on Windows 7 with a 64-bit processor?
Well, you don't specify if it's a 32 or 64 bit dll and you don't include the error message, but I'll guess that it's the same issue as described in this KB article: Error Message When You Run Regsvr32.exe on 64-Bit Windows
Quote from that article:
This behavior occurs because the Regsvr32.exe file in the System32
folder is a 64-bit version. When you run Regsvr32 to register a DLL,
you are using the 64-bit version by default.
Solution from that article:
To resolve this issue, run Regsvr32.exe from the %SystemRoot%\Syswow64
folder. For example, type the following commands to register the DLL:
cd \windows\syswow64 regsvr32 c:\filename.dll
If the DLL is 32 bit:
Copy the DLL to C:\Windows\SysWoW64\
In an elevated command prompt: %windir%\SysWoW64\regsvr32.exe %windir%\SysWoW64\namedll.dll
if the DLL is 64 bit:
Copy the DLL to C:\Windows\System32\
In an elevated command prompt: %windir%\System32\regsvr32.exe %windir%\System32\namedll.dll
I know it seems the wrong way round, but that's the way it works. See:
http://support.microsoft.com/kb/249873
Quote: "Note On a 64-bit version of a Windows operating system, there are two versions of the Regsv32.exe file:
The 64-bit version is %systemroot%\System32\regsvr32.exe.
The 32-bit version is %systemroot%\SysWoW64\regsvr32.exe.
"
Type regsvr32 name.dll into the Command Prompt (executed in elevated mode!) and press "Enter." Note that name.dll should be replaced with the name of the DLL that you want to register. For example, if you want to register the iexplore.dll, type regsvr32 iexplore.dll.
On a x64 system, system32 is for 64 bit and syswow64 is for 32 bit (not the other way around as stated in another answer). WOW (Windows on Windows) is the 32 bit subsystem that runs under the 64 bit subsystem).
It's a mess in naming terms, and serves only to confuse, but that's the way it is.
Again ...
syswow64 is 32 bit, NOT 64 bit.
system32 is 64 bit, NOT 32 bit.
There is a regsrv32 in each of these directories. One is 64 bit, and the other is 32 bit.
It is the same deal with odbcad32 and et al. (If you want to see 32-bit ODBC drivers which won't show up with the default odbcad32 in system32 which is 64-bit.)
Open the start menu and type cmd into the search box Hold Ctrl + Shift and press Enter
This runs the Command Prompt in Administrator mode.
Now type: regsvr32 MyComobject.dll
If the DLL is 32 bit:
Copy the DLL to C:\Windows\SysWoW64\
In elevated cmd: %windir%\SysWoW64\regsvr32.exe %windir%\SysWoW64\namedll.dll
if the DLL is 64 bit:
Copy the DLL to C:\Windows\System32\
In elevated cmd: %windir%\System32\regsvr32.exe %windir%\System32\namedll.dll
Finally I found the solution just run CMD as administrator then write
cd \windows\syswow64
then write this
regsvr32 c:\filename.dll
I hope that answer will help you
Everything here was failing as wrong path. Then I remembered a trick from the old Win95 days. Open the program folder where the .dll resides, open C:/Windows/System32 scroll down to regsvr32 and drag and drop the dll from the program folder onto rgsrver32. Boom,done.
And while doing this, if you get error code 0x80040201, try the solution in DllRegisterServer failed with the error code 0x80040201, but make sure, you open command prompt as Run as Administrator.
Knowing the error message would be rather valuable. It is meant to provide info, even though it doesn't make any sense to you it does to us. Being forced to guess, I'd say that the DLL is a 32-bit DirectX filter. In which case this should be the proper course of action:
cd c:\windows\syswow64
move ..\system32\dllname.ax .
regsvr32.exe dllname.ax
This must be run at an elevated command prompt so that UAC cannot stop the registry access that's required. Ask more questions about this at superuser.com
I just tested this extremely simple method and it works perfectly--but I use the built-in Administrator account, so I don't have to jump through hoops for elevated privileges.
The following batch file relieves the user of the need to move files in/out of system folders. It also leaves it up to Windows to apply the proper version of Regsvr32.
INSTRUCTIONS:
In the folder that contains the library (-.dll or -.ax) file you wish to register, open a new text file and paste in ONE of the routines below :
echo BEGIN DRAG-AND-DROP %n1 REGISTRAR FOR 64-BIT SYSTEMS
copy %1 C:\Windows\System32
regsvr32 "%nx1"
echo END BATCH FILE
pause
echo BEGIN DRAG-AND-DROP %n1 REGISTRAR FOR 32-BIT SYSTEMS
copy %1 C:\Windows\SysWOW64
regsvr32 "%nx1"
echo END BATCH FILE
pause
Save your new text file as a batch (-.bat) file; then simply drag-and-drop your -.dll or -.ax file on top of the batch file.
If UAC doesn't give you the opportunity to run the batch file as an Administrator, you may need to manually elevate privileges (instructions are for Windows 7):
Right-click on the batch file;
Select Create shortcut;
Right-click on the shortcut;
Select Properties;
Click the Compatibility tab;
Check the box labeled Run this program as administrator;
Drag-and-drop your -.dll or -.ax file on top of the new shortcut instead of the batch file.
That's it. I chose COPY instead of MOVE to prevent the failure of any UAC-related follow-up attempt(s). Successful registration should be followed by deletion of the original library (-.dll or -.ax) file.
Don't worry about copies made to the system folder (C:\Windows\System32 or C:\Windows\SysWOW64) by previous passes--they will be overwritten every time you run the batch file.
Unless you ran the wrong batch file, in which case you will probably want to delete the copy made to the wrong system folder (C:\Windows\System32 or C:\Windows\SysWOW64) before running the proper batch file, ...or...
Help Windows choose the right library file to register by fully-qualifying its directory location.
From the right batch file copy the system folder path
If 64-bit: C:\Windows\System32
If 32-bit: C:\Windows\SysWOW64
Paste it on the next line so that it precedes %nx1
If 64-bit: regsvr32 "C:\Windows\System32\%nx1"
If 32-bit: regsvr32 "C:\Windows\SysWOW64\%nx1"
Paste path inside quotation marks
Insert backslash to separate %nx1 from system folder path
or ...
Run this shotgun batch file, which will (in order):
Perform cleanup of aborted registration processes
Reverse any registration process completed by your library file;
Delete any copies of your library file that have been saved to either system folder;
Pause to allow you to terminate the batch file at this point (and run another if you would like).
Attempt 64-Bit Installation on your library file
Copy your library file to C:\Windows\System32;
Register your library file as a 64-bit process;
Pause to allow you to terminate the batch file at this point.
Undo 64-Bit Installation
Reverse any registration of your library file as a 64-bit process;
Delete your library file from C:\Windows\System32;
Pause to allow you to terminate the batch file at this point (and run another if you would like).
Attempt 32-Bit Installation on your library file
Copy your library file to C:\Windows\SystemWOW64
Register your library file as a 32-bit process;
Pause to allow you to terminate the batch file at this point.
Delete original, unregistered copy of library file
There is a difference in Windows 7. Logging on as Administrator does not give the same rights as when running a program as Administrator.
Go to Start - All Programs - Accesories.
Right click on the Command window and select "Run as administrator"
Now register the dll normally via : regsrvr32 xxx.dll
You need run the cmd.exe in c:\windows\system32\ by administrator
Commands:
For unregistration *.dll files
regsvr32.exe /u C:\folder\folder\name.dll
For registration *.dll files
regsvr32.exe C:\folder\folder\name.dll
Part of the confusion regarding regsvr32 is that on 64-bit windows the name and path have not changed, but it now registers 64-bit DLLs. The 32-bit regsvr32 exists in SysWOW64, a name that appears to represent 64-bit applications. However the WOW64 in the name refers to Windows on Windows 64, or more explicity Windows 32-bit on Windows 64-bit. When you think of it this way the name makes sense even though it is confusing in this context.
I cannot find my original source on an MSDN blog but it is referenced in this Wikipedia article http://en.wikipedia.org/wiki/WoW64
Here is how I fixed this issue on a Win7 x64 machine:
1 - error message:
"CoCreateInstance() failed
Plkease check your registry entries
CLSID{F088EA74-2E87-11D3-B1F3-00C0F03C37D3} and make sure you are logged in as an administrator"
2 - fix procedure:
Start/type cmd/RightMouseClick on cmd.exe and choose to "Run as Administrator"
typed:
regsvr32 /s C:\Program Files\Autodesk\3ds Max Design 2015\atl.dll
regsvr32 /s C:\Program Files\Autodesk\3ds Max Design 2015\MAXComponents.dll
restart Win 7 and back in business again !
Hope this helps !