I have code written in C++ on windows.
My code compiles and links when I compile it as x64 but not when I change the build configuration to x86.
The failure is a linking error.
I'm using the function RtlIsNameInExpression from ntdll.
When I compile it in 32bit mode I get a linkage error (LNK2019) of unresolved external.
Any ideas why this might happen?
10x
first of all - how you declare function and which symbol can not found linker ?
declaration must be
extern "C" NTSYSAPI BOOLEAN NTAPI RtlIsNameInExpression(
_In_ PCUNICODE_STRING Expression,
_In_ PCUNICODE_STRING Name,
_In_ BOOLEAN IgnoreCase,
_In_opt_ PWCH UpcaseTable
);
i can guess that you miss NTAPI i.e __stdacall keyword if you copy-paste from here. for x64 exist only one calling convention, but for x86 exist different between __stdcall and __cdecl for example. this can explain why this found in x64 but not found in x86
what error give you linker (not compiler !) ? unresolved external symbol __imp__RtlIsNameInExpression ? (if yes you really forget __stdcall set) or __imp__RtlIsNameInExpression#16 ? in this case you declare function correct, but your ntdll.lib not containing this symbol. (may be you use old ntdll.lib
for xp ? ) simply search __imp__RtlIsNameInExpression#16 string as is in ntdll[p].lib - are it found ? if not you have old (xp) version of ntdll i guess.
The answer is in the online documentation for that function:
This function has no associated header file. The associated import library, Ntdll.lib, is available in the Microsoft Windows Driver Kit (WDK). You can also call this function using the LoadLibrary and GetProcAddress functions to dynamically link to Ntdll.dll.
If you can't add the ntdll.lib file from the WDK to your link command, then you need to use the LoadLibrary-GetProcAddress approach.
Also from the same section of documentation:
The functions and structures in Winternl.h are internal to the operating system and subject to change from one release of Windows to the next, and possibly even between service packs for each release. To maintain the compatibility of your application, you should use the equivalent public functions instead. Further information is available in the header file, Winternl.h, and the documentation for each function.
Related
As a Xcode developer I have to use my written code on windows, too. I think I have successful master all cross platform issues but now I have a real problem understanding the DLL hell on Windows.
I used my code with Xcode and Gcc (Ubuntu) successful. On Windows I get a error message:
Run-Time Check Failure #0 - The value of ESP was not properly saved across a function call. This is usually a result of calling a function declared with one calling convention with a function pointer declared with a different calling convention.
I read much about this uses but I have my problems to understand the issue.
Normally on windows I have something like
#define MYLIB_API __declspec(dllimport)
I cannot find this inside the header of the Bass Library (bass.h). There is only one line
#define BASSDEF(f) WINAPI f
Now, I try to dynamic load the DLL functions in my code. You can see the dynamic loading header as link on bottom. To much to copy here. This dynamic loading is working for .dylib and .so libs well, not for .dll
My target is to load the DLL dynamic and not static with an additional lib.
In my code I use the bass.h and the bassdecode.h. In my code I call as sample:
bool returnVar = _BASS_SetConfig(BASS_CONFIG_DEV_DEFAULT,1);
And here I get the calling convention message.
What I have to do in my header file to successful import DLL functions on Windows?
You can download the files at: header files to download
Ok, for all who run into the same problem, the solution is the Answer from Hans Passant. I cannot mark this answer as solution so I want to give him the reputation.
My original typedef of the function:
typedef BOOL (*BASS_SetConfig_Type)(DWORD option, DWORD value);
Was searched in DLL
_BASS_SetConfig = (BASS_SetConfig_Type)DllFindSym(m_hMod, "BASS_SetConfig")
Where DLLFindSym is defined as:
#define DllFindSym(handle,name) (GetProcAddress(handle,name))
Now changed the typedef to
typedef BOOL (__stdcall *BASS_SetConfig_Type)(DWORD option, DWORD value);
Now everything works like a charm in Windows. Many thanks to the quick hint from Hans Passant.
after reading and learning for years on this great platform its my first post now.
My Problem:
In C++ I am trying to create a dynamic linked library (32 bit) that will serve as a AQMP Communication Client (based on SimpleAmqpClient). The dll file will then be used inside a third party application (32 bit).
During my tests where I invoke the dll in a custom executable everything works fine. But when I try to use the dll in the third party application I get an access violation error (0x00000000). I found out that the problem may be the function calling convention.
With the few code lines presented below that error can be reproduced. It disappears if I remove the __stdcall expression in mytest.dll. Normally I would expect the code to work because it uses the same calling convention in custom_test.exe and mytest.dll.
(Sidenote: the third party application expects a __stdcall function thats why I rely on it)
I would like to understand this behavior. Thanks in advance!
My Setup:
OS: Windows 7
32 bit Compiler: gcc 5.3 (Cygwin)
My Code (custom_test.exe):
#include <stdio.h>
#include <windows.h>
int main(void) {
HINSTANCE hInstance;
hInstance=LoadLibrary("mytest.dll");
FARPROC lpfnGetProcessID = GetProcAddress(HMODULE(hInstance), "test");
// Function prototype
typedef void (__stdcall *myFunction)(void);
myFunction test;
test = myFunction(lpfnGetProcessID);
// Call Function
test();
FreeLibrary(hInstance);
}
My Code (mytest.dll):
extern "C" __declspec(dllexport) void __stdcall test(void) {
printf("Inside Function \n");
}
I compile the code via
dll: g++ mytest.cpp -o mytest.dll -shared -std=gnu++11
exe: g++ custom_test.cpp -o custom_test.exe -std=gnu++11
The __stdcall convention makes it the responsibility of the called function to clean up the stack on return, while __cdecl makes it the caller's responsibility.
We can't see the actual declaration in the third-party DLL, but my initial assumption would be that the DLL expects arguments and is either using what it believes to be stack arguments in error, or is cleaning up the stack based on it's assumption of the stack arguments and generally messing with your stack.
EDIT
In this instance though, I see that when compiling in 32 bit, the test function is exported with a name of 'test#0'. If you change your GetProcAddress to use this decorated name instead it will work.
Ok now several hours later I can see clear again! Thx IanM_Matrix1 for the suggestion, the so called name decoration was indeed the point.
After my research I can now share some helpful ressources I found:
It is important to know that some compilers add different decorations to the function names, see here:
http://wyw.dcweb.cn/stdcall.htm
With that in mind one can read this page about Win32 calling conventions in general:
http://www.unixwiz.net/techtips/win32-callconv.html
When using gcc the decorations can also be disabled via the flag -Wl,--kill-at.
UPDATED: Added what RoInitialize looks like in roapi.h
I am in the process of writing a pure C++11 WinRT library. I do not use WRL or C++/CX (Obviously if I want pure C++11).
I got my code to compile and run on MSVC, but I want to see if I can get the code to compile and run on Mingw Gcc. Specifically, I am using GCC 4.7.2 obtained from nuwen.net.
What I need at this point is a way to call the Windows API Functions RoInitialize, RoUnitialize, RoGetActivationFactory and the HSTRING Functions WindowsCreateString, WindowsDuplicateString, WindowsDeleteString.
I tried compiling this program in G++ but got the error
extern "C"{
__declspec(dllimport)int __stdcall RoInitialize(int);
}
int main(){
RoInitialize(1);
}
I tried to compile but got:
c:\Users\jrb\Desktop>g++ gccwinrt.cpp
C:\Users\jrb\AppData\Local\Temp\ccy7y1V9.o:gccwinrt.cpp:(.text+0x1e): undefined
reference to `_imp__RoInitialize#4'
collect2.exe: error: ld returned 1 exit status
If anybody can point me in the right direction on how to declare these functions and what libraries I need to link to, I would appreciate it. Even if it requires LoadLibrary/GetProcAddress I would still be ok with that
Update: Here is what RoInitialize looks like in the header roapi.h
ROAPI
_Check_return_
HRESULT
WINAPI
RoInitialize(
_In_ RO_INIT_TYPE initType
);
ROAPI is just a define for __declspec(dllimport)
_Check_return_ is part of SAL (Secure Annotations Language?)
HRESULT maps to int32
WINAPI is a define for __stdcall
RO_INIT_TYPE is an enumeration so int should cover it
The import library for these functions is runtimeobject.lib (which the MSDN documentation fails to mention). It can be found in the Windows SDK for Windows 8.
The library you need to link against is windowsapp.lib (and only this lib, remove all others).
This topic lists the Win32 APIs that are part of the Universal Windows Platform (UWP) and that are implemented by all Windows 10 devices. For convenience, an umbrella library named WindowsApp.lib is provided in the Microsoft Windows Software Development Kit (SDK), which provides the exports for this set of Win32 APIs. Link your app with WindowsApp.lib (and no other libraries) to access these APIs.
APIs present on all Windows 10 devices - Microsoft Docs
See that page for a complete list of functions that implements; it includes RoInitialize, RoUnitialize, RoGetActivationFactory and WindowsCreateString, WindowsDuplicateString, & WindowsDeleteString (among many, many others). If you need other functions, you may need to link extension APIs also.
Similar guidance was originally on
https://msdn.microsoft.com/en-gb/windows/uwp/get-started/universal-application-platform-guide#writing-code but is no longer present:
Windowsapp.lib is an "umbrella" lib that provides the exports for the UWP APIs. Linking to Windowsapp.lib will add to your app dependencies on dlls that are present on all Windows 10 device families.
For delay loading, you will need to load api-ms-win-core-winrt-l1-1-0.dll, which is an API set, a collection of APIs that Windows can load regardless of where the actual DLLs are. This specific set is listed as a Windows 8.1 API set, however if you check the documentation for RoInitialize it says the minimum supported client is Windows 8. Assuming you use LoadLibrary and GetProcAddress, it shouldn't matter.
The actual DLL that the method is implemented in is combase.dll, but they use these API set DLLs as a level of indirection so that they are free to change or update that original DLL in the future.
For future reference, the API sets for Windows 10 (UWP) are listed on a separate page to the API sets for Windows 8 (and 8.1). The stub DLL (for delay loading) is the same. https://msdn.microsoft.com/library/windows/desktop/mt186421
Many other APIs also list their corresponding API set in their own documentation. For example, MSDN gives AllowSetForeground as an example.
If you don't have the import lib that contains RoInitialize, you'll need to use LoadLibrary/GetProcAddress to resolve the types.
Run-time link it like this:
#include <roapi.h>
namespace
{
FARPROC LoadComBaseFunction(const char* function_name)
{
static HMODULE const handle = ::LoadLibraryA("combase.dll");
return handle ? ::GetProcAddress(handle, function_name) : nullptr;
}
decltype(&::RoInitialize) GetRoInitializeFunction()
{
static decltype(&::RoInitialize) const function = reinterpret_cast<decltype(&::RoInitialize)>(LoadComBaseFunction("RoInitialize"));
return function;
}
}
HRESULT RoInitialize(RO_INIT_TYPE init_type)
{
auto ro_initialize_func = GetRoInitializeFunction();
if (!ro_initialize_func)
return E_FAIL;
return ro_initialize_func(init_type);
}
Source
I am attempting to build a project in Visual Studio 2012 that uses GnuTLS. I downloaded the latest official Windows build from the website, and created a link library by running lib /def:libgnutls-28.def in the bin directory form a Visual Studio command prompt.
After adding a typedef long ssize_t, the code compiles fine, but linking fails with the following error:
source_file.obj : error LNK2001: unresolved external symbol _gnutls_free
C:\Path\to\executable.exe : fatal error LNK1120: 1 unresolved externals
I am calling gnutls_free to free some memory allocated and returned by the library. If I remove the call to gnutls_free, the project links successfully. Given that gnutls_free is just a global variable (containing a function pointer) exported by the library, I'm not sure why accessing it results in an unresolved reference to a different symbol. I have verified that gnutls_free is not #defineed to anything.
As a test, I tried doing gnutls_free_function test = gnutls_free; which also resulting in the link error. Running grep -w -r _gnutls_free . on the GnuTLS source code returns nothing, so I am at a loss.
Any ideas for getting this working would be greatly appreciated.
EDIT:
Adding __declspec(dllimport) to the declaration of gnutls_free in gnutls.h allows the link to succeed. Is there any way to accomplish this without maintaining a custom version of the header file?
There doesn't seem to be a way to have the linker or import library automatically dereference the IAT's pointer to the data item the same way that is done for functions (via a small trampoline function that is statically linked into the module importing the function). The __declspec(dllimport) attribute tells that compiler that this dereferencing needs to be done so it can insert code to perform the dereferencing of the IAT pointer implicitly. This allows exported data to be accessed and for functions allows the compiler to call the imported function via an indirect call through the IAT pointer rather than by calling the trampoline function.
See a couple of Raymond Chen's articles about dllimport for a good explanation of what goes on for function calls (he didn't discuss importing data, unfortunately):
Calling an imported function, the naive way
How a less naive compiler calls an imported function
The MS linker or import library doesn't have a mechanism to help the compiler get imported data in a 'naive' way - the compiler needs the the __delcspec(dllimport) hint that an extra dereference through the IAT is needed. Anyway, the point of all this is that it seems there's no way to import data except by using the __declspec(dllimport) attribute.
If you want to avoid modifying the gnutls distribution (which I can understand), here's one rather imperfect workaround:
You can create a small object file that contains nothing but a simple wrapper for gnutls_free(); since gnutls_free() has an interface with no real dependencies, you can have the necessary declarations 'hardcoded' instead of including gnutls.h:
typedef void (*gnutls_free_function) (void *);
__declspec(dllimport) extern gnutls_free_function gnutls_free;
void xgnutls_free(void* p)
{
gnutls_free(p);
}
Have your code call xgnutls_free() instead of gnutls_free().
Not a great solution - it requires your code to call a wrapper (so it's particularly not great if you'll be incorporating 3rd party code that might depend on gnutls_free()), but it might be good enough.
I am facing linker error with my code. I am trying to compile with Visual Studio command Prompt (2010) in Win-7 X64 bit m/c.
The error which i see are as below.
dust2.obj
dust2.obj : error LNK2019: unresolved external symbol _NtOpenFile#24 referenced
in function _main
dust2.obj : error LNK2019: unresolved external symbol _RtlAnsiStringToUnicodeStr
ing#12 referenced in function _main
dust2.obj : error LNK2019: unresolved external symbol _RtlInitAnsiString#8 refer
enced in function _main
dust2.exe : fatal error LNK1120: 3 unresolved externals
The simplified version of my code is like this:
#include <windows.h>
#include <iostream>
#include <Winternl.h>
using namespace std;
int main()
{
NTSTATUS Status;
OBJECT_ATTRIBUTES Obja;
HANDLE SourceFile;
PUNICODE_STRING PathName=0;
PANSI_STRING p_path=0;
const char* ccp_path = "D:\\txt.txt";
RtlInitAnsiString( p_path,ccp_path );
RtlAnsiStringToUnicodeString( PathName, p_path, true );
IO_STATUS_BLOCK IoStatusBlock;
wprintf(L"%s", PathName->Buffer);
InitializeObjectAttributes(
&Obja,
PathName,
OBJ_CASE_INSENSITIVE,
NULL,
NULL
);
Status = NtOpenFile(
&SourceFile,
FILE_LIST_DIRECTORY | FILE_READ_EA | FILE_READ_ATTRIBUTES,
&Obja,
&IoStatusBlock,
FILE_SHARE_READ | FILE_SHARE_WRITE,
FILE_DIRECTORY_FILE | FILE_OPEN_FOR_BACKUP_INTENT | FILE_OPEN_REPARSE_POINT
);
if(SourceFile == INVALID_HANDLE_VALUE){
printf("\nError: Could not open file\n");
return 0;
}
cout<<endl<<endl;
system("pause");
return 0;
}
In another post in this forum the solution of these kind of problem was mention to include a #pragma.
I tried this solution by adding #pragma like this
#pragma comment(lib, "ntdll")
but on compilation i see another error that says "LINK : fatal error LNK1104: cannot open file 'ntdll.lib'".
I will much appreciate your help to resolve this problem. Thanks..
Can't let this question go unanswered like this. Because although the remark by Mladen is largely right for this particular native API, the whole topic deserves an in-depth discussion.
Preliminary cautionary note
Up front I should note that in many many cases it is neither desirable nor necessary to use one of the native API functions on Windows. However, there are a few cases where the Win32 API doesn't provide the means to query information or even manipulate data and so on. One such case would be several of the information classes available for NtQueryInformationFile/ZwQueryInformationFile.
One good example is the enumeration of alternate data streams on files and directories, which can be done using the Win32 API, in particular by using the backup APIs, but will require special privileges in that case. Not so if you resort to the native API. The same used to be true for hard links until Windows 2000, which introduced CreateHardLink to the Win32 API. Although in this particular case if you knew your way around you could have used MoveFileEx with MOVEFILE_CREATE_HARDLINK ever since it got introduced (although Microsoft still as of this writing marks it as Reserved for future use ... meh).
The canonical books about the native API are these two:
Windows NT/2000 Native API Reference, Gary Nebbett
Undocumented Windows 2000 Secrets: A Programmer's Cookbook, Sven B. Schreiber (free version from the author's website here)
... there are more, including one that discusses NT 4 and preceded Nebbett's book. But Nebbett's book used to start the hype around the native API, much like Hoglund's book started the hype around Windows rootkits. Not a reference regarding the Native API topic but still good:
Windows Internals, Mark Russinovich et. al.
Check out this website for a huge number of native API functions "documented":
http://undocumented.ntinternals.net/
So remember: the inherent risk when using these functions is that they go away in a future Windows version or their semantics change without prior notice. So be careful when you use them, if you use them.
On to glory ...
How to call native API functions
Actually there are two ways to call these functions. Microsoft was forced to disclose some of the native API functions in one of the antitrust law suits some years ago. These were shoved into winternl.h of the SDK. Microsoft expresses it thus:
The NtOpenFile documentation is provided for the sake of full API
coverage. NtOpenFile is equivalent to the ZwOpenFile function
documented in the DDK. For more information on the ZwOpenFile and
related functions, go to http://msdn.microsoft.com/library. In the
left-hand pane, click Windows Development, then click Driver
Development Kit.
However, there is no accompanying ntdll.lib file in the SDK. Microsoft suggests you link those functions dynamically (second option below).
You have several options:
The most common is to do as you did. But the ntdll.lib import library is only part of the WDKs, not the DDKs.
Use GetProcAddress to find the function pointer and call it. GetModuleHandle is sufficient for the Win32 subsystem since every Win32 program is guaranteed to have loaded ntdll.dll.
Method 1: ntdll.lib
If you have the DDK/WDK - for Driver Development Kit and Windows Driver Kit respectively - you get a full set of ntdll.lib files already. On my system (Windows 7 WDK 7600.16385.1):
C:\WINDDK\7600.16385.1\lib\win7\amd64\ntdll.lib
C:\WINDDK\7600.16385.1\lib\win7\i386\ntdll.lib
C:\WINDDK\7600.16385.1\lib\win7\ia64\ntdll.lib
C:\WINDDK\7600.16385.1\lib\wlh\amd64\ntdll.lib
C:\WINDDK\7600.16385.1\lib\wlh\i386\ntdll.lib
C:\WINDDK\7600.16385.1\lib\wlh\ia64\ntdll.lib
C:\WINDDK\7600.16385.1\lib\wnet\amd64\ntdll.lib
C:\WINDDK\7600.16385.1\lib\wnet\i386\ntdll.lib
C:\WINDDK\7600.16385.1\lib\wnet\ia64\ntdll.lib
C:\WINDDK\7600.16385.1\lib\wxp\i386\ntdll.lib
Create your own makeshift ntdll.lib
Otherwise you have to generate ntdll.lib yourself from the output of dumpbin (or by other means that allow to parse the exports of the DLL) which you can then output into a module definition file from which you can build an export .lib. Sounds convoluted? Not so much, let's see ;)
Using Ero Carrera's pefile Python module, we can do this:
import os, re, sys
from os.path import basename, dirname, join, realpath
try:
import pefile
except ImportError:
try:
sys.path.append(join(realpath(dirname(__file__)), "pefile"))
import pefile
except:
raise
def main(pename):
from pefile import PE
print "Parsing %s" % pename
pe = PE(pename)
if not getattr(pe, "DIRECTORY_ENTRY_EXPORT", None):
return "ERROR: given file has no exports."
modname = basename(pename)
libname = re.sub(r"(?i)^.*?([^\\/]+)\.(?:dll|exe|sys|ocx)$", r"\1.lib", modname)
defname = libname.replace(".lib", ".def")
print "Writing module definition file %s for %s" % (defname, modname)
with open(defname, "w") as f: # want it to throw, no sophisticated error handling here
print >>f, "LIBRARY %s\n" % (modname)
print >>f, "EXPORTS"
numexp = 0
for exp in [x for x in pe.DIRECTORY_ENTRY_EXPORT.symbols if x.name]:
numexp += 1
print >>f, "\t%s" % (exp.name)
print "Wrote %s with %d exports" % (defname, numexp)
print "\n\nUse this to create the export lib:\n\tlib /def:%s /out:%s" % (defname, libname)
if __name__ == '__main__':
if len(sys.argv) != 2:
sys.exit("ERROR:\n\tSyntax: fakelib <dllfile>\n")
sys.exit(main(sys.argv[1]))
A sample output of running this script (when named fakelib.py) would be:
> fakelib.py ntdll.dll
Parsing ntdll.dll
Writing module definition file ntdll.def for ntdll.dll
Wrote ntdll.def with 1984 exports
Use this to create the export lib:
lib /def:ntdll.def /out:ntdll.lib
Then we run the command as given on the last line. It is even better to give the /machine: parameter, of course. This is left as an "exercise" (*cough* *cough*) to the reader. The output with VS 2012 will be:
> lib /def:ntdll.def /out:ntdll.lib
Microsoft (R) Library Manager Version 11.00.51106.1
Copyright (C) Microsoft Corporation. All rights reserved.
LINK : warning LNK4068: /MACHINE not specified; defaulting to X86
Creating library ntdll.lib and object ntdll.exp
Congratulations. You can now use the ntdll.lib created by Microsoft's own lib.exe to statically import from ntdll.dll, even without having the "real" (original) .lib on your system.
Adjust the path and file names to your needs and tastes.
When using MinGW
Damon pointed out in a comment that the toolchain included with MinGW contains a tool gendef that can do the job of above Python script and that the output can be fed to dlltool.
Issues
The above method works perfectly when targeting x64 (64-bit), but for x86 (32-bit) I have encountered linker errors at times.
The issue is that the name decoration for __stdcall differs between x64 and x86. The former doesn't really use the same __stdcall as x86 and therefore just prepends an underscore. However, the latter also appends a the number of arguments times sizeof(void*) (i.e. 4). So for one argument the decorated function name for a function int __stdcall foo(int); becomes _foo#4.
This KB article from Microsoft outlines a way to get around the issue.
Method 2: dynamically imported, using GetProcAddress
Documentation in MSDN states (for NtOpenFile):
Note that the DDK header file Ntdef.h is necessary for many constant
definitions as well as the InitializeObjectAttributes macro. The
associated import library, Ntdll.lib is also available in the DDK. You
can also use the LoadLibrary and GetProcAddress functions to
dynamically link to Ntdll.dll.
Declare a function type, e.g. here we declare the type TFNNtOpenFile suitable in your case:
typedef NTSTATUS (NTAPI *TFNNtOpenFile)(
OUT PHANDLE FileHandle,
IN ACCESS_MASK DesiredAccess,
IN POBJECT_ATTRIBUTES ObjectAttributes,
OUT PIO_STATUS_BLOCK IoStatusBlock,
IN ULONG ShareAccess,
IN ULONG OpenOptions
);
... and then retrieve the function pointer and call it:
TFNNtOpenFile pfnNtOpenFile = (TFNNtOpenFile)GetProcAddress(GetModuleHandle("ntdll.dll"), "NtOpenFile");
status = pfnNtOpenFile(...); // can't be bothered to type out all parameters ;)
an alternative way of retrieving the function pointer could be this one:
static NTSTATUS (NTAPI *NtOpenFile)(
OUT PHANDLE,
IN ACCESS_MASK,
IN POBJECT_ATTRIBUTES,
OUT PIO_STATUS_BLOCK,
IN ULONG,
IN ULONG
);
(FARPROC)&NtOpenFile = GetProcAddress(GetModuleHandle("ntdll.dll"), "NtOpenFile");
which could be condensed even further by using the preprocessor stringification operator (#). The choice is yours.
These functions cannot be called directly because they belong to internal API and are not exposed through any of the libraries. You need to obtain addresses of these function using GetProcAddress.
For more information look here.