Ggtcf

I have this simple program:

#include <windows.h>
int WINAPI startMeUp() 
 return 0;

which I compile using the command line tools of Visual Studio like so:

cl /nologo /GS- /Gs- /c /W4 main.c /Fomain.obj
link /nologo main.obj /subsystem:console /entry:startMeUp /nodefaultlib kernel32.lib user32.lib /OUT:the.exe

When I then execute .the.exe, a message box is shown that says the.exe has stopped working - A problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available

After replacing the return 0; with ExitProcess(0); and re-compiling/linking it, .the.exe runs just fine.

So, it seems to me that ExitProcess() is needed to correctly end a process.

Since I am pretty sure that I already had working programs that returned from the entry-point function by returning an exit value, I am not sure if portable executables require a process to be terminated by ExitProcess().

Edit
Interestingly, if I place a MessageBox(NULL, "world", "hello", 0); before the return 0; (and thus don't have an ExitProcess() call), the executable also runs ok.

Edit II
When I add the linker option /export:startMeUp, the linker warns me with LNK4216 but I can execute the created without problem.

When I use dumpbin /all on both exes created, I see that the faulty executable has

 0 [ 0] RVA [size] of Export Directory

while the new, working one has

2000 [ 40] RVA [size] of Export Directory

Also, the working executable consists of two sections: .text and .rdata while the faulty one only has the .text section. The executable code seems to be included in the .rdata section, thus it is missing in the faulty one.

As to why that is, I have no clue.

windows process exit or when last thread in process exit or when TerminateProcess called. because can be additional (implicitly created) threads in your process - you need call TerminateProcess (or ZwTerminateProcess) direct or indirect.

the ExitProcess internally call TerminateProcess (ok really ZwTerminateProcess), but before this do some job, for correct process shutdown. including calling all DLLs entry points with DLL_PROCESS_DETACH notification

so in general you must call ExitProcess (more correct) or TerminateProcess

in case you write entrypoint yourself, the correct signature must be

int WINAPI startMeUp(void*)

this is stdcall function which take 1 param (pointer to PEB). when you return from this api to system - just RtlExitUserThread called, which cause to thread exit or all process exit if this is last thread in process. even desite on x86 system stack pointer is incorrect after your return from startMeUp this not lead to error because just RtlExitUserThread and it never return. hard say what lead to crash in your test without view your binary file, but faster need look(debug) on your concrete system. but this is unusual - this must not be. your process must or just exit or still live (infinite or some time) in background in additional thread in process exist

Yes, ExitProcess is required, or you will eventually throw an exception because there is nowhere to go and you cannot stop the processor.

However, the entry is not usually user- provided, it is provided by the CRT (WinMainCRTStartup) which also initializes global variables before calling WinMain() function.

Therefore, all you need to do is to provide a WinMain.

Edit after your edit: ExitProcess might be called by some exception handler which is created after MessageBox call. You do not (and cannot) know.