Use WaitForSingleObject(hProcess, ...)

Use global or class variables to determine if message is already on screen. I guess I solve your problem? :~

If you're programming with MFC use SetIcon() in your Main Frame class:

int CMainFrame::OnCreate(LPCREATESTRUCT lpCreateStruct)
{
...
HICON hIcon = LoadIcon(AfxGetInstanceHandle(), MAKEINTRESOURCE(IDR_SITYPE));
SetIcon(hIcon, false);
...
}

If I understood you right, you need a program that reads bad or damaged disks. BadCopy can read whole disk and replace damaged sectors with random data. So when you will play this video you'll see some artifacts, but this isn't critical if disk has a few damaged sectors. Video from the screen can be captured by SnagIt or Corel Capture,.. not sure about second program

It is internal compiler error, try to 'Rebuilt All' it may help. Here someone has the same problem.

Hi Everyone! It is sad, that visual studio 2005 class designer doesn't support C++ projects and now I'm looking for visual studio addon or whole program that can replace this inexcusable omission :) Please help me.

I suppose that this error isn't generated by your application, it's an error from windows loader, the whole executable is damaged. If you can post this file somewhere, maybe I can help. PS Check your linker options, the problem suppose to be here.

Looks like that this is bug in visual studio debugger This strange symbols are nothing else than the pointer to the "cool" string in your resource section(.rdata usually) of executable. In debugger window you see destination buffer address decremented by 4 bytes. I don't know why this happens, but I think that this is bug.

HOW WHAT wrote:

1.Your method if had some call hooked function may be happen some exception, right?

Only when application threads are not synchronized and context of current thread(that now hooking function) is switched to other that calls hooked function.

HOW WHAT wrote:

2. How to do like you say

There is an error in code you just downloaded. Armadillo protector uses the same technique and it works best on Windows 9x\Me Give me the URL of this example or send it to my mail - sharebyte gmail com

My method is better to use, because it never fail, except when application detected and removed hook(very very rarely), but it creates additional problems with synchronization in mt applications and it doesn't work on windows other than 32 bit(without modification). IAT modification is also good method, but this hook wouldn't work if application directly calls functions(call GetProcAddress to retrieve address of function...). Second method fails more offen than first. Also you can create a dll that debugs process in which it injected by inserting int3 instructions into functions you want to hook. If number of functions to hook =< 4 you can use hardware breakpoints, setting hardware breakpoints do not require any code modifications.

NetUserEnum The NetUserEnum function provides information about all user accounts on a server.

This example shows the hook of GetModuleHandleW in target process(process where you injected your dll). It works only in 32-bit windows. If you injected your dll into multithreaded process you must synchronize execution of this code with other threads or program sometimes may crash. #define BYTES_COUNT 0x05 BYTE firstBytes[BYTES_COUNT]; void *pfnGetModuleHandle; HANDLE __stdcall Handler(HANDLE hModule); // Only running process hook BOOL HookGetModuleHandle() { HANDLE hKernel32; DWORD dwOldProtect; hKernel32 = LoadLibrary(_T("kernel32.dll")); pfnGetModuleHandle = GetProcAddress((HMODULE)hKernel32, "GetModuleHandleW"); if (hKernel32 == NULL || pfnGetModuleHandle == NULL) { return FALSE; } memcpy(&firstBytes, pfnGetModuleHandle, BYTES_COUNT); if (!VirtualProtect(pfnGetModuleHandle, BYTES_COUNT, PAGE_READWRITE, &dwOldProtect)) { return FALSE; } *((BYTE*)pfnGetModuleHandle) = 0xE9; *((DWORD*)(((BYTE*)pfnGetModuleHandle)+1)) = (DWORD)Handler - (DWORD)pfnGetModuleHandle - BYTES_COUNT; if (!VirtualProtect(pfnGetModuleHandle, BYTES_COUNT, dwOldProtect, NULL)) { return FALSE; } return TRUE; } BOOL UnhookGetModuleHandle() { DWORD dwOldProtect; if (!VirtualProtect(pfnGetModuleHandle, BYTES_COUNT, PAGE_READWRITE, &dwOldProtect)) { return FALSE; } memcpy(pfnGetModuleHandle, &firstBytes, BYTES_COUNT); if (!VirtualProtect(pfnGetModuleHandle, BYTES_COUNT, dwOldProtect, NULL)) { return FALSE; } return TRUE; } HANDLE __stdcall Handler(HANDLE hModule) { HANDLE returned; printf("GetModuleHandleW call detected\n"); UnhookGetModuleHandle(); __asm { push hModule call pfnGetModuleHandle mov returned, eax } HookGetModuleHandle(); }

HOW WHAT wrote:

have other method of hook dll and not need modification the Import Table and Export Table.

you can change first bytes of function to far jmp that points on your code.

oshah wrote:

MFC... not exactly plain C++ now is it ?

yep

oshah wrote:

VC Express does not include MFC. Therefore, your program won't work in the Express edition.

this is not a problem, mfc is easy to integrate, because I have betas, but beta version is very buggy product, thats why I will not use it...

Hi, Can you help me with choosing what version of Microsoft IDE I need to use. I am using this IDE for development of drivers and GUI wrappers for them, based on MFC library, I'm not planning to use .NET platform, only plain C++, no managed code. Now when Microsoft announced that Express Edition is free for download I want to try it, but it is very lightweight version of IDE and I don't know is there is any reason to download this IDE? I know that it doesn't have resource editor, mfc library, but compiler is more compatible to ISO standarts. Please help me with choise :^) Currently I am using VS .NET 2003.

Only one way I know - you must write a driver that hooks a NtTerminateProcess, NtShutdownProcess functions exported by ntdll.dll. From user-mode you're not allowed to hook this functions.

If you need solution of problem, use CDC* pDC = GetDC(); instead of CPaintDC dc(this);

>There is a flaw in your code. Thats why it is crashing. Basically compilier try to do second stack clean up.. . I know that compiler do stack cleaning after calling this function and in my disassembly I marked this place with comment. >>typedef HANDLE (__stdcall *FOO)(...); // function must be called via std convention >The above declaration is the problem.. As is GetModuleHandleA is a standard function following pascal calling (Standard windows) convention. This is not true. Pascal convention isn't standart windows dll's convention! Standart Windows convention is exacly STD. If you don't trust me just try this code: #include #include void main() { const char* src = "Let's test"; USHORT srcSz = strlen(src); char *dst = new char[srcSz+1]; memset(dst, 0x00, sizeof(src)+1); void *lpLstrcpy = GetProcAddress(LoadLibrary("kernel32.dll"), "lstrcpy"); printf("Testing STD Calling Convention...\n" "In this convention parameters must be stored in stack in back order\n" "And function must clean all it's parameters from stack by itself\n"); __asm { ; I put in stack all parameters in flip order(STD convention rule) push src ; lstrcpy(DESTINATION, SOURCE); push dst ; ^ | call lpLstrcpy ; ----------+ } printf("In dst variable now : %s\n", dst); memset(dst, 0x00, srcSz+1); // Zero memory at dst printf("\nTesting Pascal Calling Convention...\n" "In this convention parameters must be put in stack in normal order\n" "And function doesn't cleans all it's parameters from stack by itself\n"); __try { __asm { push dst push src call lpLstrcpy ; Clean stack sub esp, 0x08 } } __except (EXCEPTION_EXECUTE_HANDLER) { printf("\nOops!\n\n"); } printf("In dst variable now - %s\nOf course you don't see anything after '-'\n", dst); system("PAUSE"); } >In Pascal calling convention, the number of paramter we are passing to the function and the number of bytes required for that must be known before calling a function. >By that way the called function will do clean up. :) If function want it can clean stack if don't can not. Conventions is a way to describe how compiler must generate it's code to call some function. >You have declared a function pointer like this.. >typedef HANDLE (__stdcall *FOO)(...); >(...) which means the function would accept many number of parameters. C/CPP compiler wou

They are always situated in system dll's

I don't understand why compiler(Microsoft Visual C++ 7.1) always makes code that cleans stack from parameters after execution function that declared as __stdcall: void corrupt { typedef HANDLE (__stdcall *FOO)(...); // function must be called via std convention FOO foo = (FOO)GetProcAddress(LoadLibrary("kernel32.dll"), "GetModuleHandleA"); (*foo)(NULL); } Disassembly: push offset foo.??_C@_0BB@HNEJOH> ; /ProcNameOrdinal = "GetModuleHandleA" push offset foo.??_C@_0N@MDJJJHM> ; |/FileName = "kernel32.dll" call near dword ptr ds:[<&KERNEL32.LoadLibraryA> ; |\LoadLibraryA push eax ; |hModule = 0012F34C mov edi, dword ptr ds:[<&KERNEL32.GetProcAddress> ; |kernel32.GetProcAddress call near edi ; \GetProcAddress push 0 call near eax ; GetModuleHandleA call add esp, 4 ; An unwanted stack clean After execution this function we'll see an access violation, because the return address will be wrong. How can I fix that problem? PS In project options __stdcall is default calling convention