911 URGENT HELP PLS: LoadLibrary EXE problem

problem: use LoadLibrary to load an EXE and call the EXE entry point manually - got access violation

description: when i call the entrypoint, the target exe program fails at line 199 of ...\crt\src\crtexe.c (c-runtime source code) with an access violation in ntdll.dll. i've attached the code segment i used below as well as the line of c-runtime code that failed... looking forward to your expert advice...

thanks so much!!!

peter

====== loadlibrary and calling entry point of exe =====

typedef DWORD (* INITPROC)();
...
char exe[] = "C:\\Documents and
Settings\\Administrator\\Desktop\\shareware\\test\\imghlptst\\exe.exe";
LOADED_IMAGE li;
if ( MapAndLoad( exe, 0, &li, FALSE, TRUE) )
{
DWORD p;
HMODULE hp = LoadLibrary(exe);
p = DWORD(hp);
p += li.FileHeader->OptionalHeader.AddressOfEntryPoint;
INITPROC proc = (INITPROC)p;
(*proc)();
...


============================================

====== c-runtime location that fails =================

#ifdef WPRFLAG
void wmainCRTStartup(
#else /* WPRFLAG */
void mainCRTStartup(
#endif /* WPRFLAG */

#endif /* _WINMAIN_ */
void
)
{
int argc; /* three standard arguments to main */
_TSCHAR **argv;
_TSCHAR **envp;

int mainret;

#ifdef _WINMAIN_
_TUCHAR *lpszCommandLine;
STARTUPINFO StartupInfo;
#endif /* _WINMAIN_ */

_startupinfo startinfo;
. . .
__try {
/*
* Set __app_type properly
*/
#ifdef _WINMAIN_
__set_app_type(_GUI_APP);// <----------------- FAILED
#else /* _WINMAIN_ */
__set_app_type(_CONSOLE_APP);
#endif /* _WINMAIN_ */



================================

thanks!!!
peter

Hi,
To run a process, they want you to use CreateProcess(). To call an exported function from a module, they want you to use LoadLibrary and then GetProcAddress(). If you just want to run a program, then use CreateProcess(). If you just want to execute an exported function, then use LoadLibrary followed by GetProcAddress().
You can use the utility dumpbin [it comes with Visual C++] to show the exports of a dll or exe:
dumpbin /exports somemodule.dll
--Paul

thanks paul, i know what you mean... but i am trying to run a EXE from the context of another EXE... that's why i am not using createprocess..

thanks!

that if you wish to run an *.exe from another, DO NOT use LoadLibrary. Use CreateProcess()

Other than the double-load bug in the sample code, there's a fundemental misunderstanding of what happens when a PE file is loaded and what happens when MapAndLoad is called.

The short answer to this problem as people have pointed out is that you can't. But here's why you can't:

PE executables are not designed to relocation. Most load on the 4MB boundary, but it does depend on where they've been told to locate themselves.

The purpose of calling CreateProcess is to create a new Virtual Address Space for the exe. Therefore as it has the whole of memory available (virtually speaking) it can load where the hell it wants.

DLLs on the other hand are intended to relocate, therefore the process of calling LoadLibrary and GetAddress will work fine for those types of solution.

If you wanted to load an exe into another exe's address space you have very view options. (1) You have to go through the loaded code and relocate all the addresses (not my idea of fun) or (2) Locate the load exe in a different part of memory so not to clash with the load and then use a Mapping function other than MapAndLoad so that you can force it to load into the correct place.

If you'd looked at the disassembly of your test program in the debugger you'd have got a good hint as to the problem as all the addresses would look wrong as your base would be above 4MB compared to those in the loaded exe.

In fact, one optimization that I've seen exe packing compressors do in Win32 is to strip the relocation block from an exe as its not used.

Whatever way you choose to solve this, it's a heck of a lot of work. Far better to rethink the strategy of what you're going.

MapAndLoad seems to be publically posted source, and from this code you can see it does nothing regarding address fix-up. It's also critical to call UnMapAndLoad when you're done as it maintains a set of handles.

And finally, having said all this, if you choose to fight the great fight. Publish the solution, as it'll be interesting to see how difficult/hard it was to do the relocation and fix-ups.