C / C++ / MFC

25-Mar-06 3:49

#include "stdafx.h"
#include <windows.h>

int _tmain()
{

HANDLE hProcess;
DWORD Address;
hProcess = OpenProcess(PROCESS_ALL_ACCESS, TRUE, (DWORD)6E8);
if (hProcess == NULL)
{
printf("Main - hProcess Error.");
CloseHandle(hProcess);
return 0;
}

Address == VirtualAllocEx(
hProcess,
NULL,
sizeof("C:\\mydll.dll"),
MEM_COMMIT,
PAGE_EXECUTE_READWRITE);

if(Address == NULL)
{
printf("Main - VirtualAllocEx Error(return NULL).");
CloseHandle(hProcess);
return 0;
}

printf("Address: x%", Address);
if(WriteProcessMemory(hProcess,
(PVOID)Address,
"C:\\mydll.dll",
sizeof("C:\\mydll.dll"),
NULL) == NULL)
{
printf("Main - WriteProcessMemory Error (return NULL).");
CloseHandle(hProcess);
return 0;
}

CreateRemoteThread(hProcess
, NULL
, 0
, (LPTHREAD_START_ROUTINE)GetProcAddress(GetModuleHandle(TEXT("kernel32")), "LoadLibraryA")
, (LPVOID)Address
, 0
, NULL);
CloseHandle(hProcess);

return 0;
}

---------------end----------------
I get this error:
error C3861: 'VirtualAllocEx': identifier not found, even with argument-dependent lookup
warning C4312: 'type cast' : conversion from 'DWORD' to 'PVOID' of greater size
warning C4312: 'type cast' : conversion from 'DWORD' to 'LPVOID' of greater size

thx

thx

Justin Tay25-Mar-06 4:43

Justin Tay

25-Mar-06 4:43

Did you install the latest Platform SDK? VirtualAllocEx should be defined in winbase.h which is included by windows.h.

DWORD Address;
to
LPVOID Address;

Address == VirtualAllocEx(
to
Address = VirtualAllocEx(

Glich25-Mar-06 4:50

25-Mar-06 4:50

Thx for your replay. I got rid of the two warnings but am still stuck with the error (error C3861: 'VirtualAllocEx': identifier not found, even with argument-dependent lookup). I have vertion Microsoft Visual C++ .NET. Eny more advice??? please??? thx Glich

Nemanja Trifunovic25-Mar-06 5:18

Nemanja Trifunovic

25-Mar-06 5:18

From MSDN:

Requires Windows Vista, Windows XP, Windows 2000 Professional, or Windows NT Workstation 4.0.
Server Requires Windows Server "Longhorn", Windows Server 2003, Windows 2000 Server, or Windows NT Server 4.0

That means you need to set WINVER macro to a version that would include VirtualAllocEx declaration.

My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.

Glich25-Mar-06 5:50

25-Mar-06 5:50

Thx for your help.
I have tryed it with: "#define WINVER 0x0400" as http://msdn2.microsoft.com/en-us/library/6sehtctf.aspx
suggests but there is no diference. these are my command line options: "/D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_MBCS" /Gm /EHsc /RTC1 /MLd /Yu"stdafx.h" /Fp"Debug/InjProg.pch" /Fo"Debug/" /Fd"Debug/vc70.pdb" /W3 /nologo /c /Wp64 /ZI /TP" and these are my linker command line options: "/OUT:"Debug/InjProg.exe" /INCREMENTAL /NOLOGO /DEBUG /PDB:"Debug/InjProg.pdb" /SUBSYSTEM:CONSOLE /MACHINE:X86 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib"

eny help to help me? Smile | :)

thx!

Nemanja Trifunovic25-Mar-06 6:20

Nemanja Trifunovic

25-Mar-06 6:20

glich wrote:
I have tryed it with: "#define WINVER 0x0400"

Where did you put this definition? It must be defined before windows.h is included. If you use precompiled headers, it is best to put it at the top of stdafx.h. Or just add it to the Project settings.

My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.

Glich25-Mar-06 6:55

25-Mar-06 6:55

Thx for your replay.
It still does not work even after I placed the line "#define WINVER 0x0400" as the first line.

More help is needed if posible. Thx again.

how to check thread is running or not

PJ Arends25-Mar-06 9:43

PJ Arends

25-Mar-06 9:43

Actually, it _WIN32_WINNT that has to be 0x0400. WINVER 0x0400 is the code for windows 95.

#define _WIN32_WINNT 0x0400

You may be right
I may be crazy
-- Billy Joel --

Within you lies the power for good - Use it!

dafs

pravin parmar25-Mar-06 1:38

pravin parmar

25-Mar-06 1:38

adfasdf

Pravin Parmar,
PravinParmar.ce@gmail.com

baldha rakesh25-Mar-06 0:18

baldha rakesh

25-Mar-06 0:18

i want to check thread is running state or not and if it is running then terminate this thread and start another thread.

anybody have idea about this please share with me:its urgent

Bankey Khandelwal
Software Engineer

Justin Tay25-Mar-06 0:35

Justin Tay

25-Mar-06 0:35

To check if thread is still running

<br />
bool IsThreadRunning(HANDLE hThread)<br />
{<br />
  DWORD dwExitCode;<br />
  ::GetExitCodeThread(hThread, &dwExitCode);<br />
  return (dwExitCode == STILL_ACTIVE)? true : false;<br />
}<br />

Don't try to terminate the thread using TerminateThread(), either have a flag or event that the thread checks to see if it should terminate gracefully. Frankly I think it's better to reuse the thread...

Stephen Hewitt25-Mar-06 1:10

Stephen Hewitt

25-Mar-06 1:10

To tell if a thread is running or not:

DWORD dwState = WaitForSingleObject(hThread, 0);
switch(dwState)
{
case WAIT_TIMEOUT:
     // Thread running.
     break;
case WAIT_OBJECT_0:
     // Thread has exited.
     break;
}

The solution using the GetExitCodeThread API has a flaw. From MSDN:
"Warning: If a thread happens to return STILL_ACTIVE (259) as an error code, applications that test for this value could end up in an infinite loop."

In general there is no safe way to forcefully terminate a thread (although this doesn't seem to stop people from doing it) - Doing so, by calling TerminateThread for example, can put the process into an unstable state. One way this happens is as follows:
1. The thread about to be terminated calls an API which enters a critical section by calling EnterCriticalSection.
2. It is terminated before it can call LeaveCriticalSection.
3. Another thread calls the same API and it deadlocks: This API is now broken and any thread calling it will now deadlock.
This really happens and I can tell you from experience that tracking down the problem is not pleasant.

The general solution to this problem is to program the thread so you can arrange for it to exit, typically by signaling an event and then waiting for it to terminate.

Steve

Justin Tay25-Mar-06 1:42

Justin Tay

25-Mar-06 1:42

Ah. I've never noticed that little caveat since I don't usually return anything other than 0 for my threads. Guess you learn something new everyday...

ThatsAlok25-Mar-06 6:04

ThatsAlok

25-Mar-06 6:04

hfry wrote:
I don't usually return anything other than 0 for my threads

Returning ZERO signals thats your thread is successfully closed

Stephen Hewitt26-Mar-06 12:20

Stephen Hewitt

26-Mar-06 12:20

ThatsAlok wrote:
Returning ZERO signals thats your thread is successfully closed

This need not be the case: The programmer is free to place whatever interpretation on the exit code of a thread that is appropriate for his application. 0 for success is simply the most popular. For example you could use the return code to return the result of a computation.

Steve