(Link to AcmlmWiki) Offline: thank ||bass
Register | Login
Views: 13,040,846
 Main | Memberlist | Active users | Calendar | Chat | Online users
Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album 		09-28-24 12:24 AM
0 users currently in Programming.
Acmlm's Board - I3 Archive - Programming - StackWalk64 isn't walking so much as stomping New poll | |
Add to favorites | Next newer thread | Next older thread
User Post
HyperHacker

Star Mario
Finally being paid to code in VB! If only I still enjoyed that. <_<
Wii #7182 6487 4198 1828


 





Since: 11-18-05
From: Canada, w00t!
My computer's specs, if anyone gives a damn.
STOP TRUNCATING THIS >8^(

Last post: 6431 days
Last view: 6431 days
Posted on 03-26-06 04:35 AM Link | Quote
I'm calling StackWalk64 to get a stack dump of another thread, and it seems to be doing that alright, but it's mucking up the stack of the thread I call it from!

DWORD WINAPI GetContext(LPVOID Thread)
{
STACKFRAME64 StackFrame;
CONTEXT Context;
HMODULE db;
HANDLE hProcess, hThread;
unsigned int i = 0, j = 0;
char* fn;
DWORD64 offset, ptr1, ptr2;
int OldThreadID = MainThreadID;
MainThreadID = GetCurrentThreadId();

memzero(&Context, sizeof(Context));
memzero(&StackFrame, sizeof(StackFrame));
Context.ContextFlags = CONTEXT_CONTROL;

hProcess = OpenProcess(PROCESS_ALL_ACCESS, false, GetCurrentProcessId());
hThread = OpenThread(THREAD_ALL_ACCESS, false, (int)Thread);
db = LoadLibrary("dbghelp");
FUNCTION_TABLE_ACCESS_ROUTINE64 SymFunctionTableAccess64 = (FUNCTION_TABLE_ACCESS_ROUTINE64)GetProcAddress(GetModuleHandle("dbghelp"),"SymFunctionTableAccess64");
PGET_MODULE_BASE_ROUTINE64 SymGetModuleBase64 = (PGET_MODULE_BASE_ROUTINE64)GetProcAddress(GetModuleHandle("dbghelp"),"SymGetModuleBase64");
BOOL(*StackWalk64)(DWORD, HANDLE, HANDLE, LPSTACKFRAME64, CONTEXT*, PREAD_PROCESS_MEMORY_ROUTINE64, FUNCTION_TABLE_ACCESS_ROUTINE64, PGET_MODULE_BASE_ROUTINE64, PTRANSLATE_ADDRESS_ROUTINE64) =
(BOOL(*)(DWORD, HANDLE, HANDLE, LPSTACKFRAME64, CONTEXT*, PREAD_PROCESS_MEMORY_ROUTINE64, FUNCTION_TABLE_ACCESS_ROUTINE64, PGET_MODULE_BASE_ROUTINE64, PTRANSLATE_ADDRESS_ROUTINE64))GetProcAddress(GetModuleHandle("dbghelp"),"StackWalk64");

BOOL(*SymInitialize)(HANDLE, char*, BOOL) = (BOOL(*)(HANDLE, char*, BOOL))GetProcAddress(GetModuleHandle("dbghelp"),"SymInitialize");
BOOL(*SymCleanup)(HANDLE) = (BOOL(*)(HANDLE))GetProcAddress(GetModuleHandle("dbghelp"),"SymCleanup");

SuspendThread(hThread);
GetThreadContext(hThread, &Context);

DebugOut(DO_ALL, "Eip = %08X, Ebp = %08X, Esp = %08X\n", Context.Eip, Context.Ebp, Context.Esp);

StackFrame.AddrPC.Offset = Context.Eip;
StackFrame.AddrPC.Mode = AddrModeFlat;
StackFrame.AddrFrame.Offset = Context.Ebp;
StackFrame.AddrFrame.Mode = AddrModeFlat;
StackFrame.AddrStack.Offset = Context.Esp;
StackFrame.AddrStack.Mode = AddrModeFlat;

DebugOut(DO_CRITICAL | DO_NO_ERROR | DO_NO_MSGBOX, "\n----------BEGIN STACK DUMP----------\nReturn PC Frame Stack Trace\n");
while(true)
{
if(!StackWalk64(IMAGE_FILE_MACHINE_I386, hProcess, hThread, &StackFrame, &Context, NULL, SymFunctionTableAccess64, SymGetModuleBase64, NULL)) break;
fn = "<not in main program>";

ptr1 = (DWORD64)_first_func;
ptr2 = (DWORD64)_last_func;
if((StackFrame.AddrPC.Offset < ptr1) || (StackFrame.AddrPC.Offset >= ptr2))
offset = 0;

DebugOut(DO_ALL, "StackWalk64=%08X; SymInitialize=%08X; SymCleanup=%08X\n", StackWalk64, SymInitialize, SymCleanup);
blah(1,2,3);
DebugOut(DO_ALL, "StackWalk64=%08X; SymInitialize=%08X; SymCleanup=%08X\n", StackWalk64, SymInitialize, SymCleanup);
}
DebugOut(DO_CRITICAL | DO_NO_ERROR | DO_NO_MSGBOX, "Return PC Frame Stack Trace\n----------END STACK DUMP----------\n");

FreeLibrary(db);
MainThreadID = OldThreadID;
ResumeThread(hThread);
CloseHandle(hThread);
CloseHandle(hProcess);
ExitThread(0);
}
(Mind the messy unfinished code. )

After the first 2 calls, it starts thrashing the local variables, starting at the pointer to StackWalk64 itself. (It's not defined in my libraries/compiler/whatever.) Notice the line "blah(1,2,3);" - this is where things start getting corrupted. SymCleanup becomes 1, SymInitialize becomes 2, and StackWalk64 becomes 3 - the values of the parameters. It seems like somewhere the stack pointer isn't getting reset properly. Thing is, this only happens if I call StackWalk64. Even calling a different function with the same specs (9 params, all 32 bits, and return 32 bits) doesn't cause it.
sloat



 





Since: 11-18-05
From: Delaware, US

Last post: 6534 days
Last view: 6534 days
Posted on 03-27-06 02:23 AM Link | Quote
Try adding a _stdcall or WINAPI directive to your function type definitions. They're the same thing, so it doesn't matter which you choose. I forget where to put it though, so good luck.
HyperHacker

Star Mario
Finally being paid to code in VB! If only I still enjoyed that. <_<
Wii #7182 6487 4198 1828


 





Since: 11-18-05
From: Canada, w00t!
My computer's specs, if anyone gives a damn.
STOP TRUNCATING THIS >8^(

Last post: 6431 days
Last view: 6431 days
Posted on 03-30-06 11:51 PM Link | Quote
Hey, it worked. Thanks!
Add to favorites | Next newer thread | Next older thread
Acmlm's Board - I3 Archive - Programming - StackWalk64 isn't walking so much as stomping |


ABII

Acmlmboard 1.92.999, 9/17/2006
©2000-2006 Acmlm, Emuz, Blades, Xkeeper

Page rendered in 0.010 seconds; used 362.64 kB (max 438.51 kB)