Need help with SymInitializeW
Hi All, Im trying to debug a crash in Everquest 2, (bug 7705) and am hoping someone here can help. The crash seems to be linked to the process calling SymInitializeW a second time (its called once at the start of the process, and works ok) On the second call to the function we see an error fixme:dbghelp:SymInitializeW what to do ?? By putting some tracing in here, I noticed that when the function is called the first time, the call to process_find_by_handle(hProcess) returns null, and once the SymInitializeW function calls EnumerateLoadedModules, process_find_by_handle returns a process id. In the second call, the process_find_by_handle(hProcess) returns the same process id as before, however, when the SymInitializeW function calls EnumerateLoadedModules, process_find_by_handle returns a different process id. Should SymInitializeW be called multiple times by a process? Is it possible that a problem has already occured, and this is called as a result? Or is it possible that SymInitializeW itself is the cause of the crash? Any ideas? Thanks Below is some trace I got when I put in some extra debug. First call: fixme:dbghelp:SymInitialize Calling SymInitializeW 0xffffffff(0xffffffff L"C:\\Program Files\\Sony\\EverQuest II" 1) fixme:dbghelp:process_find_by_handle Returning process handle (nil) fixme:dbghelp:process_find_by_handle Returning process handle 0x16c5d0 Second Call: fixme:dbghelp:SymInitialize Calling SymInitializeW 0xffffffff(0xffffffff (null) 1) fixme:dbghelp:process_find_by_handle Returning process handle 0x16c5d0 fixme:dbghelp:SymInitializeW what to do ?? fixme:dbghelp:process_find_by_handle Returning process handle 0x3a8f9a0
Kapila De Silva a écrit :
Hi All,
Im trying to debug a crash in Everquest 2, (bug 7705) and am hoping someone here can help.
I'll send a fix later on for the FIXME, but it's unlikely this is what's causing the crash So, you have to understand where the 0xffffffff as an address comes from. sometimes, +relay helps figuring that out, but YMMV A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)
Eric Pouech wrote:
Kapila De Silva a écrit :
Hi All,
Im trying to debug a crash in Everquest 2, (bug 7705) and am hoping someone here can help.
I'll send a fix later on for the FIXME, but it's unlikely this is what's causing the crash So, you have to understand where the 0xffffffff as an address comes from. sometimes, +relay helps figuring that out, but YMMV
A+
Hi, just wanted to report that Process Explorer also calls it with 0xffffffff when viewing the 'System Information': trace:dbghelp:SymInitializeW (0xffffffff (null) 0) trace:dbghelp:elf_load_file Processing elf file 'L"wine-kthread"' at 00000000 trace:dbghelp:elf_load_file Processing elf file 'L"/usr/lib/qt-3.3/bin/wine-kthread"' at 00000000 trace:dbghelp:elf_load_file Processing elf file 'L"/usr/kerberos/bin/wine-kthread"' at 00000000 trace:dbghelp:elf_load_file Processing elf file 'L"/usr/local/bin/wine-kthread"' at 00000000 Could 0xffffffff mean something like system-wide? Cheers, Paul.
Paul Vriens a écrit :
Eric Pouech wrote:
Kapila De Silva a écrit :
Hi All,
Im trying to debug a crash in Everquest 2, (bug 7705) and am hoping someone here can help.
I'll send a fix later on for the FIXME, but it's unlikely this is what's causing the crash So, you have to understand where the 0xffffffff as an address comes from. sometimes, +relay helps figuring that out, but YMMV
A+
Hi,
just wanted to report that Process Explorer also calls it with 0xffffffff when viewing the 'System Information':
trace:dbghelp:SymInitializeW (0xffffffff (null) 0) trace:dbghelp:elf_load_file Processing elf file 'L"wine-kthread"' at 00000000 trace:dbghelp:elf_load_file Processing elf file 'L"/usr/lib/qt-3.3/bin/wine-kthread"' at 00000000 trace:dbghelp:elf_load_file Processing elf file 'L"/usr/kerberos/bin/wine-kthread"' at 00000000 trace:dbghelp:elf_load_file Processing elf file 'L"/usr/local/bin/wine-kthread"' at 00000000
Could 0xffffffff mean something like system-wide?
Cheers,
Paul.
in that cas 0xffffffff is the default handle to the current process, and is never derefenced... include/winbase.h:#define GetCurrentProcess() ((HANDLE)0xffffffff) A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)
Hi guys, I put some more debug in the process_find_by_handle function of dbghelp.c, and what Im seeing is the second time we call SymInitializeW, we appear to create a new process structure, so following calls to process_find_by_handle returns the new one, and not the old one. In the trace below, the first call to process_find_by_handle returns a process structure stored at 0x16c600, but the next calls locate two process structures (one at 0x16c600 and one at 0xf5ee680). Could this be an issue? Both seem to have the same process handle of 0xffffffff. Maybe when allocating a new process structure we should check if one already exists with the same handle? Thanks Kapila. fixme:dbghelp:SymInitialize Calling SymInitializeW 0xffffffff fixme:dbghelp:SymInitializeW (0xffffffff (null) 1) fixme:dbghelp:process_find_by_handle Searching for process 0xffffffff compared to 0xffffffff (0x16c600) fixme:dbghelp:process_find_by_handle Returning process handle 0x16c600 and 0xffffffff fixme:dbghelp:SymInitializeW what to do ?? fixme:dbghelp:SymInitializeW Not User search path fixme:dbghelp:SymInitializeW check live target fixme:dbghelp:SymInitializeW Invade Process fixme:dbghelp:process_find_by_handle Searching for process 0xffffffff compared to 0xffffffff (0xf5ee680) fixme:dbghelp:process_find_by_handle Searching for process 0xffffffff compared to 0xffffffff (0x16c600) fixme:dbghelp:process_find_by_handle Returning process handle 0xf5ee680 and 0xffffffff On Wed, 2007-03-14 at 20:53 +0100, Eric Pouech wrote:
Paul Vriens a écrit :
Eric Pouech wrote:
Kapila De Silva a écrit :
Hi All,
Im trying to debug a crash in Everquest 2, (bug 7705) and am hoping someone here can help.
I'll send a fix later on for the FIXME, but it's unlikely this is what's causing the crash So, you have to understand where the 0xffffffff as an address comes from. sometimes, +relay helps figuring that out, but YMMV
A+
Hi,
just wanted to report that Process Explorer also calls it with 0xffffffff when viewing the 'System Information':
trace:dbghelp:SymInitializeW (0xffffffff (null) 0) trace:dbghelp:elf_load_file Processing elf file 'L"wine-kthread"' at 00000000 trace:dbghelp:elf_load_file Processing elf file 'L"/usr/lib/qt-3.3/bin/wine-kthread"' at 00000000 trace:dbghelp:elf_load_file Processing elf file 'L"/usr/kerberos/bin/wine-kthread"' at 00000000 trace:dbghelp:elf_load_file Processing elf file 'L"/usr/local/bin/wine-kthread"' at 00000000
Could 0xffffffff mean something like system-wide?
Cheers,
Paul.
in that cas 0xffffffff is the default handle to the current process, and is never derefenced... include/winbase.h:#define GetCurrentProcess() ((HANDLE)0xffffffff) A+
Kapila De Silva a écrit :
Hi guys,
I put some more debug in the process_find_by_handle function of dbghelp.c, and what Im seeing is the second time we call SymInitializeW, we appear to create a new process structure, so following calls to process_find_by_handle returns the new one, and not the old one.
In the trace below, the first call to process_find_by_handle returns a process structure stored at 0x16c600, but the next calls locate two process structures (one at 0x16c600 and one at 0xf5ee680).
Could this be an issue? Both seem to have the same process handle of 0xffffffff. Maybe when allocating a new process structure we should check if one already exists with the same handle?
Again, I said I'll send a patch for the syminitialize issue being called twice (but I need to figure out the semantics for the SymCleanup, which seem to be ackward...), but that's unlikely the cause of the later crash, so you don't need to spend too much time on the dbghelp issue (if you really want to be sure, in SymInitialize return TRUE if we've found an existing process with the same handle) A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)
participants (3)
-
Eric Pouech -
Kapila De Silva -
Paul Vriens