The problem is running code on an older machine where a requested function does not exist. To check for it one uses LoadLibrary and GetProcAddress as demonstrated here, but GetProcAddress requires the address of the functions in a TypeDef prior to its use.
For example, take these two on e.g, XP SP2 32 bit:
typedef BOOL (__stdcall *LPFN_Wow64RevertWow64FsRedirection) (PVOID OldValue);
typedef BOOL (__stdcall *LPFN_ISWOW64PROCESS) (HANDLE, PBOOL);
...
...
LPFN_Wow64RevertWow64FsRedirection wowRevert = NULL;
LPFN_Wow64DisableWow64FsRedirection wowDisable = NULL;
HINSTANCE hLib;
if(GetProcAddresses( &hLib, "kernel32.dll", 2, &wowRevert,_
"Wow64RevertWow64FsRedirection", &wowDisable, Wow64DisableWow64FsRedirection" ))
{...
Code crashes here with:
The procedure entry point Wow64RevertWow64FsRedirection could not be located in the dynamic link library Kernel32.dll
It's easy enough to implement our own custom Wow64RevertWow64FsRedirection with non-WINAPI typedefs, but how can they be replaced with the base type when the function exists in kernel32.dll?
I'm having a bit of trouble understanding your question. The Wow64RevertWow64FsRedirection function is obviously not going to exist on a 32-bit operating system, so it won't exist on 32-bit Windows XP. Therefore, attempting to retrieve a pointer to this function with GetProcAddress will fail. You get the sensible error that this entry point could not be found. If the entry point cannot be found, the function does not exist and you should not attempt to call it.
You claim that you can implement your own custom Wow64RevertWow64FsRedirection function, but I haven't the foggiest idea why you would want to do this. If the operating system supports WOW64 file-system redirection, then it will provide the Wow64RevertWow64FsRedirection function. If it does not, then it does not provide the function, but you do not need such a function, because there is no such thing as WOW64 file-system redirection. You don't need to enable, disable, or revert it.
It seems that you are making this far more complicated than it needs to be. You don't even need to first verify that the process is a 64-bit process. You can just attempt to locate the entry point to Wow64RevertWow64FsRedirection (or Wow64DisableWow64FsRedirection, as needed), call it if it exists, or ignore the failure if it does not exist.
It is as simple as:
BOOL RevertWOW64RedirectionIfNecessary(PVOID pOldValue)
{
typedef BOOL (WINAPI * fnWow64RevertWow64FsRedirection)(PVOID);
fnWow64RevertWow64FsRedirection pfn =
reinterpret_cast<fnWow64RevertWow64FsRedirection>(
reinterpret_cast<void*>(
GetProcAddress(GetModuleHandle(L"kernel32"),
"Wow64RevertWow64FsRedirection")));
if (pfn)
{
// The function exists, so call it through the pointer we obtained.
return pfn(pOldValue);
}
else
{
// The function does not exist, so we can't call it.
// But we don't ever need to call it in such cases,
// so do nothing and feign success.
return TRUE;
}
}
Note that I am calling the GetModuleHandle function to retrieve a handle to the module kernel32.dll (the .dll extension is implied). I can use GetModuleHandle here instead of LoadModule because I know that kernel32.dll is guaranteed to always be loaded in any application's process. And since I've used GetModuleHandle, I don't need to free the module handle, either.
I pass the resulting handle to the GetProcAddress function, along with a string that contains the name of the function/procedure whose address is to be retrieved. This function attempts to retrieve the address of that function, and returns it if it exists; otherwise, it fails and returns NULL.
I check to see if it returned a valid pointer, and if so, I call the function dynamically through that pointer. Otherwise, it returned NULL, meaning that the function is not available, but in that case, we don't even need to worry about it, so the code just becomes a no-op.
As for the funny casting, see my answer here, which explains this trick.
I am thoroughly stumped on this one, can you please help.
I am trying to call the sqrt from a function with a Dll. When doing so I get the following error,
First-chance exception at 0x000082bc in DllTest.exe: 0xC0000005: Access violation.
The exception happens when the sqrt is called.
The code in my Dll is (contained in the header)
/////////////////////////////////////////////////////////////
#include <math.h>
//////////////////////////////////////////////////////////////
extern "C" __declspec(dllexport) float MyFunction (void)
{
float f(10.0f);
float r(sqrt(f));
return r;
}
///////////////////////////////////////////////////////////
Which is run from a command line application. (Contained in the cpp file)
#include "stdafx.h"
///////////////////////////////////////////////////////
typedef float (*MyDllFn)(void);
//////////////////////////////////////////////////////////////////////////
int _tmain(int argc, _TCHAR* argv[])
{
HMODULE module = LoadLibraryEx(_T("MyDll.dll"),
NULL,
DONT_RESOLVE_DLL_REFERENCES);
MyDllFn pMyDllFunction ((MyDllFn) GetProcAddress(module, "MyFunction"));
float sqrt10 = pMyDllFunction();
return 0;
}
I have tried moving the sqrt into the cpp file which made no difference. I am really not sure why this could be happening so any help is greatly appreciated.
You are not performing any error checking at all.
Quite possibly LoadLibraryEx fails and returns NULL. Then GetProcAddress fails and returns NULL. You then try to call a function at address NULL. Or perhaps LoadLibraryEx succeeds, but the call to GetProcAddress fails because you got the function name wrong. The function name looks right, but there is always the possibility of name mangling or decoration. Granted the way you have exported it means neither of those should happen. So I rather suspect that module is NULL.
The use of DONT_RESOLVE_DLL_REFERENCES puzzles me. I cannot imagine why you included that. The documentation says:
If this value is used, and the executable module is a DLL, the system
does not call DllMain for process and thread initialization and
termination. Also, the system does not load additional executable
modules that are referenced by the specified module.
Note Do not use this value; it is provided only for backward compatibility. If you are planning to access only data or resources in
the DLL, use LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE or
LOAD_LIBRARY_AS_IMAGE_RESOURCE or both. Otherwise, load the library as
a DLL or executable module using the LoadLibrary function.
That is as clear as can be. Do not use this value. In fact, you should just call LoadLibrary. You do not need the added functionality that LoadLibraryEx offers.
The fact that the error is raised in the DllTest.exe module indicates that you never make it into the DLL. And so I'm reasonably confident that one of my hypotheses above is accurate.
Add some error checking. The documentation for the functions that you call tell you how to do that. Specifically you will need to check the return values of the functions that you call. For both of these functions a return value of NULL indicates failure. And, for both of these functions, when they fail you can obtain an error code by calling GetLastError. But not all Win32 functions work that way so always read the documentation carefully and always check for errors.
You want code that looks like this:
HMODULE module = LoadLibrary(L"MyDll.dll");
if (module == NULL)
return GetLastError(); // or do some real error handling
MyDllFn pMyDllFunction = (MyDllFn)GetProcAddress(module, "MyFunction");
if (pMyDllFunction == NULL)
return GetLastError(); // or do some real error handling
float sqrt10 = pMyDllFunction();
I have 2 FARPROCs and I want to replace the address of one with the other using ASM.
What is a FARPROC? "[int (FAR WINAPI * FARPROC) () ] In C, the FARPROC declaration indicates a callback function that has an unspecified parameter list. In C++, however, the empty parameter list in the declaration indicates that a function has no parameters. This subtle distinction can break careless code. Following is one way to handle this situation:"
Now that that's covered, this is my code:
HMODULE h = LoadLibrary("myDLL.dll");
FARPROC p = GetProcAddress(h, "_GetHelloMessage#0");
if(!p) MessageBox(hwnd, "injected, but function not found", "Loader", NULL);
HMODULE dllHmodule = GetModuleHandle("InjectFunctions.dll");
FARPROC injproc = GetProcAddress(dllHmodule, "_GetHelloMessage#0");
if(!injproc) MessageBox(hwnd, "injproc is null", "Loader", NULL);
__asm{
mov eax, p
ADD injproc [EAX],8
}
My question is how do I make it so whenever the program that loaded this DLL calls p it will instead call injproc?
Each referenced function in an external DLL gets an entry in the Import Address Table in the executable file's header area. Part of that entry is the address of the function. That's what you patch to make the call go somewhere else. There should be plenty of examples on how to do this out on the open internet, though I don't happen to have a link handy.
If you want to do this on your own, download the Portable Executable specification from msdn to see what the format of those headers is.
Sample code that shows how to create threads using MFC declares the thread function as both static and __cdecl. Why is the latter required? Boost threads don't bother with this convention, so is it just an anachronism?
For example (MFC):
static __cdecl UINT MyFunc(LPVOID pParam)
{
...
}
CWinThread* pThread = AfxBeginThread(MyFunc, ...);
Whereas Boost:
static void func()
{
...
}
boost::thread t;
t.create(&func);
(the code samples might not be 100% correct as I am nowhere near an IDE).
What is the point of __cdecl? How does it help when creating threads?
__cdecl tells the compiler to use the C calling convention (as opposed to the stdcall, fastcall or whatever other calling convention your compiler supports). I believe, VC++ uses stdcall by default.
The calling convention affects things such as how arguments are pushed onto the stack (or registers, in the case of fastcall) and who pops arguments off the stack (caller or callee).
In the case of Boost. I believe it uses template specialization to figure out the appropriate function type and calling convention.
Look at the prototype for AfxBeginThread():
CWinThread* AfxBeginThread(
AFX_THREADPROC pfnThreadProc,
LPVOID pParam,
int nPriority = THREAD_PRIORITY_NORMAL,
UINT nStackSize = 0,
DWORD dwCreateFlags = 0,
LPSECURITY_ATTRIBUTES lpSecurityAttrs = NULL
);
AFX_THREADPROC is a typedef for UINT(AFX_CDECL*)(LPVOID). When you pass a function to AfxBeginThread(), it must match that prototype, including the calling convention.
The MSDN pages on __cdecl and __stdcall (as well as __fastcall and __thiscall) explain the pros and cons of each calling convention.
The boost::thread constructor uses templates to allow you to pass a function pointer or callable function object, so it doesn't have the same restrictions as MFC.
Because your thread is going to be called by a runtime function that manages this for you, and that function expects it to be that way. Boost designed it a different way.
Put a breakpoint at the start of your thread function and look at the stack when it gets called, you'll see the runtime function that calls you.
C/C++ compilers by default use the C calling convention (pushing rightmost param first on the stack) for it allows working with functions with variable argument number as printf.
The Pascal calling convention (aka "fastcall") pushes leftmost param first. This is quicker though costs you the possibility of easy variable argument functions (I read somewhere they're still possible, though you need to use some tricks).
Due to the speed resulting from using the Pascal convention, both Win32 and MacOS APIs by default use that calling convention, except in certain cases.
If that function has only one param, in theory using either calling convention would be legal, though the compiler may enforce the same calling convention is used to avoid any problem.
The boost libraries were designed with an eye on portability, so they should be agnostic as to which caller convention a particular compiler is using.
The real answer has to do with how windows internally calls the thread proc routine, and it is expecting the function to abide by a specific calling convention, which in this case is a macro, WINAPI, which according to my system is defined as:
#define WINAPI __stdcall
This means that the called function is responsible for cleaning up the stack. The reason why boost::thread is able to support arbitrary functions is that it passes a pointer to the function object used in the call to thread::create function to CreateThread. The threadproc associated with the thread simply calls operator() on the function object.
The reason MFC requires __cdecl therefore has to do with the way it internally calls the function passed in to the call to AfxBeginThread. There is no good reason to do this unless they were planning on allowing vararg parameters...
We recently attempted to break apart some of our Visual Studio projects into libraries, and everything seemed to compile and build fine in a test project with one of the library projects as a dependency. However, attempting to run the application gave us the following nasty run-time 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 pointer declared with a different calling convention.
We have never even specified calling conventions (__cdecl etc.) for our functions, leaving all the compiler switches on the default. I checked and the project settings are consistent for calling convention across the library and test projects.
Update: One of our devs changed the "Basic Runtime Checks" project setting from "Both (/RTC1, equiv. to /RTCsu)" to "Default" and the run-time vanished, leaving the program running apparently correctly. I do not trust this at all. Was this a proper solution, or a dangerous hack?
This debug error means that the stack pointer register is not returned to its original value after the function call, i.e. that the number of pushes before the function call were not followed by the equal number of pops after the call.
There are 2 reasons for this that I know (both with dynamically loaded libraries). #1 is what VC++ is describing in the error message, but I don't think this is the most often cause of the error (see #2).
1) Mismatched calling conventions:
The caller and the callee do not have a proper agreement on who is going to do what. For example, if you're calling a DLL function that is _stdcall, but you for some reason have it declared as a _cdecl (default in VC++) in your call. This would happen a lot if you're using different languages in different modules etc.
You would have to inspect the declaration of the offending function, and make sure it is not declared twice, and differently.
2) Mismatched types:
The caller and the callee are not compiled with the same types. For example, a common header defines the types in the API and has recently changed, and one module was recompiled, but the other was not--i.e. some types may have a different size in the caller and in the callee.
In that case, the caller pushes the arguments of one size, but the callee (if you're using _stdcall where the callee cleans the stack) pops the different size. The ESP is not, thus, returned to the correct value.
(Of course, these arguments, and others below them, would seem garbled in the called function, but sometimes you can survive that without a visible crash.)
If you have access to all the code, simply recompile it.
I read this in other forum
I was having the same problem, but I just FIXED it. I was getting the same error from the following code:
HMODULE hPowerFunctions = LoadLibrary("Powrprof.dll");
typedef bool (*tSetSuspendStateSig)(BOOL, BOOL, BOOL);
tSetSuspendState SetSuspendState = (tSuspendStateSig)GetProcAddress(hPowerfunctions, "SetSuspendState");
result = SetSuspendState(false, false, false); <---- This line was where the error popped up.
After some investigation, I changed one of the lines to:
typedef bool (WINAPI*tSetSuspendStateSig)(BOOL, BOOL, BOOL);
which solved the problem. If you take a look in the header file where SetSuspendState is found (powrprof.h, part of the SDK), you will see the function prototype is defined as:
BOOLEAN WINAPI SetSuspendState(BOOLEAN, BOOLEAN, BOOLEAN);
So you guys are having a similar problem. When you are calling a given function from a .dll, its signature is probably off. (In my case it was the missing WINAPI keyword).
Hope that helps any future people! :-)
Cheers.
Silencing the check is not the right solution. You have to figure out what is messed up with your calling conventions.
There are quite a few ways to change the calling convetion of a function without explicitly specifying it. extern "C" will do it, STDMETHODIMP/IFACEMETHODIMP will also do it, other macros might do it as well.
I believe if run your program under WinDBG (http://www.microsoft.com/whdc/devtools/debugging/default.mspx), the runtime should break at the point where you hit that problem. You can look at the call stack and figure out which function has the problem and then look at its definition and the declaration that the caller uses.
I saw this error when the code tried to call a function on an object that was not of the expected type.
So, class hierarchy: Parent with children: Child1 and Child2
Child1* pMyChild = 0;
...
pMyChild = pSomeClass->GetTheObj();// This call actually returned a Child2 object
pMyChild->SomeFunction(); // "...value of ESP..." error occurs here
I was getting similar error for AutoIt APIs which i was calling from VC++ program.
typedef long (*AU3_RunFn)(LPCWSTR, LPCWSTR);
However, when I changed the declaration which includes WINAPI, as suggested earlier in the thread, problem vanished.
Code without any error looks like:
typedef long (WINAPI *AU3_RunFn)(LPCWSTR, LPCWSTR);
AU3_RunFn _AU3_RunFn;
HINSTANCE hInstLibrary = LoadLibrary("AutoItX3.dll");
if (hInstLibrary)
{
_AU3_RunFn = (AU3_RunFn)GetProcAddress(hInstLibrary, "AU3_WinActivate");
if (_AU3_RunFn)
_AU3_RunFn(L"Untitled - Notepad",L"");
FreeLibrary(hInstLibrary);
}
It's worth pointing out that this can also be a Visual Studio bug.
I got this issue on VS2017, Win10 x64. At first it made sense, since I was doing weird things casting this to a derived type and wrapping it in a lambda. However, I reverted the code to a previous commit and still got the error, even though it wasn't there before.
I tried restarting and then rebuilding the project, and then the error went away.
I was getting this error calling a function in a DLL which was compiled with a pre-2005 version of Visual C++ from a newer version of VC (2008).
The function had this signature:
LONG WINAPI myFunc( time_t, SYSTEMTIME*, BOOL* );
The problem was that time_t's size is 32 bits in pre-2005 version, but 64 bits since VS2005 (is defined as _time64_t). The call of the function expects a 32 bit variable but gets a 64 bit variable when called from VC >= 2005. As parameters of functions are passed via the stack when using WINAPI calling convention, this corrupts the stack and generates the above mentioned error message ("Run-Time Check Failure #0 ...").
To fix this, it is possible to
#define _USE_32BIT_TIME_T
before including the header file of the DLL or -- better -- change the signature of the function in the header file depending on the VS version (pre-2005 versions don't know _time32_t!):
#if _MSC_VER >= 1400
LONG WINAPI myFunc( _time32_t, SYSTEMTIME*, BOOL* );
#else
LONG WINAPI myFunc( time_t, SYSTEMTIME*, BOOL* );
#endif
Note that you need to use _time32_t instead of time_t in the calling program, of course.
I was having this exact same error after moving functions to a dll and dynamically loading the dll with LoadLibrary and GetProcAddress. I had declared extern "C" for the function in the dll because of the decoration. So that changed calling convention to __cdecl as well. I was declaring function pointers to be __stdcall in the loading code. Once I changed the function pointer from __stdcall to__cdecl in the loading code the runtime error went away.
Are you creating static libs or DLLs? If DLLs, how are the exports defined; how are the import libraries created?
Are the prototypes for the functions in the libs exactly the same as the function declarations where the functions are defined?
do you have any typedef'd function prototypes (eg int (*fn)(int a, int b) )
if you dom you might be have gotten the prototype wrong.
ESP is an error on the calling of a function (can you tell which one in the debugger?) that has a mismatch in the parameters - ie the stack has restored back to the state it started in when you called the function.
You can also get this if you're loading C++ functions that need to be declared extern C - C uses cdecl, C++ uses stdcall calling convention by default (IIRC). Put some extern C wrappers around the imported function prototypes and you may fix it.
If you can run it in the debugger, you'll see the function immediatey. If not, you can set DrWtsn32 to create a minidump that you can load into windbg to see the callstack at the time of the error (you'll need symbols or a mapfile to see the function names though).
Another case where esp can get messed up is with an inadvertent buffer overflow, usually through mistaken use of pointers to work past the boundary of an array. Say you have some C function that looks like
int a, b[2];
Writing to b[3] will probably change a, and anywhere past that is likely to hose the saved esp on the stack.
You would get this error if the function is invoked with a calling convention other than the one it is compiled to.
Visual Studio uses a default calling convention setting thats decalred in the project's options. Check if this value is the same in the orignal project settings and in the new libraries. An over ambitious dev could have set this to _stdcall/pascal in the original since it reduces the code size compared to the default cdecl. So the base process would be using this setting and the new libraries get the default cdecl which causes the problem
Since you have said that you do not use any special calling conventions this seems to be a good probability.
Also do a diff on the headers to see if the declarations / files that the process sees are the same ones that the libraries are compiled with .
ps : Making the warning go away is BAAAD. the underlying error still persists.
This happened to me when accessing a COM object (Visual Studio 2010). I passed the GUID for another interface A for in my call to QueryInterface, but then I cast the retrieved pointer as interface B. This resulted in making a function call to one with an entirely signature, which accounts for the stack (and ESP) being messed up.
Passing the GUID for interface B fixed the problem.
In my MFC C++ app I am experiencing the same problem as reported in Weird MSC 8.0 error: “The value of ESP was not properly saved across a function call…”. The posting has over 42K views and 16 answers/comments none of which blamed the compiler as the problem. At least in my case I can show that the VS2015 compiler is at fault.
My dev and test setup is the following: I have 3 PCs all of which run Win10 version 10.0.10586. All are compiling with VS2015, but here is the difference. Two of the VS2015s have Update 2 while the other has Update 3 applied. The PC with Update 3 works, but the other two with Update 2 fail with the same error as reported in the posting above. My MFC C++ app code is exactly the same on all three PCs.
Conclusion: at least in my case for my app the compiler version (Update 2) contained a bug that broke my code. My app makes heavy use of std::packaged_task so I expect the problem was in that fairly new compiler code.
ESP is the stack pointer. So according to the compiler, your stack pointer is getting messed up. It is hard to say how (or if) this could be happening without seeing some code.
What is the smallest code segment you can get to reproduce this?
If you're using any callback functions with the Windows API, they must be declared using CALLBACK and/or WINAPI. That will apply appropriate decorations to make the compiler generate code that cleans the stack correctly. For example, on Microsoft's compiler it adds __stdcall.
Windows has always used the __stdcall convention as it leads to (slightly) smaller code, with the cleanup happening in the called function rather than at every call site. It's not compatible with varargs functions, though (because only the caller knows how many arguments they pushed).
Here's a stripped down C++ program that produces that error. Compiled using (Microsoft Visual Studio 2003) produces the above mentioned error.
#include "stdafx.h"
char* blah(char *a){
char p[1];
strcat(p, a);
return (char*)p;
}
int main(){
std::cout << blah("a");
std::cin.get();
}
ERROR:
"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 had this same problem here at work. I was updating some very old code that was calling a FARPROC function pointer. If you don't know, FARPROC's are function pointers with ZERO type safety. It's the C equivalent of a typdef'd function pointer, without the compiler type checking.
So for instance, say you have a function that takes 3 parameters. You point a FARPROC to it, and then call it with 4 parameters instead of 3. The extra parameter pushed extra garbage onto the stack, and when it pops off, ESP is now different than when it started. So I solved it by removing the extra parameter to the invocation of the FARPROC function call.
Not the best answer but I just recompiled my code from scratch (rebuild in VS) and then the problem went away.