Need help with SymInitializeW

[Kapila De Silva]

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

[Eric Pouech]

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+

[Paul Vriens]

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.

[Eric Pouech]

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]

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+

[Eric Pouech]

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+