I tried to use __declspec(dllexport) to export functions in my DLL, but it doesn't work.
When I run GetProcAddress in main app, it always shows "The specified module could not be found".
But if I export my functions by .def file. It works very well.
Can you help me to solve this problem. I want to use __declspec(dllexport) instead of the .def file.
Thank you very much.
(I'm using Visual C++ 2005, MFC)
The specified module could not be found
That's the wrong error message, you will only get that when LoadLibrary fails. Typically because you are using the wrong file name. GetProcAddress() fails with error 127, "The specified procedure could not be found".
Assuming it is actually the exported function name, you do not have a lot of options to rename the function with __declspec(dllexport). You only have extern "C" to suppress C++ name mangling. The exported name is still going to have a underscore before its name, #n after its name if it was declared __stdcall. Exporting completely undecorated is only possible in 64-bit code or by using a .def file.
Use dumpbin.exe /exports on the DLL to see actual names. You'll get a better dump if you delete the .pdb file first. Depends.exe is fine too.
I expect you're not looking for the right name when using GetProcAddress. Have you used dumpbin or Dependency Walker to verify the name of the exported function yet?
Related
How can I explicitly link to a .sys file on windows? MSDN says you can use the LoadLibrary() and the GetProcAddress() functions to basically explicitly link and access members of a dll. I can successfully use this to at least get a handle for an associated dll however when I try them with a .lib or a .sys they do not work or they return null. I can understand that it would not work with .lib maybe (even though it says library in the name) but I had read that .sys files were usually dlls.
if (0 == LoadLibraryA("videoprt.sys"))
{
printf("goodbye");
}
This will compile but the address returned will be zero for the .sys file, if I use a more typical windows dll it does not return zero. How do I link a .sys file so that I can access exported functions?
I have a program that uses different dlls and it crashed.
I am trying to work out the cause of the crash using WinDbg but I am having no luck so far.
I have the .dmp file but I have tried addig that as the symbol path, I have tried adding the dlls in th symbol path also and a few other things but it keeps telling me it could not find myprogram.dmp/symbols etc or just that the symbols could not be found.
What is the right method to get it working with the .dmp file?
Thanks I am new to this and finding online documentation only seems to help for programs that don`t have DLLs and other non built-in DLLs.
Example of some of the errors:
* ERROR: Symbol file could not be found. Defaulted to export symbols for mydll.dll
* ERROR: Module load completed but symbols could not be loaded for myprogram.dll
PDB not found : c:\users\me\desktop\myprogram.dmp\symbols\dll\ole32.pdb
I managed to load the default windows symbols adding the downloaded symbols to the symbols path. Must I add DLLs I am using in my project to the symbols folder or something?
PRIMARY_PROBLEM_CLASS: WRONG_SYMBOLS
C:\Users\me\Desktop\Assignments\4. DPI-600 Testing\DumpFileDebugging\symbols
First, set up a path for your private symbols. Let's call it X:\mysymbols. Copy all PDBs into that folder, just as a flat list. In WinDbg, set the symbol path to that folder
.sympath X:\mysymbols
Next, let WinDbg find the Microsoft stuff. Create a folder X:\microsymbols. Put nothing inside and do not use the same folder as X:\mysymbols. Add that folder to the symbol path:
.symfix+ X:\microsymbols
Now that everything is set up correctly, tell the debugger to refresh:
.reload
In rare cases only a
.reload /f; ld *
helps.
If you're still unlucky, try
!sym noisy
so that the debugger tells you what exactly is wrong with the symbols. Look up the error messages and try to fix them.
If it still goes wrong, you might simply not have the correct PDBs. PDBs are correlated to modules (DLLs and EXEs) by a kind of hash / timestamp. So either get the correct PDBs or try
.symopt+ 0x40
which forces the debugger to load whatever he gets without checking the hash. Be aware that callstacks etc. may be misleading if they are too far off.
Im busy to create a dll (in Windows, with VS 6.0).
That dll have some functions who call some other functions from a external dll.
In the main dll I have added :
include "external_lib.h"
But when I try to compile get this error:
main_lib.obj : error LNK2001: unresolved external symbol
_My_external_Function
It seems that the main dll do not find the external dll...
In external_lib.h there is no assign to "C:\myprg\external_lib.dll"
How can i assign the name of that dll ?
I understand that, if the directory is not defined, it search into "C:\windows\system", but how to declare the name of the external dll ? ( here "external_lib.dll" )
Must i declare it in main_lib.h or external_lib.h ?
After a big fight, I get it.
First I had to find the code of the external dll and recompile it to have his lib file ( all the tools like dll2lib do not work ).
Then include in link-import that external.lib, compile and it works.
Im happy.
I got a C++.NET library from a colleague with a name like "my-name.dll". Importing in IronPython is not possible since "from my-name import *" is not valid.
If I rename the library to "myname.dll" I get an error that the assembly manifest is missing (HRESULT: 0x80131018). Now I'm not sure wether it is a problem of the wrong name of the accompanying "my-name.lib" file (renaming didn't help) or if there is something different wrong.
I'm not an expert in .NET but as I testet with a VB.NET dll which I built myself (with a proper name) alle worked well.
Any ideas?
It's probably an issue with the assembly; calling clr.AddReference('my-name.dll') should work just fine. One possibility is that your machine is missing the proper VC++ runtime files. Try creating a small VB/C# application and loading the DLL from there.
Also, make sure the assembly is not blocked.
What is the meaning of building a dll as export library ? I just googled it.I found its a dynamic link library.Can anyone please explain what actually dll is ? and why do we need to add these statement in the .dll file
extern "c" _declspec(dllexport)
I studied the static and shared libraries but Im not sure why do we go for dll files.I learnt .dll is used for the run time. But can you help me and give me more information.Thank you in advance
I may have been a bit harsh in my comments. I am not an authority on dlls, but I have a bit of working knowledge of them, so I will try to give a short explanation.
The difference between static and shared libraries should be easy to find in a web search, but basically the code in a static library gets included into the final executable, so after the linking stage, the actual library file is not needed anymore to run the program; on the other hand, code in a shared library doesn't get included in the main program - the two parts remain separate, so the shared library (called dll on windows) will be needed every time the program is run.
"Building a dll as export library" is a bit of a confusing term. I had not heard of it before, and during a short search could only find it on a cygwin page, which you might have read, considering your initial tags. A dll can export some or all of its functions and data. Exporting means that they are available for other programs and dlls to use. Which names get exported can be controlled in various ways. One of those is inserting _declspec(dllexport) in the declaration of the function. Another way is by using a definition file with an exports section.
When creating a dll, an import library can be created. This is a file that can then be used when building an executable that uses the dll, during the linking stage, to let it know which names are exported from the dll, so the program knows how to resolve references to those functions; in other words: how to import them. (This is not always necessary. Many linkers allow you to directly link against the dll itself, thereby removing the need for an import library.)
I realize it can be confusing, but try to find a tutorial and some small examples to see how it works, and play with it a bit.