I guess, because LoadLibraryA checks if it's argument is 0. And to indicate this, he wrote that the same LoadLbraryA(NULL), when placed in own process, just fails, doesn't crash.

Actually the address may vary, windows sets it while loading kernel32.dll. But on each machine, all processes share kernel32.dll functions' addresses. DWORD __stdcall RemoteThreadProc(LPVOID lParam) { __asm { push 0 call DWORD PTR LoadLibrary } } should be ok...as long as you compile your program with optimizations on. It would be definitely OK if you wrote the whole thing in assembly to ensure that compiler won't insert there something you don't want it to. push 0 call DWORD PTR LoadLibrary retn 0 generates the same code, no matter where it's placed. If it still doesn't work, can you disassembly RemoteThreadProc and post here?

I don't get, how do you want to get file and line with stack trace, but you can obtain your return address with void *lpReturnAddress; __asm { mov lpReturnAddress, DWORD PTR[esp] }

Injecting functions written in high level programming language this way is unsafe, when they are relocated, some addresses change. It's safer to call HANDLE hRemoteThread = CreateRemoteThread( hTargetProcess, NULL, 0, LoadLibraryA, pRemotelyAllocatedStringContainigPathToTheDll, 0, &dwWriteBytes); And in the DllMain of this dll call your RemoteThreadProc. Anyway, as far as I understand the comments in your code, WriteProcessMemory is the part that fails. What process do you try inject your code to? Are you sure that you have sufficient rights? -- added at 6:56 Wednesday 28th November, 2007 One more thing. Do you compile it in debug mode? If so, at the address of your function you'll see: jmp some_other_address Then WriteProcessMemory will copy just these 5 (6?) bytes and some "other" data, not useful for you instead of your function's body.

Thanks that you tried to help.

Mark Salsbery wrote:

Isn't there a way to do what you're trying to do using documented/supported APIs?

Unfortunately, there isn't. What I'm doing is making Zoltan Csizmadia's ForceDel (a tool that deletes locked files) more usable. Improved performance (originally-very poor, especially when trying to delete multiple files), GUI, some more features. AFAIK there are 2 ways of doing it. The first is what Zoltan does - enumerating all handles and closing the right ones with CreateRemoteThread(CloseHandle). No documented API gives these handles... There's one more method, implemented in Unlocker. It's not open source and I had no time to reverse it..but it's a kernel mode hack. I guess, a kind of hook...and I think it's even worse than what I'm working at. It works faster though and maybe I'll decide to try to do the same.

Mark Salsbery wrote:

Why did you pick 80ms to wait here? What if it takes 81ms?

Under normal conditions, it shouldn't take even 3ms on a fairly modern machine. Why is it implemented this way? Because with insufficient access rights, NtQueryInformationFile doesn't return...at least not in reasonable time (I didn't write this code, but WAIT_TIMEOUT happens here up to 77 times on my machine. Also with 100 ms which was the default set several years ago by the author of this part). _endthread() would need to be called by the thread itself, which is impossible when NtQueryInformationFile doesn't return. Yes, this can cause a resource leak, I need to rewrite it to use CreateThread instead. Anyway, it's not the case. After a few hours of restarting my computer, I found where is the problem. INtDll::NtQueryObject ( handle, 1, NULL, 0, &size ); // let's try to use the default if ( size == 0 ) size = 0x8000; lpBuffer = (UCHAR*)HeapAlloc(hHeap = GetProcessHeap(), 0, sizeof(UCHAR)*size); if ( INtDll::NtQueryObject( handle, 1, lpBuffer, size, NULL ) == 0 ) { SystemInfoUtils::Unicode2CString( (UNICODE_STRING*)lpBuffer, str ); ret = TRUE; } Neither MSDN nor ntinternals.net write about thread security issues in NtQueryObject. I'm going to try to put it in a critical section and see what happens. Need another restart though :sigh: -- modified at 15:13 Saturday 24th November, 2007 When there's a hung process in memory, it becomes totally unpredictable. X| Even the single treaded, well tested version can hang here. I'm leaving it for today, I'm too tired.

Mark Salsbery wrote:

maciu2020 wrote: Unable to attach a debugger hmm...why?

This is what OllyDbg tells me..

Mark Salsbery wrote:

It really sounds like you have active threads left running. Closing a thread handle does not eliminate the thread. All threads should terminate themselves by returning.

Sure. All threads should do it as they have no loops or infinite waits. And when I run one at the time, they all return.

Mark Salsbery wrote:

You shouldn't ever need to terminate a thread or process forcefully.

Yep. And I didn't do it until this strange case.

Mark Salsbery wrote:

Also, make sure you use the proper thread creation functions, depending on what the thread uses:

I use the correct one. I thing it would be good to post the code. It's a slightly modified part of Zoltan Csizmadia's SystemInfo library. My ThreadProc just calls GetFileName() as below. For readability, I stripped security checks and cleanup. BOOL SystemHandleInformation::GetFileName( HANDLE h, CString& str, DWORD processId ) throw() { ULONG size = 0x8000; UCHAR* lpBuffer = NULL; BOOL ret = FALSE; HANDLE handle; HANDLE hRemoteProcess; BOOL remote = processId != GetCurrentProcessId(); DWORD dwId = 0; HANDLE hHeap; if ( remote ) { hRemoteProcess = ::OpenProcess( PROCESS_DUP_HANDLE, TRUE, processId ); handle = DuplicateHandle( hRemoteProcess, h ); } else handle = h; // let's be happy, handle is in our process space, so query the infos :) ret = GetFileNameHelper( handle, str ); INtDll::NtQueryObject ( handle, 1, NULL, 0, &size ); lpBuffer = (UCHAR*)HeapAlloc(hHeap = GetProcessHeap(), 0, sizeof(UCHAR)*size); if ( INtDll::NtQueryObject( handle, 1, lpBuffer, size, NULL ) == 0 ) { SystemInfoUtils::Unicode2CString( (UNICODE_STRING*)lpBuffer, str ); ret = TRUE; } return ret; } #define FILE_NAME_INFORMATION 9 //File related functions void __cdecl SystemHandleInformation::GetFileNameThread( PVOID pParam ) throw() { // This thread function for getting the filename // if access denied, we hang up in this function, // so if it times out we just kill this thread GetFileNameThreadParam* p = (GetFileNameThreadParam*)pParam; UCHAR *lpBuffer = (UCHAR*) VirtualAlloc( NULL, 0x1000*sizeof(U

Unable to attach a debugger. -- modified at 3:18 Saturday 24th November, 2007 Checked the currently running ones with Process Explorer. 19-139 threads. The newer instance-the more threads. How many did I create in total? One for each open file handle, system-wide. I noticed that each running copy of my program leaves some handles unclosed...and number of them is close to the number of threads left...(didn't count precisely, every 5-6 versions I have to restart computer, then I have a problem with resource allocation. And windows (XP SP2 BTW) also has some problems with killing them - closing system is ridiculously slow).

Recently, after rewriting a part of my code for multithreading, I noticed that after return from main(), the program doesn't quit. So I added ExitProcess() there. Doesn't work. TerminateThread(). Doesn't work. Doesn't return control. Then I tried to manually kill all the threads I started ( it wasn't necessary before, they should never hang ). Also doesn't return. Furthermore, the process cannot be killed in any way. Advanced Process Terminator can't do it. Any clue?