What is invoke_main and mainCRTStartup? - c++

I have a CUI based and GUI based application that is written with CPP language. GUI based application has the following code:
#include <Windows.h>
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)
{
const TCHAR* title = TEXT("پیام");
const TCHAR* text = TEXT("سلام، من یک پنجره هستم.");
MessageBox(NULL, text, title, MB_OKCANCEL | MB_ICONINFORMATION);
return 0;
}
and CUI based program has the following code:
#include <Windows.h>
#include <iostream>
int main(int argc, const char* argv)
{
const char* cMessage = "Native Windows Development.\n";
WriteConsole(GetStdHandle(STD_OUTPUT_HANDLE), cMessage, strlen(cMessage), NULL, NULL);
return 0;
}
However, when I debug these programs in WinDBG, I have seen before main and WinMain function, a lot of other functions like mainCRTStartup and invoke_main for CUI based app and WinMainCRTStartup and invoke_main for GUI based app have called.
What are these functions and what they did before executing the main? and also how can I get more information about these two function?

With VS tool, we could see the call stack below:
And if you double-click on each call of the stack, you could see what it did in the code(as comments, the source code was located at ..\VC\Tools\MSVC\14.24.28314\crt\src\vcruntime).
First wWinMainCRTStartup is just to call function __scrt_common_main:
extern "C" int wWinMainCRTStartup()
{
return __scrt_common_main();
}
In __scrt_common_main, the comments contains the detals:
// This is the common main implementation to which all of the CRT main functions
// delegate (for executables; DLLs are handled separately).
static __forceinline int __cdecl __scrt_common_main()
{
// The /GS security cookie must be initialized before any exception handling
// targeting the current image is registered. No function using exception
// handling can be called in the current image until after this call:
__security_init_cookie();
return __scrt_common_main_seh();
}
The function is the common main implementation to which all of the CRT
main functions delegate (for executables; DLLs are handled
separately) and __security_init_cookie is to initialize /GS security cookie
before any exception handling for current image.
Then, it was the __scrt_common_main_seh:
initialize crt, acquire startup lock, check the current native startup state, release startup lock, invoke the dynamically initialized __declspec(thread) variables, register the callback function for thread-local destructors.
After complete the Initialization, call invoke_main, as the name, it invoke main/wWinMain.
static int __cdecl invoke_main()
{
return wWinMain(
reinterpret_cast<HINSTANCE>(&__ImageBase),
nullptr,
_get_wide_winmain_command_line(),
__scrt_get_show_window_mode());
}

Related

How can I change the entry point procedure from "WinMain" to "main" or any custom function?

I have read a lot about how to change the WinMain entry point procedure, some say you can change the entry point from the linker and some others say you can put the WinMain into DLL (dllMain) and so on.
Honestly, I am confused. I believe that there are one or more ways to change the entry point procedure to a custom procedure because there are some examples like MFC don't have a direct WinMain function and the Qt framework also has a custom entry point procedure it's similar to the console application main function int main(int argc, char *argv[]), so, there are ways as I expected.
I want a whatever way to replace/change the entry point procedure for GUI application on Windows from the traditional procedural WinMain to int main(int argc, char *argv[]) like Qt or even any other custom function but it must be compatible with (MS, GCC, Clang) compilers.
///////////Windows main/////////////
int WINAPI WinMain(HINSTANCE hInst, HINSTANCE hPrevInst, LPSTR cmdParam, int cmdShow){
}
///////////Console main and Qt framework////////////
int main(int argc, char *argv[]) {
}
//////////MFC////////////
class CMyFrame : public CFrameWnd {
public:
CMyFrame() {}
};
class CExample : public CWinApp {
BOOL InitInstance() {}
};
CExample theApp;
How do I do that?
entry point of exe can by any function with signature
ULONG CALLBACK ep(void* )
possible and use ULONG CALLBACK ep() - despite on x86 will be wrong stack pointer (esp) after return, this not lead to error, because windows just call ExitThread after entry return, if it return control at all - usually it call ExitProcess instead return.
the name of this entry point of course not play any role at all - it can be any valid c/c++ name. entry point found/called not by name but by AddressOfEntryPoint offset from IMAGE_OPTIONAL_HEADER
but when we build PE - we need tell linker name of this function, for it can set AddressOfEntryPoint, but this info (name of function) used only during build process (not used in runtime)
different linkers of course have different options for do this, link.exe have option /ENTRY. this option is optional and by default, the starting address is a function name from the C run-time library.
if /ENTRY:MyEntry explicitly stated - it used as is - MyEntry will be used as entry point. if no /ENTRY option set - used default:
if /SUBSYSTEM:CONSOLE set - used mainCRTStartup or if it not found wmainCRTStartup
if /SUBSYSTEM:WINDOWS set - used WinMainCRTStartup or if it not found wWinMainCRTStartup
but in most case c/c++ developers use CRT libraries. regardless of whether static or dynamic linking used with CRT - some lib code always statically linked with your exe and this code containing function which you used as entry point. for ms windows crt - this is mainCRTStartup or wmainCRTStartup (for console apps), WinMainCRTStartup or wWinMainCRTStartup for gui apps.
in all this 4 functions - called hardcoded function by name
mainCRTStartup call main
wmainCRTStartup call wmain
WinMainCRTStartup call WinMain
wWinMainCRTStartup call wWinMain
of course called function must be implemented somewhere in your code or in another lib code. for example if you use MFC - it implement wWinMain by self and called your code in another way ( via calling virtual functions on object which you override - InitApplication and InitInstance)
if back to question how change name of your custom entry point - but for what ? you really not need change name. you need only understand how your entry point is called. if you understand this - you can do almost all.
assume we want use main as "entry point". i take this in quotes because we really want have real entry point in CRT code and we want that CRT code call exactly main function.
possible ? simply !
set /ENTRY: mainCRTStartup linker option. so mainCRTStartup will be real entry point and it call main.
another question, i personally think that this is senseless trick, which nothing change and nothing give
also possible simply call main from WinMain
typedef struct
{
int newmode;
} _startupinfo;
/*
* new mode flag -- when set, makes malloc() behave like new()
*/
EXTERN_C _CRTIMP int __cdecl _query_new_mode( );
EXTERN_C _CRTIMP int __cdecl _set_new_mode( _In_ int _NewMode);
EXTERN_C
_CRTIMP int __cdecl __getmainargs(__out int * _Argc,
__deref_out_ecount(*_Argc) char *** _Argv,
__deref_out_opt char *** _Env,
__in int _DoWildCard,
__in _startupinfo * _StartInfo);
int __cdecl main(__in int _Argc, __in_ecount_z(_Argc) char ** _Argv, ...);
int CALLBACK WinMain( _In_ HINSTANCE , _In_opt_ HINSTANCE , _In_ LPSTR , _In_ int )
{
int _Argc, r;
char ** _Argv;
char ** _Env;
_startupinfo _StartInfo { _query_new_mode( ) };
if (!(r = __getmainargs(&_Argc, &_Argv, &_Env, 0, &_StartInfo)))
{
r = main(_Argc, _Argv, _Env);
if (_Argv) free(_Argv);
}
return r;
}
it must be compatible with (MS, GCC, Clang) compilers
How you do that depends on your compiler. Most of them will have some flags to choose which "subsystem" (the Windows term) you are targeting and even customize the entry point manually.
Put another way, there is no standard way of doing so because this is outside the scope of the C++ standard.
Having said that, some compilers provide the means to emulate the flags of other compilers. For instance, Clang can imitate Microsoft's.

Segmentation fault trying to execute a MinGW compiled C++ winapi test program

I have trouble executing some winapi code. I don't know if the reason is because I missed something in the compilation process or if the test program is wrong; but when I execute the program the Bitmap defintion line is giving a segfault.
here is the test program
#include <windows.h>
#include <gdiplus.h>
int WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)
{
Gdiplus::PixelFormat* pf = new Gdiplus::PixelFormat();
Gdiplus::Bitmap* bitmap = new Gdiplus::Bitmap(100, 100, *pf);
return 0;
}
and here is the compilation instruction :
> mingw32-g++ main.cpp -lgdiplus -o main.exe
When I execute, I have this throw :
Program received signal SIGSEGV, Segmentation fault.
0x00403da3 in Gdiplus::Image::Image (this=0x0, image=0x0, status=Gdiplus::Ok) at c:/mingw/include/gdiplus/gdiplusheaders.h:142
142 nativeImage(image), lastStatus(status) {}
I did some winapi tutorial and created a window before so I think my MinGW installation has nothing wrong.
What could be the problem ?
The error is because GDI+ is not being initialized. You could simply call Gdiplus::GdiplusStartup at the top of main and Gdiplus::GdiplusShutdown at the end, but by wrapping it in a class we get to take advantage of RAII and automate the initialization and release with less muss and fuss should anything go wrong.
#include <stdexcept>
#include <windows.h>
#include <gdiplus.h>
#include <stdio.h>
// GDI+ wrapper class
class GdiplusRAII
{
ULONG_PTR gdiplusToken;
public:
GdiplusRAII()
{
Gdiplus::GdiplusStartupInput input;
Gdiplus::Status status = Gdiplus::GdiplusStartup(&gdiplusToken, &input, NULL);
if (status != Gdiplus::Ok)
{
throw std::runtime_error("Could not initialize GDI+");
}
}
~GdiplusRAII()
{
Gdiplus::GdiplusShutdown(gdiplusToken);
}
};
int WinMain(HINSTANCE ,
HINSTANCE ,
LPSTR ,
int ) // not using the parameters so I left them out.
{
GdiplusRAII raii; // initialize GDI+
// no need to new a PixelFormat. It is just an int associated with a
// collection of defined constants. I'm going to pick one that sounds
// reasonable to minimize the potential for a nasty surprise and use it
// directly in the Gdiplus::Bitmap constructor call.
// Probably no need to new the bitmap. In fact you'll find that most of
// the time it is better to not new at all.
Gdiplus::Bitmap bitmap(100, 100, PixelFormat32bppARGB);
return 0;
// GDI+ will be shutdown when raii goes out of scope and its destructor runs.
}
Documentation on PixelFormat.

C++ - How to find source of heap / stack corruption on program exit

I have a project which causes two assertion failures in succession, AFTER the 'main'-function is completed. This is very problematic because it doesn't show me the piece of code causing the problem.
I was able to narrow the problem down somewhat. With an empty main-function:
int main(int argc,char* argv[])
{
return 0;
}
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nShowCmd)
{
return main(__argc,__argv);
}
everything is working just fine. However as soon as I use any class or function from a specific dll (which is part of the project), the problem starts occurring:
int main(int argc,char* argv[])
{
Color col(255,0,0,255);
col.r += 1;
int r = HeapValidate(GetProcessHeap(),0,nullptr);
std::cout<<r<<std::endl;
return 0;
}
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nShowCmd)
{
return main(__argc,__argv);
}
the 'Color' class is part of that dll, but it's not the cause of the issue. 'HeapValidate' returns 1, which means the heap is valid according to the documentation.
The dll in question contains hundreds of thousands lines of code, which makes debugging even more difficult.
On a similar question, I found the suggestion to use WinDBG, but I'm not sure what to do with the result:
http://pastebin.com/zV27b51Z
It confirms that the issue is some sort of memory corruption, but I still don't know where it originates from.
Is there any way to reliably find the origin, or am I stuck using trial and error?
My OS is Windows 8.1, I'm using Visual Studio 2013.
Run the application under debugger and press Retry button in assertion messagebox. DebugBreak will be called and the debugger will take coltrol.

VC++ project, how to define DLL missing error messages?

So the idea is when the user haven't installed DirectX End-User Runtime the program to show message like "DirectX Runtime missing! Download it from here", instead of the windows loader error (eg.: "d3dx9_43.dll is missing!"). So I find a very funky solution of the problem as I used a delay loaded DLL's and an DLL check before any function defined in the module is invoked using LoadLibrary. If the dll is missing the program shows a user-defined dialog box and exits, otherwise it calls FreeLibrary with the HMODULE returned by LoadLibrary and continues executing. This is implemented as a function like follows:
bool CheckResourcesAvailability() //Mainly check for the existence of delay loaded DLL's
{
HMODULE hMod; //Resourse handle
if((hMod = LoadLibraryEx(_T("d3d9.dll"), NULL, LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE)) == NULL)
{
DialogBox(hProgramInstance, MAKEINTRESOURCE(IDD_DX_RE), 0, (DLGPROC)&DxRedistMissingDlg);
return false;
}
FreeLibrary(hMod);
if((hMod = LoadLibraryEx(_T("D3DX9_43.dll"), NULL, LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE)) == NULL)
{
DialogBox(hProgramInstance, MAKEINTRESOURCE(IDD_DX_RE), 0, (DLGPROC)&DxRedistMissingDlg);
return false;
}
FreeLibrary(hMod);
return true;
}
*As DxRedistMissingDlg and MAKEINTRESOURCE(IDD_DX_RE) creates the user-defined error message dialog.
And In WinMain it's called as follows:
int WINAPI WinMain(HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPSTR lpCmdLine,
int nCmdShow)
{
hProgramInstance = hInstance;
#ifndef _DEBUG
SetErrorMode(SEM_FAILCRITICALERRORS); //Don't display windows error messages
#endif
//Check for missing delay - loaded dependencies and inform the user
if(!CheckResourcesAvailability())
return -1;
//Some other code.........
}
But I don't think this is the cleanest way to do it. First we aren't sure that d3dx9.lib really inherits from D3DX9_43.dll (I know that because I used IDA PRO) and also the LoadLibrary function is called twice - one time at the CheckResourcesAvailability() function and second when the DLL is delay-loaded. Any ideas for a better implementation?
Use delay load hooks to let the delay loader notify you whenever a given DLL or a specific exported function is missing. Not only does that tell you which DLL/function is missing, but also lets you specify a substitute DLL/function if desired.

Create a DLL that can be run

Windows has an utility called rundll32.exe that can execute native dynamic link libraries as applications.
Say I have a piece of code that prints "Hello World!" to the console. Is it possible to write a library in C++ (preferably Visual C++) that can be executed using rundll32.exe and will run this code? If so, how?
Googling "rundll32", the 3rd hit was a link to documentation,
http://support.microsoft.com/kb/164787
According to that documentation, rundll32 calls a user-specified function with signature like wWinMain (except the first argument here is a window handle instead of an instance handle),
void CALLBACK
EntryPoint(HWND hwnd, HINSTANCE hinst, LPSTR lpszCmdLine, int nCmdShow);
So, trying this out:
// File [foo.def]
EXPORTS
sayHello
// File [foo.cpp]
#include <iostream>
namespace myCode {
void sayHello()
{
using namespace std;
cout << "Hello, world!" << endl;
}
} // namespace myCode
#undef UNICODE
#define UNICODE
#include <windows.h>
extern "C"
__declspec( dllexport )
void CALLBACK sayHello( HWND, HINSTANCE, wchar_t const*, int )
{
AllocConsole();
freopen( "CONIN$", "r", stdin );
freopen( "CONOUT$", "w", stdout );
freopen( "CONOUT$", "w", stderr );
DWORD const infoBoxOptions = MB_ICONINFORMATION | MB_SETFOREGROUND;
MessageBox( 0, L"Before call...", L"DLL message:", infoBoxOptions );
myCode::sayHello();
MessageBox( 0, L"After call...", L"DLL message:", infoBoxOptions );
}
Building & running:
[d:\dev\test]
> cl foo.cpp foo.def user32.lib /MD /LD /D _CRT_SECURE_NO_WARNINGS
foo.cpp
Creating library foo.lib and object foo.exp
[d:\dev\test]
> rundll32 foo.dll,sayHello
[d:\dev\test]
> _
The output is presented in its own console window, created via AllocConsole, which is generally necessary since rundll32 is a GUI subsystem program (this is also the reason for the freopen calls).
To present the output in an existing console window one can just omit the calls to AllocConsole and freopen, and redirect standard output of rundll32 to a pipe. E.g. standard output can be piped through Windows’ more when the output is just a few lines, or through some *nix-utility cat for more lines. However, in the standard command interpreter [cmd.exe] it doesn’t work to just redirect the output to con.
http://support.microsoft.com/kb/164787
This MSDN article I believe is still accurate; you define an entrypoint as
void CALLBACK EntryPoint(HWND hwnd, HINSTANCE hinst, LPSTR lpszCmdLine, int nCmdShow);
While it is possible to use rundll32 to run a properly-designed function in a DLL, it is not recommended. Doing so means that your DLL is at the mercy of rundll32's process settings (large address awareness, terminal service awareness, DPI awareness, elevation manifest, etc.) Even worse: If some other rundll32 process triggers an application compatibility behavior (such as low fragmentation heap), then that will affect all rundll32 processes including yours.
Just write a separate EXE.
Like said by Joe and yourself, use something like this:
void CALLBACK func(HWND hwnd, HINSTANCE hinst, LPSTR lpszCmdLine, int nCmdShow)
{
std::cout << "Hello world!" << std::endl;
}
However, CALLBACK = __stdcall, which, when your "func" is exported will changed to _func#16
You could change this name, http://support.microsoft.com/kb/140485
so, you might want to try something similar to this:
rundll32.exe DLLTest.dll,_func#16