gamedevlists-windows

RE: [GD-Windows] Finding routine that's crashing

[Brian S. <bs...@mi...>]

You can get OS symbols here:

http://www.microsoft.com/ddk/debugging/symbolpkg.asp=20

You can also try stopping immediately on exceptions (start your app,
then go to Debug->Exceptions->Stop Always).  That might put on the
brakes before your call stack gets trashed.

good luck!  --b.

> -----Original Message-----
> From: Brian Hook [mailto:bri...@py...]=20
> Sent: Wednesday, July 31, 2002 10:41 AM
> To: gam...@li...
> Subject: [GD-Windows] Finding routine that's crashing
>=20
>=20
> I'm getting an exception deep inside some call such that I=20
> don't have a
> call stack.  I'm using MSVC6.  I'm not sure what's causing it or where
> it happens, and it appears to be timing dependent (i.e. if I step
> through the code, it doesn't happen).
>=20
> Is there a simple way given an address to look up what=20
> function I'm in?
> Using a MAP file works for app code, but this appears to be an entry
> point somewhere deeper in the system so the address I'm=20
> seeing isn't in
> the MAP file.
>=20
> Thanks,
>=20
> Brian

RE: [GD-Windows] Finding routine that's crashing

[Brian H. <bri...@py...>]

Woo-hoo!  WinDBG! =)  It feels like one step above the - prompt and
debug.com

So far I've got it to repro in WinDBG, but it's rather frustrating since
apparently I'm in the middle of nowhere (my current address doesn't map
to any loaded modules), but the disasm I'm looking at is very valid
(typical stack frame munging, unmunging, some work in between, pop/ret
at the end).  

Grrr, the docs and interface leave a bit to be desired.

Thanks, I'll give this a go for a bit.

Brian

Re: [GD-Windows] Finding routine that's crashing

[Rich <leg...@xm...>]

In article <555...@gu...>,
    Ben Carter <be...@gu...>  writes:

> [...] We've got an exception
> handler in our current project that can do a stack trace and reports
> everything it finds, with symbols if available - if you can't track
> down the information give me a shout and I'll see if I can extract the
> relevant code snippets for resolving the addresses. 

This would be very handy, if you're willing to share!

I can find SymGetSymFromAddr in MSDN, but I'm fuzzy on how you get the
stack trace.
-- 
Ask me about my upcoming book on Direct3D from Addison-Wesley!
  Direct3D Book <http://www.xmission.com/~legalize/book/>
    izfree: Open source tools for Windows Installer
            <http://izfree.sourceforge.net>

RE: [GD-Windows] Finding routine that's crashing

[Paul B. <pa...@mi...>]

Check out John Robbins bugslayer code.  You might find it
at his site
http://www.wintellect.com/about/instructors/robbins/default.asp

Paul


> -----Original Message-----
> From: Rich [mailto:leg...@xm...]=20
> Sent: Wednesday, July 31, 2002 2:16 PM
> To: gam...@li...
> Subject: Re: [GD-Windows] Finding routine that's crashing=20
>=20
>=20
>=20
> In article <555...@gu...>,
>     Ben Carter <be...@gu...>  writes:
>=20
> > [...] We've got an exception
> > handler in our current project that can do a stack trace=20
> and reports=20
> > everything it finds, with symbols if available - if you can't track=20
> > down the information give me a shout and I'll see if I can=20
> extract the=20
> > relevant code snippets for resolving the addresses.
>=20
> This would be very handy, if you're willing to share!
>=20
> I can find SymGetSymFromAddr in MSDN, but I'm fuzzy on how=20
> you get the stack trace.
> --=20
> Ask me about my upcoming book on Direct3D from Addison-Wesley!
>   Direct3D Book <http://www.xmission.com/~legalize/book/>
>     izfree: Open source tools for Windows Installer
>             <http://izfree.sourceforge.net>
>=20
>=20
> -------------------------------------------------------
> This sf.net email is sponsored by: Dice - The leading online=20
> job board for high-tech professionals. Search and apply for=20
> tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=3D31
> _______________________________________________
> Gamedevlists-windows mailing list=20
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D555
>=20

RE: [GD-Windows] Finding routine that's crashing

[Brian S. <bs...@mi...>]

StackWalk() gives you the stack trace.

Robbins' Debugging Windows Apps covers this in some detail as well.  It
doesn't give you anything that you won't get from inside the debugger
though - it's most useful for logging crashes on customer or QA
machines.

--brian

> -----Original Message-----
> From: Rich [mailto:leg...@xm...]=20
> Sent: Wednesday, July 31, 2002 12:16 PM
> To: gam...@li...
> Subject: Re: [GD-Windows] Finding routine that's crashing=20
>=20
>=20
>=20
> In article <555...@gu...>,
>     Ben Carter <be...@gu...>  writes:
>=20
> > [...] We've got an exception
> > handler in our current project that can do a stack trace and reports
> > everything it finds, with symbols if available - if you can't track
> > down the information give me a shout and I'll see if I can=20
> extract the
> > relevant code snippets for resolving the addresses.=20
>=20
> This would be very handy, if you're willing to share!
>=20
> I can find SymGetSymFromAddr in MSDN, but I'm fuzzy on how you get the
> stack trace.

RE: [GD-Windows] Finding routine that's crashing

[Brian H. <bri...@py...>]

Well, found it.  The reason I was having such a hard time finding it is
because apparently it's a dynamically generated piece of code that the
NVidia drivers make, therefore there was no symbol or module associated
with that address space.

Loverly.

Thanks for everyone that helped though, at least I've now found the joy
of WinDbg =)

Brian


> -----Original Message-----
> From: gam...@li... 
> [mailto:gam...@li...] On 
> Behalf Of Brian Sharon
> Sent: Wednesday, July 31, 2002 12:23 PM
> To: Rich; gam...@li...
> Subject: RE: [GD-Windows] Finding routine that's crashing 
> 
> 
> StackWalk() gives you the stack trace.
> 
> Robbins' Debugging Windows Apps covers this in some detail as 
> well.  It doesn't give you anything that you won't get from 
> inside the debugger though - it's most useful for logging 
> crashes on customer or QA machines.
> 
> --brian
> 
> > -----Original Message-----
> > From: Rich [mailto:leg...@xm...]
> > Sent: Wednesday, July 31, 2002 12:16 PM
> > To: gam...@li...
> > Subject: Re: [GD-Windows] Finding routine that's crashing 
> > 
> > 
> > 
> > In article <555...@gu...>,
> >     Ben Carter <be...@gu...>  writes:
> > 
> > > [...] We've got an exception
> > > handler in our current project that can do a stack trace 
> and reports 
> > > everything it finds, with symbols if available - if you 
> can't track 
> > > down the information give me a shout and I'll see if I can
> > extract the
> > > relevant code snippets for resolving the addresses.
> > 
> > This would be very handy, if you're willing to share!
> > 
> > I can find SymGetSymFromAddr in MSDN, but I'm fuzzy on how 
> you get the 
> > stack trace.
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: Dice - The leading online 
> job board for high-tech professionals. Search and apply for 
> tech jobs today! http://seeker.dice.com/seeker.epl?rel_code1
> _______________________________________________
> Gamedevlists-windows mailing list 
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives: http://sourceforge.net/mailarchive/forum.php?forum_idU5
> 
> 

RE: [GD-Windows] Finding routine that's crashing

[Andrew G. <ag...@cl...>]

Err yeah. It was late that night ok! :)

I think the two extra FF's are a typo as that buffer is just used to =
store
the current working directory, why it's not on the stack is probably a
result of me not tidying things up properly.

I had all sorts of nightmares trying to get that stack trace stuff =
working
reliably on versions of Win9x so as a result that whole file which =
deals
with retrieving the callstack and symbol names ended up being quite =
messy as
I tried various things, and at the end I just ran over the file quickly =
to
tidy things up.

Thanks, I might clean it up and bung it on flipcode or something. I =
still
use that DLL as a drop for projects as it's very handy, but haven't =
looked
at the source since last year when I wrote it.

Andrew Grant-
Climax Brighton=20



> -----Original Message-----
> From: Ignacio Casta=F1o [mailto:cas...@ya...]
> Sent: 01 August 2002 21:27
> To: gam...@li...
> Subject: Re: [GD-Windows] Finding routine that's crashing=20
>=20
>=20
> Hey, thanks! what a nice code!
>=20
> by the way, there's a little leak in line 96 in file=20
> ExceptionHandler.cpp:
>=20
>  tt =3D new char[TTBUFLEN];
>=20
> is never freed, just replace it by:
>=20
> char tt[TTBUFLEN];
>=20
> and should be fine, or add the appropiate delete at the end=20
> of the function.
>=20
> And there's no need to have TTBUFLEN =3D 0xFFFF, that's too big=20
> I think...
>=20
>=20
>=20
> Ignacio Casta=F1o
> cas...@ya...
>=20
>=20
> Andrew Grant wrote:
> > This would be very handy, if you're willing to share!
> >
> > I can find SymGetSymFromAddr in MSDN, but I'm fuzzy on how=20
> you get the
> > stack trace.
>=20
> (Second sending, apparently the mail list has an attatchment=20
> limit which I
> went over by more than I thought it'd be). Files are at
> <http://www.b0rked.clara.co.uk/assert.zip>
>=20
> Attatched is the source for something similar (and a drop in=20
> module for
> people who don't really want to worry about how it works).=20
> Sorry for the
> attatchment, it's fairly small and I don't have anywhere at=20
> hand to upload
> it to.
>=20
> I wrote this a while ago for tracking down some rare crashes=20
> we had in art
> tools, it's basically a drop in that replaces the standard=20
> MSVC runtime
> assert but provides more info. You place the dll in your=20
> working folder and
> add the two files to your project so when an assert triggers=20
> you get the
> below dialog. If the DLL doesn't exist then it defaults back=20
> to the standard
> version.
>=20
> use ASSERT(x) or one of the macros in stdassert.h and you should get =
a
> dialog like the image below.
>=20
> Hopefully it might be of some use to someone. It's very old=20
> code that I
> wrote in one evening so be kind, also some of the stack trace=20
> code is ripped
> from an MSDN sample but tidied up.
>=20
>=20
> Andrew Grant-
> Climax Brighton
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> _______________________________________________________________
> Yahoo! Messenger
> Nueva versi=F3n: Webcam, voz, y mucho m=E1s =A1Gratis!=20
> Desc=E1rgalo ya desde http://messenger.yahoo.es
>=20
>=20
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=3D555
>=20

Re: [GD-Windows] Finding routine that's crashing

[Colin F. <cp...@ea...>]

2002 August 1st
Thursday

That code is very interesting.  There are at least two things
that caused me trouble, though:


[1] Under Windows 98, the DLL with the symbol handler and
  StackWalk() functions is called: "imagehlp.dll".
  (i.e., different from the "dbghelp.dll" references
  scattered around the source and project settings)


[2] Under Windows 98, we need the process **ID** for
  SymInitialize(), NOT the process handle.
  (See MSDN Library documentation for SymInitialize().)

  HANDLE hProcess = GetCurrentProcess();
  DWORD idProcess = GetCurrentProcessId();

#ifdef WIN_98
  SymInitialize( ((HANDLE)(idProcess)), mSearchPath, FALSE );
#else
  SymInitialize( hProcess, mSearchPath, FALSE );
#endif

   (NOTE: Read MSDN Library documentation for how to
   proceed with the other functions.)

Despite the glitches (I still can't get the code to work
under Windows 98; minor stuff), I'm glad for the code example;
it inspired me to study this area, which is fascinating.


By the way...

>>>Hey, thanks! what a nice code!
>>>by the way, there's a little leak in line 96 in file
ExceptionHandler.cpp:
>>>tt = new char[TTBUFLEN];
>>>is never freed, just replace it by:
>>>char tt[TTBUFLEN];
>>>and should be fine, or add the appropiate delete at the end
>>>of the function.
>>>And there's no need to have TTBUFLEN = 0xFFFF, that's too big I think...
>>>Ignacio Castaño
>>>cas...@ya...

Perhaps "tt = new char[TTBUFLEN]" was done instead of
"char tt[TTBUFLEN]" to avoid putting more stuff on the
stack?  I guess if the exception was a stack overflow,
then you're pretty much doomed anyway.

--- Colin

==============================================================


Andrew Grant wrote:
> This would be very handy, if you're willing to share!
>
> I can find SymGetSymFromAddr in MSDN, but I'm fuzzy on how you get the
> stack trace.

(Second sending, apparently the mail list has an attatchment limit which I
went over by more than I thought it'd be). Files are at
<http://www.b0rked.clara.co.uk/assert.zip>

Attatched is the source for something similar (and a drop in module for
people who don't really want to worry about how it works). Sorry for the
attatchment, it's fairly small and I don't have anywhere at hand to upload
it to.

I wrote this a while ago for tracking down some rare crashes we had in art
tools, it's basically a drop in that replaces the standard MSVC runtime
assert but provides more info. You place the dll in your working folder and
add the two files to your project so when an assert triggers you get the
below dialog. If the DLL doesn't exist then it defaults back to the standard
version.

use ASSERT(x) or one of the macros in stdassert.h and you should get a
dialog like the image below.

Hopefully it might be of some use to someone. It's very old code that I
wrote in one evening so be kind, also some of the stack trace code is ripped
from an MSDN sample but tidied up.


Andrew Grant-
Climax Brighton

Re: [GD-Windows] Finding routine that's crashing

[Colin F. <cp...@ea...>]

2002 August 2nd
Friday

Help!

First, I'm going to reply to my own post, contradicting and
criticizing myself.

>>> [1] Under Windows 98, the DLL with the symbol handler and
>>>   StackWalk() functions is called: "imagehlp.dll".
>>>   (i.e., different from the "dbghelp.dll" references
>>>   scattered around the source and project settings)

Okay, the first part is true, but the posted code doesn't
mention "dbghelp.dll" anywhere!  I was just confused.
After I couldn't get the posted code to work, I downloaded
a completely different project (Bugslayer1000), and *THAT*
project had "dbghelp.dll" all over the place!


>>> [2] Under Windows 98, we need the process **ID** for
>>>   SymInitialize(), NOT the process handle.
>>>   (See MSDN Library documentation for SymInitialize().)

This really was in the documentation, but I'm getting
mixed signals from the code...

  (a) If I use the process ID (following MSDN
      documentation on SymInitialize()), the StackWalk()
      stops walking after a single iteration!  The symbol
      lookup returns an empty symbol string, but doesn't
      complain about accessing an invalid address.

  (b) If I use hProcess handle (contradicting MSDN
      documentation on SymInitialize()), the StackWalk()
      walks up the stack just fine (apparently)!  The symbol
      lookup fails (complain about accessing an invalid address).


I'd really like to get the code working, just as an educational
example.

Here's a kind of trace of what happened:
========================================

(NOTE: The following trace assumes that we can get away with
using hProcess for the symbol handler (contradicting the
documentation).  The trace with the process ID as symbol
handler and StackWalk parameter is similar, but ends
with a whimper: StackWalk() ends its walk immediately,
and SymGetSymFromAddr() returns nothing!)

When my test application starts executing:
------------------------------------------

ENTER ExceptionHandler::ExceptionHandler()

  ENTER ExceptionHandler::InitClass()
  LEAVE ExceptionHandler::InitClass()

  ENTER ExceptionHandler::InitDLL()
    global_hProcess   = 0x7fffffff
    global_ProcessId  = 0xfffcfd73
    global_SymProcess = 0x7fffffff
    mHImageHlpDll = LoadLibrary("imagehlp.dll"); = 0x7d750000
  LEAVE ExceptionHandler::InitDLL()

  Dir with executable:
'C:\WINDOWS\DESKTOP\ASSERT_CODE\TEST_ASSERT\DEBUG\TEST_ASSERT.EXE'

LEAVE ExceptionHandler::ExceptionHandler()



When my test application calls ASSERTx(...):
--------------------------------------------

ENTER ExceptionHandler::DumpCrash(HANDLE hThread = 0xfffffffe, void*
pExceptionInfo = 0x0065f8c0)

  About to do
    SymInitialize


     0x7fffffff,

"C:\WINDOWS\Desktop\assert_code\test_assert\Debug;C:\WINDOWS\DESKTOP\ASSERT_
CODE\TEST_ASSERT\DEBUG;",
     FALSE
     );

  About to do
     SymSetOptions(SYMOPT_LOAD_LINES | SYMOPT_UNDNAME |
SYMOPT_CASE_INSENSITIVE);

  About to do
     enumAndLoadModuleSymbols( global_hProcess, global_ProcessId );


  ENTER void enumAndLoadModuleSymbols( HANDLE hProcess = 0x7fffffff, DWORD
pid = 0xfffcfd73 );

. . .
. . .
. . .
    sSymLoadModule


      global_SymProcess = 0x7fffffff,
      0,
      img='C:\WINDOWS\DESKTOP\ASSERT_CODE\TEST_ASSERT\DEBUG\STDASSERT.DLL',
      mod='STDASSERT.DLL',
      base=0x10000000,
      size=311296
      ); ==> Result = 0x10000000

    sSymLoadModule


      global_SymProcess = 0x7fffffff,
      0,

img='C:\WINDOWS\DESKTOP\ASSERT_CODE\TEST_ASSERT\DEBUG\TEST_ASSERT.EXE',
      mod='TEST_ASSERT.EXE',
      base=0x00400000,
      size=180224
      ); ==> Result = 0x00400000

    sSymLoadModule


      global_SymProcess = 0x7fffffff,
      0,
      img='C:\WINDOWS\SYSTEM\KERNEL32.DLL',
      mod='KERNEL32.DLL',
      base=0xbff70000,
      size=471040
      ); ==> Result = 0xbff70000
. . .

LEAVE void enumAndLoadModuleSymbols( HANDLE hProcess = 0x7fffffff, DWORD pid
= 0xfffcfd73 );


(Back in ExceptionHandler::DumpCrash()...)


  StackWalk
    ( ...,
    global_SymProcess = 0x7fffffff,
    hThread = 0xfffffffe,
    {sfStackFrame.AddrPC.Offset = 0x100042b3},
    ...); ==> Result = 1

  SymGetSymFromAddr


    global_SymProcess = 0x7fffffff,
    ui32_Address = 0x100042b3,
    &(dwSymOffset = 0x00000000),
    (pSymbol->Name = '')
    ); ==> Result = 0x00000001

  ERROR: "Attempt to access invalid address"

  StackWalk
    ( ...,
    global_SymProcess = 0x7fffffff,
    hThread = 0xfffffffe,
    {sfStackFrame.AddrPC.Offset = 0x004012c0},
    ...); ==> Result = 1

  SymGetSymFromAddr


    global_SymProcess = 0x7fffffff,
    ui32_Address = 0x004012c0,
    &(dwSymOffset = 0x00000000),
    (pSymbol->Name = '')
    ); ==> Result = 0x00000001

  ERROR: "Attempt to access invalid address"

  StackWalk
    ( ...,
    global_SymProcess = 0x7fffffff,
    hThread = 0xfffffffe,
    {sfStackFrame.AddrPC.Offset = 0x0040139e},
    ...); ==> Result = 1

  SymGetSymFromAddr


    global_SymProcess = 0x7fffffff,
    ui32_Address = 0x0040139e,
    &(dwSymOffset = 0x00000000),
    (pSymbol->Name = '')
    ); ==> Result = 0x00000001

  ERROR: "Attempt to access invalid address"

  StackWalk
    ( ...,
    global_SymProcess = 0x7fffffff,
    hThread = 0xfffffffe,
    {sfStackFrame.AddrPC.Offset = 0x004013fd},
    ...); ==> Result = 1

  SymGetSymFromAddr


    global_SymProcess = 0x7fffffff,
    ui32_Address = 0x004013fd,
    &(dwSymOffset = 0x00000000),
    (pSymbol->Name = '')
    ); ==> Result = 0x00000001

  ERROR: "Attempt to access invalid address"

  StackWalk
    ( ...,
    global_SymProcess = 0x7fffffff,
    hThread = 0xfffffffe,
    {sfStackFrame.AddrPC.Offset = 0x0040144a},
    ...); ==> Result = 1

  SymGetSymFromAddr


    global_SymProcess = 0x7fffffff,
    ui32_Address = 0x0040144a,
    &(dwSymOffset = 0x00000000),
    (pSymbol->Name = '')
    ); ==> Result = 0x00000001

  ERROR: "Attempt to access invalid address"

  StackWalk
    ( ...,
    global_SymProcess = 0x7fffffff,
    hThread = 0xfffffffe,
    {sfStackFrame.AddrPC.Offset = 0x004020c9},
    ...); ==> Result = 1

  SymGetSymFromAddr


    global_SymProcess = 0x7fffffff,
    ui32_Address = 0x004020c9,
    &(dwSymOffset = 0x00000000),
    (pSymbol->Name = '')
    ); ==> Result = 0x00000001

  ERROR: "Attempt to access invalid address"

  StackWalk
    ( ...,
    global_SymProcess = 0x7fffffff,
    hThread = 0xfffffffe,
    {sfStackFrame.AddrPC.Offset = 0xbff8b537},
    ...); ==> Result = 1

  SymGetSymFromAddr


    global_SymProcess = 0x7fffffff,
    ui32_Address = 0xbff8b537,
    &(dwSymOffset = 0x00000000),
    (pSymbol->Name = '')
    ); ==> Result = 0x00000001

  ERROR: "Attempt to access invalid address"



Closing Comments:
-----------------

The stack walking looks fine!  The addresses fall within the various *.DLL
files.
I'm sure I could convert the addresses to functions by hand;  i.e., I am
confident that the addresses are valid.

I initiatialized the structure size field in the symbol structure
(which wasn't done in the original version of the code)
for SymGetSymFromAddr().

The process handle is the same as that used to initialize the
symbol handler -- and if I try using a different handle,
the function reports (via GetLastError()) "invalid handle".

What could this be?!  What is the "Attempt to access invalid address"
reported by SymGetSymFromAddr() (via GetLastError())?

I also tried using the exact address of an existing symbol
in the SymGetSymFromAddr(), just as a sanity check...
But there was no sanity!  It also resulted in the
"Attempt to access invalid address" error.

All of this is under Windows 98, using Visual C++ 6.0 Professional,
with Service Pack 5.  I never explicitly installed a different
version of "imagehlp.{dll,lib,h}" -- although VC++ 6.0 SP5 may
have overwritten the version that shipped with VC++ 6.0.

I'd step in to SymGetSymFromAddr()...IF I KNEW HOW!!! ;-)

--- Colin

RE: [GD-Windows] Finding routine that's crashing

[Andrew G. <ag...@cl...>]

I told you it was fun under Win9x :)

Symbol lookups under 98 were always the thing that bit me, the problem as
far as I remember is that there's multiple versions of imagehlp for 98 and
only the later ones work. I think my eventual solution involved using a
specific version of this DLL (which was fine as this was for inhouse stuff).

Thankfull the situation Win2K and higher is a lot nicer. The sooner the 9x
kernel dies the better.

Sorry I can only vaguely hint at how I eventually got it working, I can't
even fire it up here as we don't have any Win98 machines.

Andrew Grant-
Climax Brighton 



> -----Original Message-----
> From: Colin Fahey [mailto:cp...@ea...]
> Sent: 02 August 2002 10:03
> To: Gam...@li...
> Subject: Re: [GD-Windows] Finding routine that's crashing
> 
> 
> 2002 August 2nd
> Friday
> 
> Help!
> 
> First, I'm going to reply to my own post, contradicting and
> criticizing myself.
> 
> >>> [1] Under Windows 98, the DLL with the symbol handler and
> >>>   StackWalk() functions is called: "imagehlp.dll".
> >>>   (i.e., different from the "dbghelp.dll" references
> >>>   scattered around the source and project settings)
> 
> Okay, the first part is true, but the posted code doesn't
> mention "dbghelp.dll" anywhere!  I was just confused.
> After I couldn't get the posted code to work, I downloaded
> a completely different project (Bugslayer1000), and *THAT*
> project had "dbghelp.dll" all over the place!
> 
> 
> >>> [2] Under Windows 98, we need the process **ID** for
> >>>   SymInitialize(), NOT the process handle.
> >>>   (See MSDN Library documentation for SymInitialize().)
> 
> This really was in the documentation, but I'm getting
> mixed signals from the code...
> 
>   (a) If I use the process ID (following MSDN
>       documentation on SymInitialize()), the StackWalk()
>       stops walking after a single iteration!  The symbol
>       lookup returns an empty symbol string, but doesn't
>       complain about accessing an invalid address.
> 
>   (b) If I use hProcess handle (contradicting MSDN
>       documentation on SymInitialize()), the StackWalk()
>       walks up the stack just fine (apparently)!  The symbol
>       lookup fails (complain about accessing an invalid address).
> 
> 
> I'd really like to get the code working, just as an educational
> example.
> 
> Here's a kind of trace of what happened:
> ========================================
> 
> (NOTE: The following trace assumes that we can get away with
> using hProcess for the symbol handler (contradicting the
> documentation).  The trace with the process ID as symbol
> handler and StackWalk parameter is similar, but ends
> with a whimper: StackWalk() ends its walk immediately,
> and SymGetSymFromAddr() returns nothing!)
> 
> When my test application starts executing:
> ------------------------------------------
> 
> ENTER ExceptionHandler::ExceptionHandler()
> 
>   ENTER ExceptionHandler::InitClass()
>   LEAVE ExceptionHandler::InitClass()
> 
>   ENTER ExceptionHandler::InitDLL()
>     global_hProcess   = 0x7fffffff
>     global_ProcessId  = 0xfffcfd73
>     global_SymProcess = 0x7fffffff
>     mHImageHlpDll = LoadLibrary("imagehlp.dll"); = 0x7d750000
>   LEAVE ExceptionHandler::InitDLL()
> 
>   Dir with executable:
> 'C:\WINDOWS\DESKTOP\ASSERT_CODE\TEST_ASSERT\DEBUG\TEST_ASSERT.EXE'
> 
> LEAVE ExceptionHandler::ExceptionHandler()
> 
> 
> 
> When my test application calls ASSERTx(...):
> --------------------------------------------
> 
> ENTER ExceptionHandler::DumpCrash(HANDLE hThread = 0xfffffffe, void*
> pExceptionInfo = 0x0065f8c0)
> 
>   About to do
>     SymInitialize
> 
> 
>      0x7fffffff,
> 
> "C:\WINDOWS\Desktop\assert_code\test_assert\Debug;C:\WINDOWS\D
> ESKTOP\ASSERT_
> CODE\TEST_ASSERT\DEBUG;",
>      FALSE
>      );
> 
>   About to do
>      SymSetOptions(SYMOPT_LOAD_LINES | SYMOPT_UNDNAME |
> SYMOPT_CASE_INSENSITIVE);
> 
>   About to do
>      enumAndLoadModuleSymbols( global_hProcess, global_ProcessId );
> 
> 
>   ENTER void enumAndLoadModuleSymbols( HANDLE hProcess = 
> 0x7fffffff, DWORD
> pid = 0xfffcfd73 );
> 
> . . .
> . . .
> . . .
>     sSymLoadModule
> 
> 
>       global_SymProcess = 0x7fffffff,
>       0,
>       
> img='C:\WINDOWS\DESKTOP\ASSERT_CODE\TEST_ASSERT\DEBUG\STDASSERT.DLL',
>       mod='STDASSERT.DLL',
>       base=0x10000000,
>       size=311296
>       ); ==> Result = 0x10000000
> 
>     sSymLoadModule
> 
> 
>       global_SymProcess = 0x7fffffff,
>       0,
> 
> img='C:\WINDOWS\DESKTOP\ASSERT_CODE\TEST_ASSERT\DEBUG\TEST_ASS
> ERT.EXE',
>       mod='TEST_ASSERT.EXE',
>       base=0x00400000,
>       size=180224
>       ); ==> Result = 0x00400000
> 
>     sSymLoadModule
> 
> 
>       global_SymProcess = 0x7fffffff,
>       0,
>       img='C:\WINDOWS\SYSTEM\KERNEL32.DLL',
>       mod='KERNEL32.DLL',
>       base=0xbff70000,
>       size=471040
>       ); ==> Result = 0xbff70000
> . . .
> 
> LEAVE void enumAndLoadModuleSymbols( HANDLE hProcess = 
> 0x7fffffff, DWORD pid
> = 0xfffcfd73 );
> 
> 
> (Back in ExceptionHandler::DumpCrash()...)
> 
> 
>   StackWalk
>     ( ...,
>     global_SymProcess = 0x7fffffff,
>     hThread = 0xfffffffe,
>     {sfStackFrame.AddrPC.Offset = 0x100042b3},
>     ...); ==> Result = 1
> 
>   SymGetSymFromAddr
> 
> 
>     global_SymProcess = 0x7fffffff,
>     ui32_Address = 0x100042b3,
>     &(dwSymOffset = 0x00000000),
>     (pSymbol->Name = '')
>     ); ==> Result = 0x00000001
> 
>   ERROR: "Attempt to access invalid address"
> 
>   StackWalk
>     ( ...,
>     global_SymProcess = 0x7fffffff,
>     hThread = 0xfffffffe,
>     {sfStackFrame.AddrPC.Offset = 0x004012c0},
>     ...); ==> Result = 1
> 
>   SymGetSymFromAddr
> 
> 
>     global_SymProcess = 0x7fffffff,
>     ui32_Address = 0x004012c0,
>     &(dwSymOffset = 0x00000000),
>     (pSymbol->Name = '')
>     ); ==> Result = 0x00000001
> 
>   ERROR: "Attempt to access invalid address"
> 
>   StackWalk
>     ( ...,
>     global_SymProcess = 0x7fffffff,
>     hThread = 0xfffffffe,
>     {sfStackFrame.AddrPC.Offset = 0x0040139e},
>     ...); ==> Result = 1
> 
>   SymGetSymFromAddr
> 
> 
>     global_SymProcess = 0x7fffffff,
>     ui32_Address = 0x0040139e,
>     &(dwSymOffset = 0x00000000),
>     (pSymbol->Name = '')
>     ); ==> Result = 0x00000001
> 
>   ERROR: "Attempt to access invalid address"
> 
>   StackWalk
>     ( ...,
>     global_SymProcess = 0x7fffffff,
>     hThread = 0xfffffffe,
>     {sfStackFrame.AddrPC.Offset = 0x004013fd},
>     ...); ==> Result = 1
> 
>   SymGetSymFromAddr
> 
> 
>     global_SymProcess = 0x7fffffff,
>     ui32_Address = 0x004013fd,
>     &(dwSymOffset = 0x00000000),
>     (pSymbol->Name = '')
>     ); ==> Result = 0x00000001
> 
>   ERROR: "Attempt to access invalid address"
> 
>   StackWalk
>     ( ...,
>     global_SymProcess = 0x7fffffff,
>     hThread = 0xfffffffe,
>     {sfStackFrame.AddrPC.Offset = 0x0040144a},
>     ...); ==> Result = 1
> 
>   SymGetSymFromAddr
> 
> 
>     global_SymProcess = 0x7fffffff,
>     ui32_Address = 0x0040144a,
>     &(dwSymOffset = 0x00000000),
>     (pSymbol->Name = '')
>     ); ==> Result = 0x00000001
> 
>   ERROR: "Attempt to access invalid address"
> 
>   StackWalk
>     ( ...,
>     global_SymProcess = 0x7fffffff,
>     hThread = 0xfffffffe,
>     {sfStackFrame.AddrPC.Offset = 0x004020c9},
>     ...); ==> Result = 1
> 
>   SymGetSymFromAddr
> 
> 
>     global_SymProcess = 0x7fffffff,
>     ui32_Address = 0x004020c9,
>     &(dwSymOffset = 0x00000000),
>     (pSymbol->Name = '')
>     ); ==> Result = 0x00000001
> 
>   ERROR: "Attempt to access invalid address"
> 
>   StackWalk
>     ( ...,
>     global_SymProcess = 0x7fffffff,
>     hThread = 0xfffffffe,
>     {sfStackFrame.AddrPC.Offset = 0xbff8b537},
>     ...); ==> Result = 1
> 
>   SymGetSymFromAddr
> 
> 
>     global_SymProcess = 0x7fffffff,
>     ui32_Address = 0xbff8b537,
>     &(dwSymOffset = 0x00000000),
>     (pSymbol->Name = '')
>     ); ==> Result = 0x00000001
> 
>   ERROR: "Attempt to access invalid address"
> 
> 
> 
> Closing Comments:
> -----------------
> 
> The stack walking looks fine!  The addresses fall within the 
> various *.DLL
> files.
> I'm sure I could convert the addresses to functions by hand;  
> i.e., I am
> confident that the addresses are valid.
> 
> I initiatialized the structure size field in the symbol structure
> (which wasn't done in the original version of the code)
> for SymGetSymFromAddr().
> 
> The process handle is the same as that used to initialize the
> symbol handler -- and if I try using a different handle,
> the function reports (via GetLastError()) "invalid handle".
> 
> What could this be?!  What is the "Attempt to access invalid address"
> reported by SymGetSymFromAddr() (via GetLastError())?
> 
> I also tried using the exact address of an existing symbol
> in the SymGetSymFromAddr(), just as a sanity check...
> But there was no sanity!  It also resulted in the
> "Attempt to access invalid address" error.
> 
> All of this is under Windows 98, using Visual C++ 6.0 Professional,
> with Service Pack 5.  I never explicitly installed a different
> version of "imagehlp.{dll,lib,h}" -- although VC++ 6.0 SP5 may
> have overwritten the version that shipped with VC++ 6.0.
> 
> I'd step in to SymGetSymFromAddr()...IF I KNEW HOW!!! ;-)
> 
> --- Colin
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=555
> 

RE: [GD-Windows] Finding routine that's crashing

[Brian S. <bs...@mi...>]

dbghelp was the old name of the dll, i think it became imagehlp around
the win2000 timeframe.  your best bet if you want this to work on all
platforms is to bind dynamically to one dll or the other (whichever one
you can find) and load the entry points you want manually.  i remember
that at least one useful entry point doesn't exist in dbghelp...sorry
can't remember the specifics.

i do remember this being a pain in the ass to get working on 9x.  i know
i have a version of this at home somewhere.  i will try to dig it up
tonight and send it out.

--brian

> -----Original Message-----
> From: Colin Fahey [mailto:cp...@ea...]=20
> Sent: Friday, August 02, 2002 2:03 AM
> To: Gam...@li...
> Subject: Re: [GD-Windows] Finding routine that's crashing
>=20
>=20
> 2002 August 2nd
> Friday
>=20
> Help!
>=20
> First, I'm going to reply to my own post, contradicting and
> criticizing myself.
>=20
> >>> [1] Under Windows 98, the DLL with the symbol handler and
> >>>   StackWalk() functions is called: "imagehlp.dll".
> >>>   (i.e., different from the "dbghelp.dll" references
> >>>   scattered around the source and project settings)
>=20
> Okay, the first part is true, but the posted code doesn't
> mention "dbghelp.dll" anywhere!  I was just confused.
> After I couldn't get the posted code to work, I downloaded
> a completely different project (Bugslayer1000), and *THAT*
> project had "dbghelp.dll" all over the place!
>=20
>=20
> >>> [2] Under Windows 98, we need the process **ID** for
> >>>   SymInitialize(), NOT the process handle.
> >>>   (See MSDN Library documentation for SymInitialize().)
>=20
> This really was in the documentation, but I'm getting
> mixed signals from the code...
>=20
>   (a) If I use the process ID (following MSDN
>       documentation on SymInitialize()), the StackWalk()
>       stops walking after a single iteration!  The symbol
>       lookup returns an empty symbol string, but doesn't
>       complain about accessing an invalid address.
>=20
>   (b) If I use hProcess handle (contradicting MSDN
>       documentation on SymInitialize()), the StackWalk()
>       walks up the stack just fine (apparently)!  The symbol
>       lookup fails (complain about accessing an invalid address).
>=20
>=20
> I'd really like to get the code working, just as an educational
> example.
>=20
> Here's a kind of trace of what happened:
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> (NOTE: The following trace assumes that we can get away with
> using hProcess for the symbol handler (contradicting the
> documentation).  The trace with the process ID as symbol
> handler and StackWalk parameter is similar, but ends
> with a whimper: StackWalk() ends its walk immediately,
> and SymGetSymFromAddr() returns nothing!)
>=20
> When my test application starts executing:
> ------------------------------------------
>=20
> ENTER ExceptionHandler::ExceptionHandler()
>=20
>   ENTER ExceptionHandler::InitClass()
>   LEAVE ExceptionHandler::InitClass()
>=20
>   ENTER ExceptionHandler::InitDLL()
>     global_hProcess   =3D 0x7fffffff
>     global_ProcessId  =3D 0xfffcfd73
>     global_SymProcess =3D 0x7fffffff
>     mHImageHlpDll =3D LoadLibrary("imagehlp.dll"); =3D 0x7d750000
>   LEAVE ExceptionHandler::InitDLL()
>=20
>   Dir with executable:
> 'C:\WINDOWS\DESKTOP\ASSERT_CODE\TEST_ASSERT\DEBUG\TEST_ASSERT.EXE'
>=20
> LEAVE ExceptionHandler::ExceptionHandler()
>=20
>=20
>=20
> When my test application calls ASSERTx(...):
> --------------------------------------------
>=20
> ENTER ExceptionHandler::DumpCrash(HANDLE hThread =3D 0xfffffffe, void*
> pExceptionInfo =3D 0x0065f8c0)
>=20
>   About to do
>     SymInitialize
>=20
>=20
>      0x7fffffff,
>=20
> "C:\WINDOWS\Desktop\assert_code\test_assert\Debug;C:\WINDOWS\D
> ESKTOP\ASSERT_
> CODE\TEST_ASSERT\DEBUG;",
>      FALSE
>      );
>=20
>   About to do
>      SymSetOptions(SYMOPT_LOAD_LINES | SYMOPT_UNDNAME |
> SYMOPT_CASE_INSENSITIVE);
>=20
>   About to do
>      enumAndLoadModuleSymbols( global_hProcess, global_ProcessId );
>=20
>=20
>   ENTER void enumAndLoadModuleSymbols( HANDLE hProcess =3D=20
> 0x7fffffff, DWORD
> pid =3D 0xfffcfd73 );
>=20
> . . .
> . . .
> . . .
>     sSymLoadModule
>=20
>=20
>       global_SymProcess =3D 0x7fffffff,
>       0,
>      =20
> =
img=3D'C:\WINDOWS\DESKTOP\ASSERT_CODE\TEST_ASSERT\DEBUG\STDASSERT.DLL',
>       mod=3D'STDASSERT.DLL',
>       base=3D0x10000000,
>       size=3D311296
>       ); =3D=3D> Result =3D 0x10000000
>=20
>     sSymLoadModule
>=20
>=20
>       global_SymProcess =3D 0x7fffffff,
>       0,
>=20
> img=3D'C:\WINDOWS\DESKTOP\ASSERT_CODE\TEST_ASSERT\DEBUG\TEST_ASS
> ERT.EXE',
>       mod=3D'TEST_ASSERT.EXE',
>       base=3D0x00400000,
>       size=3D180224
>       ); =3D=3D> Result =3D 0x00400000
>=20
>     sSymLoadModule
>=20
>=20
>       global_SymProcess =3D 0x7fffffff,
>       0,
>       img=3D'C:\WINDOWS\SYSTEM\KERNEL32.DLL',
>       mod=3D'KERNEL32.DLL',
>       base=3D0xbff70000,
>       size=3D471040
>       ); =3D=3D> Result =3D 0xbff70000
> . . .
>=20
> LEAVE void enumAndLoadModuleSymbols( HANDLE hProcess =3D=20
> 0x7fffffff, DWORD pid
> =3D 0xfffcfd73 );
>=20
>=20
> (Back in ExceptionHandler::DumpCrash()...)
>=20
>=20
>   StackWalk
>     ( ...,
>     global_SymProcess =3D 0x7fffffff,
>     hThread =3D 0xfffffffe,
>     {sfStackFrame.AddrPC.Offset =3D 0x100042b3},
>     ...); =3D=3D> Result =3D 1
>=20
>   SymGetSymFromAddr
>=20
>=20
>     global_SymProcess =3D 0x7fffffff,
>     ui32_Address =3D 0x100042b3,
>     &(dwSymOffset =3D 0x00000000),
>     (pSymbol->Name =3D '')
>     ); =3D=3D> Result =3D 0x00000001
>=20
>   ERROR: "Attempt to access invalid address"
>=20
>   StackWalk
>     ( ...,
>     global_SymProcess =3D 0x7fffffff,
>     hThread =3D 0xfffffffe,
>     {sfStackFrame.AddrPC.Offset =3D 0x004012c0},
>     ...); =3D=3D> Result =3D 1
>=20
>   SymGetSymFromAddr
>=20
>=20
>     global_SymProcess =3D 0x7fffffff,
>     ui32_Address =3D 0x004012c0,
>     &(dwSymOffset =3D 0x00000000),
>     (pSymbol->Name =3D '')
>     ); =3D=3D> Result =3D 0x00000001
>=20
>   ERROR: "Attempt to access invalid address"
>=20
>   StackWalk
>     ( ...,
>     global_SymProcess =3D 0x7fffffff,
>     hThread =3D 0xfffffffe,
>     {sfStackFrame.AddrPC.Offset =3D 0x0040139e},
>     ...); =3D=3D> Result =3D 1
>=20
>   SymGetSymFromAddr
>=20
>=20
>     global_SymProcess =3D 0x7fffffff,
>     ui32_Address =3D 0x0040139e,
>     &(dwSymOffset =3D 0x00000000),
>     (pSymbol->Name =3D '')
>     ); =3D=3D> Result =3D 0x00000001
>=20
>   ERROR: "Attempt to access invalid address"
>=20
>   StackWalk
>     ( ...,
>     global_SymProcess =3D 0x7fffffff,
>     hThread =3D 0xfffffffe,
>     {sfStackFrame.AddrPC.Offset =3D 0x004013fd},
>     ...); =3D=3D> Result =3D 1
>=20
>   SymGetSymFromAddr
>=20
>=20
>     global_SymProcess =3D 0x7fffffff,
>     ui32_Address =3D 0x004013fd,
>     &(dwSymOffset =3D 0x00000000),
>     (pSymbol->Name =3D '')
>     ); =3D=3D> Result =3D 0x00000001
>=20
>   ERROR: "Attempt to access invalid address"
>=20
>   StackWalk
>     ( ...,
>     global_SymProcess =3D 0x7fffffff,
>     hThread =3D 0xfffffffe,
>     {sfStackFrame.AddrPC.Offset =3D 0x0040144a},
>     ...); =3D=3D> Result =3D 1
>=20
>   SymGetSymFromAddr
>=20
>=20
>     global_SymProcess =3D 0x7fffffff,
>     ui32_Address =3D 0x0040144a,
>     &(dwSymOffset =3D 0x00000000),
>     (pSymbol->Name =3D '')
>     ); =3D=3D> Result =3D 0x00000001
>=20
>   ERROR: "Attempt to access invalid address"
>=20
>   StackWalk
>     ( ...,
>     global_SymProcess =3D 0x7fffffff,
>     hThread =3D 0xfffffffe,
>     {sfStackFrame.AddrPC.Offset =3D 0x004020c9},
>     ...); =3D=3D> Result =3D 1
>=20
>   SymGetSymFromAddr
>=20
>=20
>     global_SymProcess =3D 0x7fffffff,
>     ui32_Address =3D 0x004020c9,
>     &(dwSymOffset =3D 0x00000000),
>     (pSymbol->Name =3D '')
>     ); =3D=3D> Result =3D 0x00000001
>=20
>   ERROR: "Attempt to access invalid address"
>=20
>   StackWalk
>     ( ...,
>     global_SymProcess =3D 0x7fffffff,
>     hThread =3D 0xfffffffe,
>     {sfStackFrame.AddrPC.Offset =3D 0xbff8b537},
>     ...); =3D=3D> Result =3D 1
>=20
>   SymGetSymFromAddr
>=20
>=20
>     global_SymProcess =3D 0x7fffffff,
>     ui32_Address =3D 0xbff8b537,
>     &(dwSymOffset =3D 0x00000000),
>     (pSymbol->Name =3D '')
>     ); =3D=3D> Result =3D 0x00000001
>=20
>   ERROR: "Attempt to access invalid address"
>=20
>=20
>=20
> Closing Comments:
> -----------------
>=20
> The stack walking looks fine!  The addresses fall within the=20
> various *.DLL
> files.
> I'm sure I could convert the addresses to functions by hand; =20
> i.e., I am
> confident that the addresses are valid.
>=20
> I initiatialized the structure size field in the symbol structure
> (which wasn't done in the original version of the code)
> for SymGetSymFromAddr().
>=20
> The process handle is the same as that used to initialize the
> symbol handler -- and if I try using a different handle,
> the function reports (via GetLastError()) "invalid handle".
>=20
> What could this be?!  What is the "Attempt to access invalid address"
> reported by SymGetSymFromAddr() (via GetLastError())?
>=20
> I also tried using the exact address of an existing symbol
> in the SymGetSymFromAddr(), just as a sanity check...
> But there was no sanity!  It also resulted in the
> "Attempt to access invalid address" error.
>=20
> All of this is under Windows 98, using Visual C++ 6.0 Professional,
> with Service Pack 5.  I never explicitly installed a different
> version of "imagehlp.{dll,lib,h}" -- although VC++ 6.0 SP5 may
> have overwritten the version that shipped with VC++ 6.0.
>=20
> I'd step in to SymGetSymFromAddr()...IF I KNEW HOW!!! ;-)
>=20
> --- Colin
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=3D555
>=20

RE: [GD-Windows] Finding routine that's crashing

[Grills, J. <jg...@so...>]

Actually, I think the old name was ImageHlp, and the new name is DbgHelp.
I'm pretty sure DbgHelp is redistributable, so you can include it with your
app to make sure it's always there, no matter what OS you're on.  We use a
newer version of the DLL that has a working MiniDumpWriteDump function.
That's another awesome function you guys should become familiar with.

j

-----Original Message-----
From: Brian Sharon [mailto:bs...@mi...]
Sent: Friday, August 02, 2002 11:41 AM
To: Colin Fahey; Gam...@li...
Subject: RE: [GD-Windows] Finding routine that's crashing


dbghelp was the old name of the dll, i think it became imagehlp around
the win2000 timeframe.  your best bet if you want this to work on all
platforms is to bind dynamically to one dll or the other (whichever one
you can find) and load the entry points you want manually.  i remember
that at least one useful entry point doesn't exist in dbghelp...sorry
can't remember the specifics.

i do remember this being a pain in the ass to get working on 9x.  i know
i have a version of this at home somewhere.  i will try to dig it up
tonight and send it out.

--brian

> -----Original Message-----
> From: Colin Fahey [mailto:cp...@ea...] 
> Sent: Friday, August 02, 2002 2:03 AM
> To: Gam...@li...
> Subject: Re: [GD-Windows] Finding routine that's crashing
> 
> 
> 2002 August 2nd
> Friday
> 
> Help!
> 
> First, I'm going to reply to my own post, contradicting and
> criticizing myself.
> 
> >>> [1] Under Windows 98, the DLL with the symbol handler and
> >>>   StackWalk() functions is called: "imagehlp.dll".
> >>>   (i.e., different from the "dbghelp.dll" references
> >>>   scattered around the source and project settings)
> 
> Okay, the first part is true, but the posted code doesn't
> mention "dbghelp.dll" anywhere!  I was just confused.
> After I couldn't get the posted code to work, I downloaded
> a completely different project (Bugslayer1000), and *THAT*
> project had "dbghelp.dll" all over the place!
> 
> 
> >>> [2] Under Windows 98, we need the process **ID** for
> >>>   SymInitialize(), NOT the process handle.
> >>>   (See MSDN Library documentation for SymInitialize().)
> 
> This really was in the documentation, but I'm getting
> mixed signals from the code...
> 
>   (a) If I use the process ID (following MSDN
>       documentation on SymInitialize()), the StackWalk()
>       stops walking after a single iteration!  The symbol
>       lookup returns an empty symbol string, but doesn't
>       complain about accessing an invalid address.
> 
>   (b) If I use hProcess handle (contradicting MSDN
>       documentation on SymInitialize()), the StackWalk()
>       walks up the stack just fine (apparently)!  The symbol
>       lookup fails (complain about accessing an invalid address).
> 
> 
> I'd really like to get the code working, just as an educational
> example.
> 
> Here's a kind of trace of what happened:
> ========================================
> 
> (NOTE: The following trace assumes that we can get away with
> using hProcess for the symbol handler (contradicting the
> documentation).  The trace with the process ID as symbol
> handler and StackWalk parameter is similar, but ends
> with a whimper: StackWalk() ends its walk immediately,
> and SymGetSymFromAddr() returns nothing!)
> 
> When my test application starts executing:
> ------------------------------------------
> 
> ENTER ExceptionHandler::ExceptionHandler()
> 
>   ENTER ExceptionHandler::InitClass()
>   LEAVE ExceptionHandler::InitClass()
> 
>   ENTER ExceptionHandler::InitDLL()
>     global_hProcess   = 0x7fffffff
>     global_ProcessId  = 0xfffcfd73
>     global_SymProcess = 0x7fffffff
>     mHImageHlpDll = LoadLibrary("imagehlp.dll"); = 0x7d750000
>   LEAVE ExceptionHandler::InitDLL()
> 
>   Dir with executable:
> 'C:\WINDOWS\DESKTOP\ASSERT_CODE\TEST_ASSERT\DEBUG\TEST_ASSERT.EXE'
> 
> LEAVE ExceptionHandler::ExceptionHandler()
> 
> 
> 
> When my test application calls ASSERTx(...):
> --------------------------------------------
> 
> ENTER ExceptionHandler::DumpCrash(HANDLE hThread = 0xfffffffe, void*
> pExceptionInfo = 0x0065f8c0)
> 
>   About to do
>     SymInitialize
> 
> 
>      0x7fffffff,
> 
> "C:\WINDOWS\Desktop\assert_code\test_assert\Debug;C:\WINDOWS\D
> ESKTOP\ASSERT_
> CODE\TEST_ASSERT\DEBUG;",
>      FALSE
>      );
> 
>   About to do
>      SymSetOptions(SYMOPT_LOAD_LINES | SYMOPT_UNDNAME |
> SYMOPT_CASE_INSENSITIVE);
> 
>   About to do
>      enumAndLoadModuleSymbols( global_hProcess, global_ProcessId );
> 
> 
>   ENTER void enumAndLoadModuleSymbols( HANDLE hProcess = 
> 0x7fffffff, DWORD
> pid = 0xfffcfd73 );
> 
> . . .
> . . .
> . . .
>     sSymLoadModule
> 
> 
>       global_SymProcess = 0x7fffffff,
>       0,
>       
> img='C:\WINDOWS\DESKTOP\ASSERT_CODE\TEST_ASSERT\DEBUG\STDASSERT.DLL',
>       mod='STDASSERT.DLL',
>       base=0x10000000,
>       size=311296
>       ); ==> Result = 0x10000000
> 
>     sSymLoadModule
> 
> 
>       global_SymProcess = 0x7fffffff,
>       0,
> 
> img='C:\WINDOWS\DESKTOP\ASSERT_CODE\TEST_ASSERT\DEBUG\TEST_ASS
> ERT.EXE',
>       mod='TEST_ASSERT.EXE',
>       base=0x00400000,
>       size=180224
>       ); ==> Result = 0x00400000
> 
>     sSymLoadModule
> 
> 
>       global_SymProcess = 0x7fffffff,
>       0,
>       img='C:\WINDOWS\SYSTEM\KERNEL32.DLL',
>       mod='KERNEL32.DLL',
>       base=0xbff70000,
>       size=471040
>       ); ==> Result = 0xbff70000
> . . .
> 
> LEAVE void enumAndLoadModuleSymbols( HANDLE hProcess = 
> 0x7fffffff, DWORD pid
> = 0xfffcfd73 );
> 
> 
> (Back in ExceptionHandler::DumpCrash()...)
> 
> 
>   StackWalk
>     ( ...,
>     global_SymProcess = 0x7fffffff,
>     hThread = 0xfffffffe,
>     {sfStackFrame.AddrPC.Offset = 0x100042b3},
>     ...); ==> Result = 1
> 
>   SymGetSymFromAddr
> 
> 
>     global_SymProcess = 0x7fffffff,
>     ui32_Address = 0x100042b3,
>     &(dwSymOffset = 0x00000000),
>     (pSymbol->Name = '')
>     ); ==> Result = 0x00000001
> 
>   ERROR: "Attempt to access invalid address"
> 
>   StackWalk
>     ( ...,
>     global_SymProcess = 0x7fffffff,
>     hThread = 0xfffffffe,
>     {sfStackFrame.AddrPC.Offset = 0x004012c0},
>     ...); ==> Result = 1
> 
>   SymGetSymFromAddr
> 
> 
>     global_SymProcess = 0x7fffffff,
>     ui32_Address = 0x004012c0,
>     &(dwSymOffset = 0x00000000),
>     (pSymbol->Name = '')
>     ); ==> Result = 0x00000001
> 
>   ERROR: "Attempt to access invalid address"
> 
>   StackWalk
>     ( ...,
>     global_SymProcess = 0x7fffffff,
>     hThread = 0xfffffffe,
>     {sfStackFrame.AddrPC.Offset = 0x0040139e},
>     ...); ==> Result = 1
> 
>   SymGetSymFromAddr
> 
> 
>     global_SymProcess = 0x7fffffff,
>     ui32_Address = 0x0040139e,
>     &(dwSymOffset = 0x00000000),
>     (pSymbol->Name = '')
>     ); ==> Result = 0x00000001
> 
>   ERROR: "Attempt to access invalid address"
> 
>   StackWalk
>     ( ...,
>     global_SymProcess = 0x7fffffff,
>     hThread = 0xfffffffe,
>     {sfStackFrame.AddrPC.Offset = 0x004013fd},
>     ...); ==> Result = 1
> 
>   SymGetSymFromAddr
> 
> 
>     global_SymProcess = 0x7fffffff,
>     ui32_Address = 0x004013fd,
>     &(dwSymOffset = 0x00000000),
>     (pSymbol->Name = '')
>     ); ==> Result = 0x00000001
> 
>   ERROR: "Attempt to access invalid address"
> 
>   StackWalk
>     ( ...,
>     global_SymProcess = 0x7fffffff,
>     hThread = 0xfffffffe,
>     {sfStackFrame.AddrPC.Offset = 0x0040144a},
>     ...); ==> Result = 1
> 
>   SymGetSymFromAddr
> 
> 
>     global_SymProcess = 0x7fffffff,
>     ui32_Address = 0x0040144a,
>     &(dwSymOffset = 0x00000000),
>     (pSymbol->Name = '')
>     ); ==> Result = 0x00000001
> 
>   ERROR: "Attempt to access invalid address"
> 
>   StackWalk
>     ( ...,
>     global_SymProcess = 0x7fffffff,
>     hThread = 0xfffffffe,
>     {sfStackFrame.AddrPC.Offset = 0x004020c9},
>     ...); ==> Result = 1
> 
>   SymGetSymFromAddr
> 
> 
>     global_SymProcess = 0x7fffffff,
>     ui32_Address = 0x004020c9,
>     &(dwSymOffset = 0x00000000),
>     (pSymbol->Name = '')
>     ); ==> Result = 0x00000001
> 
>   ERROR: "Attempt to access invalid address"
> 
>   StackWalk
>     ( ...,
>     global_SymProcess = 0x7fffffff,
>     hThread = 0xfffffffe,
>     {sfStackFrame.AddrPC.Offset = 0xbff8b537},
>     ...); ==> Result = 1
> 
>   SymGetSymFromAddr
> 
> 
>     global_SymProcess = 0x7fffffff,
>     ui32_Address = 0xbff8b537,
>     &(dwSymOffset = 0x00000000),
>     (pSymbol->Name = '')
>     ); ==> Result = 0x00000001
> 
>   ERROR: "Attempt to access invalid address"
> 
> 
> 
> Closing Comments:
> -----------------
> 
> The stack walking looks fine!  The addresses fall within the 
> various *.DLL
> files.
> I'm sure I could convert the addresses to functions by hand;  
> i.e., I am
> confident that the addresses are valid.
> 
> I initiatialized the structure size field in the symbol structure
> (which wasn't done in the original version of the code)
> for SymGetSymFromAddr().
> 
> The process handle is the same as that used to initialize the
> symbol handler -- and if I try using a different handle,
> the function reports (via GetLastError()) "invalid handle".
> 
> What could this be?!  What is the "Attempt to access invalid address"
> reported by SymGetSymFromAddr() (via GetLastError())?
> 
> I also tried using the exact address of an existing symbol
> in the SymGetSymFromAddr(), just as a sanity check...
> But there was no sanity!  It also resulted in the
> "Attempt to access invalid address" error.
> 
> All of this is under Windows 98, using Visual C++ 6.0 Professional,
> with Service Pack 5.  I never explicitly installed a different
> version of "imagehlp.{dll,lib,h}" -- although VC++ 6.0 SP5 may
> have overwritten the version that shipped with VC++ 6.0.
> 
> I'd step in to SymGetSymFromAddr()...IF I KNEW HOW!!! ;-)
> 
> --- Colin
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=555
> 


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Gamedevlists-windows mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_idU5

Re: [GD-Windows] Finding routine that's crashing

[Colin F. <cp...@ea...>]

2002 August 2nd
Friday

>>> Actually, I think the old name was ImageHlp, and the new name is
DbgHelp.
>>> I'm pretty sure DbgHelp is redistributable, so you can include it with
your
>>> app to make sure it's always there, no matter what OS you're on.


[1] Can I just copy the "dbghelp.dll" (and LIB and H) from my
Windows 2000 machine to my Windows 98 machine?  (Assume I
modify my code to link to dbghelp.lib and load dbghelp.dll.)


[2] Under Window 98 (special case) with "dbghelp.dll", should
I use the process **ID** or should I use the process **HANDLE**
for SymInitialize(), StackWalk(), etc?

  (NOTE: Windows 98 case is potentially different from
    Windows 2000, Windows Me, Windows XP cases.)


--- Colin
cp...@ea...

Re: [GD-Windows] Finding routine that's crashing

[Rich <leg...@xm...>]

In article <9EA...@ma...>,
    "Grills, Jeff" <jg...@so...>  writes:

> newer version of the DLL that has a working MiniDumpWriteDump function.
> That's another awesome function you guys should become familiar with.

Speaking of which... I hear that the XP team is working on a way to
let your company receive those crash reports that are collected
automatically by XP when a program bombs out.  (I think it collects a
minidump, I'm not entirely sure; I don't have XP installed on anything
yet.)
-- 
Ask me about my upcoming book on Direct3D from Addison-Wesley!
  Direct3D Book <http://www.xmission.com/~legalize/book/>
    izfree: Open source tools for Windows Installer
            <http://izfree.sourceforge.net>

RE: [GD-Windows] Finding routine that's crashing

[Brian S. <bs...@mi...>]

Yes, I had those names flip-flopped, sorry for the confusion.  Too much
time on Xbox :)

Are you tearing apart the mini-dump files yourself or just loading them
into the VS.NET debugger?  I haven't looked at the file format.

--brian

> -----Original Message-----
> From: Grills, Jeff [mailto:jg...@so...]=20
> Sent: Friday, August 02, 2002 9:53 AM
> To: Brian Sharon; Colin Fahey;=20
> Gam...@li...
> Subject: RE: [GD-Windows] Finding routine that's crashing
>=20
>=20
>=20
> Actually, I think the old name was ImageHlp, and the new name=20
> is DbgHelp.
> I'm pretty sure DbgHelp is redistributable, so you can=20
> include it with your
> app to make sure it's always there, no matter what OS you're=20
> on.  We use a
> newer version of the DLL that has a working MiniDumpWriteDump=20
> function.
> That's another awesome function you guys should become familiar with.
>=20
> j
>=20
> -----Original Message-----
> From: Brian Sharon [mailto:bs...@mi...]
> Sent: Friday, August 02, 2002 11:41 AM
> To: Colin Fahey; Gam...@li...
> Subject: RE: [GD-Windows] Finding routine that's crashing
>=20
>=20
> dbghelp was the old name of the dll, i think it became imagehlp around
> the win2000 timeframe.  your best bet if you want this to work on all
> platforms is to bind dynamically to one dll or the other=20
> (whichever one
> you can find) and load the entry points you want manually.  i remember
> that at least one useful entry point doesn't exist in dbghelp...sorry
> can't remember the specifics.
>=20
> i do remember this being a pain in the ass to get working on=20
> 9x.  i know
> i have a version of this at home somewhere.  i will try to dig it up
> tonight and send it out.
>=20
> --brian
>=20
> > -----Original Message-----
> > From: Colin Fahey [mailto:cp...@ea...]=20
> > Sent: Friday, August 02, 2002 2:03 AM
> > To: Gam...@li...
> > Subject: Re: [GD-Windows] Finding routine that's crashing
> >=20
> >=20
> > 2002 August 2nd
> > Friday
> >=20
> > Help!
> >=20
> > First, I'm going to reply to my own post, contradicting and
> > criticizing myself.
> >=20
> > >>> [1] Under Windows 98, the DLL with the symbol handler and
> > >>>   StackWalk() functions is called: "imagehlp.dll".
> > >>>   (i.e., different from the "dbghelp.dll" references
> > >>>   scattered around the source and project settings)
> >=20
> > Okay, the first part is true, but the posted code doesn't
> > mention "dbghelp.dll" anywhere!  I was just confused.
> > After I couldn't get the posted code to work, I downloaded
> > a completely different project (Bugslayer1000), and *THAT*
> > project had "dbghelp.dll" all over the place!
> >=20
> >=20
> > >>> [2] Under Windows 98, we need the process **ID** for
> > >>>   SymInitialize(), NOT the process handle.
> > >>>   (See MSDN Library documentation for SymInitialize().)
> >=20
> > This really was in the documentation, but I'm getting
> > mixed signals from the code...
> >=20
> >   (a) If I use the process ID (following MSDN
> >       documentation on SymInitialize()), the StackWalk()
> >       stops walking after a single iteration!  The symbol
> >       lookup returns an empty symbol string, but doesn't
> >       complain about accessing an invalid address.
> >=20
> >   (b) If I use hProcess handle (contradicting MSDN
> >       documentation on SymInitialize()), the StackWalk()
> >       walks up the stack just fine (apparently)!  The symbol
> >       lookup fails (complain about accessing an invalid address).
> >=20
> >=20
> > I'd really like to get the code working, just as an educational
> > example.
> >=20
> > Here's a kind of trace of what happened:
> > =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >=20
> > (NOTE: The following trace assumes that we can get away with
> > using hProcess for the symbol handler (contradicting the
> > documentation).  The trace with the process ID as symbol
> > handler and StackWalk parameter is similar, but ends
> > with a whimper: StackWalk() ends its walk immediately,
> > and SymGetSymFromAddr() returns nothing!)
> >=20
> > When my test application starts executing:
> > ------------------------------------------
> >=20
> > ENTER ExceptionHandler::ExceptionHandler()
> >=20
> >   ENTER ExceptionHandler::InitClass()
> >   LEAVE ExceptionHandler::InitClass()
> >=20
> >   ENTER ExceptionHandler::InitDLL()
> >     global_hProcess   =3D 0x7fffffff
> >     global_ProcessId  =3D 0xfffcfd73
> >     global_SymProcess =3D 0x7fffffff
> >     mHImageHlpDll =3D LoadLibrary("imagehlp.dll"); =3D 0x7d750000
> >   LEAVE ExceptionHandler::InitDLL()
> >=20
> >   Dir with executable:
> > 'C:\WINDOWS\DESKTOP\ASSERT_CODE\TEST_ASSERT\DEBUG\TEST_ASSERT.EXE'
> >=20
> > LEAVE ExceptionHandler::ExceptionHandler()
> >=20
> >=20
> >=20
> > When my test application calls ASSERTx(...):
> > --------------------------------------------
> >=20
> > ENTER ExceptionHandler::DumpCrash(HANDLE hThread =3D 0xfffffffe, =
void*
> > pExceptionInfo =3D 0x0065f8c0)
> >=20
> >   About to do
> >     SymInitialize
> >=20
> >=20
> >      0x7fffffff,
> >=20
> > "C:\WINDOWS\Desktop\assert_code\test_assert\Debug;C:\WINDOWS\D
> > ESKTOP\ASSERT_
> > CODE\TEST_ASSERT\DEBUG;",
> >      FALSE
> >      );
> >=20
> >   About to do
> >      SymSetOptions(SYMOPT_LOAD_LINES | SYMOPT_UNDNAME |
> > SYMOPT_CASE_INSENSITIVE);
> >=20
> >   About to do
> >      enumAndLoadModuleSymbols( global_hProcess, global_ProcessId );
> >=20
> >=20
> >   ENTER void enumAndLoadModuleSymbols( HANDLE hProcess =3D=20
> > 0x7fffffff, DWORD
> > pid =3D 0xfffcfd73 );
> >=20
> > . . .
> > . . .
> > . . .
> >     sSymLoadModule
> >=20
> >=20
> >       global_SymProcess =3D 0x7fffffff,
> >       0,
> >      =20
> >=20
> =
img=3D'C:\WINDOWS\DESKTOP\ASSERT_CODE\TEST_ASSERT\DEBUG\STDASSERT.DLL',
> >       mod=3D'STDASSERT.DLL',
> >       base=3D0x10000000,
> >       size=3D311296
> >       ); =3D=3D> Result =3D 0x10000000
> >=20
> >     sSymLoadModule
> >=20
> >=20
> >       global_SymProcess =3D 0x7fffffff,
> >       0,
> >=20
> > img=3D'C:\WINDOWS\DESKTOP\ASSERT_CODE\TEST_ASSERT\DEBUG\TEST_ASS
> > ERT.EXE',
> >       mod=3D'TEST_ASSERT.EXE',
> >       base=3D0x00400000,
> >       size=3D180224
> >       ); =3D=3D> Result =3D 0x00400000
> >=20
> >     sSymLoadModule
> >=20
> >=20
> >       global_SymProcess =3D 0x7fffffff,
> >       0,
> >       img=3D'C:\WINDOWS\SYSTEM\KERNEL32.DLL',
> >       mod=3D'KERNEL32.DLL',
> >       base=3D0xbff70000,
> >       size=3D471040
> >       ); =3D=3D> Result =3D 0xbff70000
> > . . .
> >=20
> > LEAVE void enumAndLoadModuleSymbols( HANDLE hProcess =3D=20
> > 0x7fffffff, DWORD pid
> > =3D 0xfffcfd73 );
> >=20
> >=20
> > (Back in ExceptionHandler::DumpCrash()...)
> >=20
> >=20
> >   StackWalk
> >     ( ...,
> >     global_SymProcess =3D 0x7fffffff,
> >     hThread =3D 0xfffffffe,
> >     {sfStackFrame.AddrPC.Offset =3D 0x100042b3},
> >     ...); =3D=3D> Result =3D 1
> >=20
> >   SymGetSymFromAddr
> >=20
> >=20
> >     global_SymProcess =3D 0x7fffffff,
> >     ui32_Address =3D 0x100042b3,
> >     &(dwSymOffset =3D 0x00000000),
> >     (pSymbol->Name =3D '')
> >     ); =3D=3D> Result =3D 0x00000001
> >=20
> >   ERROR: "Attempt to access invalid address"
> >=20
> >   StackWalk
> >     ( ...,
> >     global_SymProcess =3D 0x7fffffff,
> >     hThread =3D 0xfffffffe,
> >     {sfStackFrame.AddrPC.Offset =3D 0x004012c0},
> >     ...); =3D=3D> Result =3D 1
> >=20
> >   SymGetSymFromAddr
> >=20
> >=20
> >     global_SymProcess =3D 0x7fffffff,
> >     ui32_Address =3D 0x004012c0,
> >     &(dwSymOffset =3D 0x00000000),
> >     (pSymbol->Name =3D '')
> >     ); =3D=3D> Result =3D 0x00000001
> >=20
> >   ERROR: "Attempt to access invalid address"
> >=20
> >   StackWalk
> >     ( ...,
> >     global_SymProcess =3D 0x7fffffff,
> >     hThread =3D 0xfffffffe,
> >     {sfStackFrame.AddrPC.Offset =3D 0x0040139e},
> >     ...); =3D=3D> Result =3D 1
> >=20
> >   SymGetSymFromAddr
> >=20
> >=20
> >     global_SymProcess =3D 0x7fffffff,
> >     ui32_Address =3D 0x0040139e,
> >     &(dwSymOffset =3D 0x00000000),
> >     (pSymbol->Name =3D '')
> >     ); =3D=3D> Result =3D 0x00000001
> >=20
> >   ERROR: "Attempt to access invalid address"
> >=20
> >   StackWalk
> >     ( ...,
> >     global_SymProcess =3D 0x7fffffff,
> >     hThread =3D 0xfffffffe,
> >     {sfStackFrame.AddrPC.Offset =3D 0x004013fd},
> >     ...); =3D=3D> Result =3D 1
> >=20
> >   SymGetSymFromAddr
> >=20
> >=20
> >     global_SymProcess =3D 0x7fffffff,
> >     ui32_Address =3D 0x004013fd,
> >     &(dwSymOffset =3D 0x00000000),
> >     (pSymbol->Name =3D '')
> >     ); =3D=3D> Result =3D 0x00000001
> >=20
> >   ERROR: "Attempt to access invalid address"
> >=20
> >   StackWalk
> >     ( ...,
> >     global_SymProcess =3D 0x7fffffff,
> >     hThread =3D 0xfffffffe,
> >     {sfStackFrame.AddrPC.Offset =3D 0x0040144a},
> >     ...); =3D=3D> Result =3D 1
> >=20
> >   SymGetSymFromAddr
> >=20
> >=20
> >     global_SymProcess =3D 0x7fffffff,
> >     ui32_Address =3D 0x0040144a,
> >     &(dwSymOffset =3D 0x00000000),
> >     (pSymbol->Name =3D '')
> >     ); =3D=3D> Result =3D 0x00000001
> >=20
> >   ERROR: "Attempt to access invalid address"
> >=20
> >   StackWalk
> >     ( ...,
> >     global_SymProcess =3D 0x7fffffff,
> >     hThread =3D 0xfffffffe,
> >     {sfStackFrame.AddrPC.Offset =3D 0x004020c9},
> >     ...); =3D=3D> Result =3D 1
> >=20
> >   SymGetSymFromAddr
> >=20
> >=20
> >     global_SymProcess =3D 0x7fffffff,
> >     ui32_Address =3D 0x004020c9,
> >     &(dwSymOffset =3D 0x00000000),
> >     (pSymbol->Name =3D '')
> >     ); =3D=3D> Result =3D 0x00000001
> >=20
> >   ERROR: "Attempt to access invalid address"
> >=20
> >   StackWalk
> >     ( ...,
> >     global_SymProcess =3D 0x7fffffff,
> >     hThread =3D 0xfffffffe,
> >     {sfStackFrame.AddrPC.Offset =3D 0xbff8b537},
> >     ...); =3D=3D> Result =3D 1
> >=20
> >   SymGetSymFromAddr
> >=20
> >=20
> >     global_SymProcess =3D 0x7fffffff,
> >     ui32_Address =3D 0xbff8b537,
> >     &(dwSymOffset =3D 0x00000000),
> >     (pSymbol->Name =3D '')
> >     ); =3D=3D> Result =3D 0x00000001
> >=20
> >   ERROR: "Attempt to access invalid address"
> >=20
> >=20
> >=20
> > Closing Comments:
> > -----------------
> >=20
> > The stack walking looks fine!  The addresses fall within the=20
> > various *.DLL
> > files.
> > I'm sure I could convert the addresses to functions by hand; =20
> > i.e., I am
> > confident that the addresses are valid.
> >=20
> > I initiatialized the structure size field in the symbol structure
> > (which wasn't done in the original version of the code)
> > for SymGetSymFromAddr().
> >=20
> > The process handle is the same as that used to initialize the
> > symbol handler -- and if I try using a different handle,
> > the function reports (via GetLastError()) "invalid handle".
> >=20
> > What could this be?!  What is the "Attempt to access=20
> invalid address"
> > reported by SymGetSymFromAddr() (via GetLastError())?
> >=20
> > I also tried using the exact address of an existing symbol
> > in the SymGetSymFromAddr(), just as a sanity check...
> > But there was no sanity!  It also resulted in the
> > "Attempt to access invalid address" error.
> >=20
> > All of this is under Windows 98, using Visual C++ 6.0 Professional,
> > with Service Pack 5.  I never explicitly installed a different
> > version of "imagehlp.{dll,lib,h}" -- although VC++ 6.0 SP5 may
> > have overwritten the version that shipped with VC++ 6.0.
> >=20
> > I'd step in to SymGetSymFromAddr()...IF I KNEW HOW!!! ;-)
> >=20
> > --- Colin
> >=20
> >=20
> >=20
> >=20
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Gamedevlists-windows mailing list
> > Gam...@li...
> > https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> > Archives:
> > http://sourceforge.net/mailarchive/forum.php?forum_id=3D555
> >=20
>=20
>=20
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_idU5
>=20

RE: [GD-Windows] Finding routine that's crashing

[Jon W. <hp...@mi...>]

WinDBG can open the mini dumps just fine under Win2k. No .NET madness 
needed. WinDBG is, all in all, pretty darn spiffy for being an overgrown 
kernel monitor front-end :-)

Cheers,

				/ h+

> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Brian Sharon
> Sent: Friday, August 02, 2002 10:30 AM
> To: Gam...@li...
> Subject: RE: [GD-Windows] Finding routine that's crashing
> 
> 
> Yes, I had those names flip-flopped, sorry for the confusion.  Too much
> time on Xbox :)
> 
> Are you tearing apart the mini-dump files yourself or just loading them
> into the VS.NET debugger?  I haven't looked at the file format.
> 
> --brian
> 
> > -----Original Message-----
> > From: Grills, Jeff [mailto:jg...@so...] 
> > Sent: Friday, August 02, 2002 9:53 AM
> > To: Brian Sharon; Colin Fahey; 
> > Gam...@li...
> > Subject: RE: [GD-Windows] Finding routine that's crashing
> > 
> > 
> > 
> > Actually, I think the old name was ImageHlp, and the new name 
> > is DbgHelp.
> > I'm pretty sure DbgHelp is redistributable, so you can 
> > include it with your
> > app to make sure it's always there, no matter what OS you're 
> > on.  We use a
> > newer version of the DLL that has a working MiniDumpWriteDump 
> > function.
> > That's another awesome function you guys should become familiar with.
> > 
> > j
> > 
> > -----Original Message-----
> > From: Brian Sharon [mailto:bs...@mi...]
> > Sent: Friday, August 02, 2002 11:41 AM
> > To: Colin Fahey; Gam...@li...
> > Subject: RE: [GD-Windows] Finding routine that's crashing
> > 
> > 
> > dbghelp was the old name of the dll, i think it became imagehlp around
> > the win2000 timeframe.  your best bet if you want this to work on all
> > platforms is to bind dynamically to one dll or the other 
> > (whichever one
> > you can find) and load the entry points you want manually.  i remember
> > that at least one useful entry point doesn't exist in dbghelp...sorry
> > can't remember the specifics.
> > 
> > i do remember this being a pain in the ass to get working on 
> > 9x.  i know
> > i have a version of this at home somewhere.  i will try to dig it up
> > tonight and send it out.
> > 
> > --brian
> > 
> > > -----Original Message-----
> > > From: Colin Fahey [mailto:cp...@ea...] 
> > > Sent: Friday, August 02, 2002 2:03 AM
> > > To: Gam...@li...
> > > Subject: Re: [GD-Windows] Finding routine that's crashing
> > > 
> > > 
> > > 2002 August 2nd
> > > Friday
> > > 
> > > Help!
> > > 
> > > First, I'm going to reply to my own post, contradicting and
> > > criticizing myself.
> > > 
> > > >>> [1] Under Windows 98, the DLL with the symbol handler and
> > > >>>   StackWalk() functions is called: "imagehlp.dll".
> > > >>>   (i.e., different from the "dbghelp.dll" references
> > > >>>   scattered around the source and project settings)
> > > 
> > > Okay, the first part is true, but the posted code doesn't
> > > mention "dbghelp.dll" anywhere!  I was just confused.
> > > After I couldn't get the posted code to work, I downloaded
> > > a completely different project (Bugslayer1000), and *THAT*
> > > project had "dbghelp.dll" all over the place!
> > > 
> > > 
> > > >>> [2] Under Windows 98, we need the process **ID** for
> > > >>>   SymInitialize(), NOT the process handle.
> > > >>>   (See MSDN Library documentation for SymInitialize().)
> > > 
> > > This really was in the documentation, but I'm getting
> > > mixed signals from the code...
> > > 
> > >   (a) If I use the process ID (following MSDN
> > >       documentation on SymInitialize()), the StackWalk()
> > >       stops walking after a single iteration!  The symbol
> > >       lookup returns an empty symbol string, but doesn't
> > >       complain about accessing an invalid address.
> > > 
> > >   (b) If I use hProcess handle (contradicting MSDN
> > >       documentation on SymInitialize()), the StackWalk()
> > >       walks up the stack just fine (apparently)!  The symbol
> > >       lookup fails (complain about accessing an invalid address).
> > > 
> > > 
> > > I'd really like to get the code working, just as an educational
> > > example.
> > > 
> > > Here's a kind of trace of what happened:
> > > ========================================
> > > 
> > > (NOTE: The following trace assumes that we can get away with
> > > using hProcess for the symbol handler (contradicting the
> > > documentation).  The trace with the process ID as symbol
> > > handler and StackWalk parameter is similar, but ends
> > > with a whimper: StackWalk() ends its walk immediately,
> > > and SymGetSymFromAddr() returns nothing!)
> > > 
> > > When my test application starts executing:
> > > ------------------------------------------
> > > 
> > > ENTER ExceptionHandler::ExceptionHandler()
> > > 
> > >   ENTER ExceptionHandler::InitClass()
> > >   LEAVE ExceptionHandler::InitClass()
> > > 
> > >   ENTER ExceptionHandler::InitDLL()
> > >     global_hProcess   = 0x7fffffff
> > >     global_ProcessId  = 0xfffcfd73
> > >     global_SymProcess = 0x7fffffff
> > >     mHImageHlpDll = LoadLibrary("imagehlp.dll"); = 0x7d750000
> > >   LEAVE ExceptionHandler::InitDLL()
> > > 
> > >   Dir with executable:
> > > 'C:\WINDOWS\DESKTOP\ASSERT_CODE\TEST_ASSERT\DEBUG\TEST_ASSERT.EXE'
> > > 
> > > LEAVE ExceptionHandler::ExceptionHandler()
> > > 
> > > 
> > > 
> > > When my test application calls ASSERTx(...):
> > > --------------------------------------------
> > > 
> > > ENTER ExceptionHandler::DumpCrash(HANDLE hThread = 0xfffffffe, void*
> > > pExceptionInfo = 0x0065f8c0)
> > > 
> > >   About to do
> > >     SymInitialize
> > > 
> > > 
> > >      0x7fffffff,
> > > 
> > > "C:\WINDOWS\Desktop\assert_code\test_assert\Debug;C:\WINDOWS\D
> > > ESKTOP\ASSERT_
> > > CODE\TEST_ASSERT\DEBUG;",
> > >      FALSE
> > >      );
> > > 
> > >   About to do
> > >      SymSetOptions(SYMOPT_LOAD_LINES | SYMOPT_UNDNAME |
> > > SYMOPT_CASE_INSENSITIVE);
> > > 
> > >   About to do
> > >      enumAndLoadModuleSymbols( global_hProcess, global_ProcessId );
> > > 
> > > 
> > >   ENTER void enumAndLoadModuleSymbols( HANDLE hProcess = 
> > > 0x7fffffff, DWORD
> > > pid = 0xfffcfd73 );
> > > 
> > > . . .
> > > . . .
> > > . . .
> > >     sSymLoadModule
> > > 
> > > 
> > >       global_SymProcess = 0x7fffffff,
> > >       0,
> > >       
> > > 
> > img='C:\WINDOWS\DESKTOP\ASSERT_CODE\TEST_ASSERT\DEBUG\STDASSERT.DLL',
> > >       mod='STDASSERT.DLL',
> > >       base=0x10000000,
> > >       size=311296
> > >       ); ==> Result = 0x10000000
> > > 
> > >     sSymLoadModule
> > > 
> > > 
> > >       global_SymProcess = 0x7fffffff,
> > >       0,
> > > 
> > > img='C:\WINDOWS\DESKTOP\ASSERT_CODE\TEST_ASSERT\DEBUG\TEST_ASS
> > > ERT.EXE',
> > >       mod='TEST_ASSERT.EXE',
> > >       base=0x00400000,
> > >       size=180224
> > >       ); ==> Result = 0x00400000
> > > 
> > >     sSymLoadModule
> > > 
> > > 
> > >       global_SymProcess = 0x7fffffff,
> > >       0,
> > >       img='C:\WINDOWS\SYSTEM\KERNEL32.DLL',
> > >       mod='KERNEL32.DLL',
> > >       base=0xbff70000,
> > >       size=471040
> > >       ); ==> Result = 0xbff70000
> > > . . .
> > > 
> > > LEAVE void enumAndLoadModuleSymbols( HANDLE hProcess = 
> > > 0x7fffffff, DWORD pid
> > > = 0xfffcfd73 );
> > > 
> > > 
> > > (Back in ExceptionHandler::DumpCrash()...)
> > > 
> > > 
> > >   StackWalk
> > >     ( ...,
> > >     global_SymProcess = 0x7fffffff,
> > >     hThread = 0xfffffffe,
> > >     {sfStackFrame.AddrPC.Offset = 0x100042b3},
> > >     ...); ==> Result = 1
> > > 
> > >   SymGetSymFromAddr
> > > 
> > > 
> > >     global_SymProcess = 0x7fffffff,
> > >     ui32_Address = 0x100042b3,
> > >     &(dwSymOffset = 0x00000000),
> > >     (pSymbol->Name = '')
> > >     ); ==> Result = 0x00000001
> > > 
> > >   ERROR: "Attempt to access invalid address"
> > > 
> > >   StackWalk
> > >     ( ...,
> > >     global_SymProcess = 0x7fffffff,
> > >     hThread = 0xfffffffe,
> > >     {sfStackFrame.AddrPC.Offset = 0x004012c0},
> > >     ...); ==> Result = 1
> > > 
> > >   SymGetSymFromAddr
> > > 
> > > 
> > >     global_SymProcess = 0x7fffffff,
> > >     ui32_Address = 0x004012c0,
> > >     &(dwSymOffset = 0x00000000),
> > >     (pSymbol->Name = '')
> > >     ); ==> Result = 0x00000001
> > > 
> > >   ERROR: "Attempt to access invalid address"
> > > 
> > >   StackWalk
> > >     ( ...,
> > >     global_SymProcess = 0x7fffffff,
> > >     hThread = 0xfffffffe,
> > >     {sfStackFrame.AddrPC.Offset = 0x0040139e},
> > >     ...); ==> Result = 1
> > > 
> > >   SymGetSymFromAddr
> > > 
> > > 
> > >     global_SymProcess = 0x7fffffff,
> > >     ui32_Address = 0x0040139e,
> > >     &(dwSymOffset = 0x00000000),
> > >     (pSymbol->Name = '')
> > >     ); ==> Result = 0x00000001
> > > 
> > >   ERROR: "Attempt to access invalid address"
> > > 
> > >   StackWalk
> > >     ( ...,
> > >     global_SymProcess = 0x7fffffff,
> > >     hThread = 0xfffffffe,
> > >     {sfStackFrame.AddrPC.Offset = 0x004013fd},
> > >     ...); ==> Result = 1
> > > 
> > >   SymGetSymFromAddr
> > > 
> > > 
> > >     global_SymProcess = 0x7fffffff,
> > >     ui32_Address = 0x004013fd,
> > >     &(dwSymOffset = 0x00000000),
> > >     (pSymbol->Name = '')
> > >     ); ==> Result = 0x00000001
> > > 
> > >   ERROR: "Attempt to access invalid address"
> > > 
> > >   StackWalk
> > >     ( ...,
> > >     global_SymProcess = 0x7fffffff,
> > >     hThread = 0xfffffffe,
> > >     {sfStackFrame.AddrPC.Offset = 0x0040144a},
> > >     ...); ==> Result = 1
> > > 
> > >   SymGetSymFromAddr
> > > 
> > > 
> > >     global_SymProcess = 0x7fffffff,
> > >     ui32_Address = 0x0040144a,
> > >     &(dwSymOffset = 0x00000000),
> > >     (pSymbol->Name = '')
> > >     ); ==> Result = 0x00000001
> > > 
> > >   ERROR: "Attempt to access invalid address"
> > > 
> > >   StackWalk
> > >     ( ...,
> > >     global_SymProcess = 0x7fffffff,
> > >     hThread = 0xfffffffe,
> > >     {sfStackFrame.AddrPC.Offset = 0x004020c9},
> > >     ...); ==> Result = 1
> > > 
> > >   SymGetSymFromAddr
> > > 
> > > 
> > >     global_SymProcess = 0x7fffffff,
> > >     ui32_Address = 0x004020c9,
> > >     &(dwSymOffset = 0x00000000),
> > >     (pSymbol->Name = '')
> > >     ); ==> Result = 0x00000001
> > > 
> > >   ERROR: "Attempt to access invalid address"
> > > 
> > >   StackWalk
> > >     ( ...,
> > >     global_SymProcess = 0x7fffffff,
> > >     hThread = 0xfffffffe,
> > >     {sfStackFrame.AddrPC.Offset = 0xbff8b537},
> > >     ...); ==> Result = 1
> > > 
> > >   SymGetSymFromAddr
> > > 
> > > 
> > >     global_SymProcess = 0x7fffffff,
> > >     ui32_Address = 0xbff8b537,
> > >     &(dwSymOffset = 0x00000000),
> > >     (pSymbol->Name = '')
> > >     ); ==> Result = 0x00000001
> > > 
> > >   ERROR: "Attempt to access invalid address"
> > > 
> > > 
> > > 
> > > Closing Comments:
> > > -----------------
> > > 
> > > The stack walking looks fine!  The addresses fall within the 
> > > various *.DLL
> > > files.
> > > I'm sure I could convert the addresses to functions by hand;  
> > > i.e., I am
> > > confident that the addresses are valid.
> > > 
> > > I initiatialized the structure size field in the symbol structure
> > > (which wasn't done in the original version of the code)
> > > for SymGetSymFromAddr().
> > > 
> > > The process handle is the same as that used to initialize the
> > > symbol handler -- and if I try using a different handle,
> > > the function reports (via GetLastError()) "invalid handle".
> > > 
> > > What could this be?!  What is the "Attempt to access 
> > invalid address"
> > > reported by SymGetSymFromAddr() (via GetLastError())?
> > > 
> > > I also tried using the exact address of an existing symbol
> > > in the SymGetSymFromAddr(), just as a sanity check...
> > > But there was no sanity!  It also resulted in the
> > > "Attempt to access invalid address" error.
> > > 
> > > All of this is under Windows 98, using Visual C++ 6.0 Professional,
> > > with Service Pack 5.  I never explicitly installed a different
> > > version of "imagehlp.{dll,lib,h}" -- although VC++ 6.0 SP5 may
> > > have overwritten the version that shipped with VC++ 6.0.
> > > 
> > > I'd step in to SymGetSymFromAddr()...IF I KNEW HOW!!! ;-)
> > > 
> > > --- Colin
> > > 
> > > 
> > > 
> > > 
> > > -------------------------------------------------------
> > > This sf.net email is sponsored by:ThinkGeek
> > > Welcome to geek heaven.
> > > http://thinkgeek.com/sf
> > > _______________________________________________
> > > Gamedevlists-windows mailing list
> > > Gam...@li...
> > > https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> > > Archives:
> > > http://sourceforge.net/mailarchive/forum.php?forum_id=555
> > > 
> > 
> > 
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Gamedevlists-windows mailing list
> > Gam...@li...
> > https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> > Archives:
> > http://sourceforge.net/mailarchive/forum.php?forum_idU5
> > 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_idU5
> 

RE: [GD-Windows] Finding routine that's crashing

[Andrew G. <ag...@cl...>]

There's a 3rd party program, Bugtrapper which does this. You run the
bugtrapper agent on the machine in question and if a crash happens it =
logs a
complete call stack with variables and so on.

I seem to remember it's fairly pricey =A32-3k but we found it priceless =
during
beta, no more "I clicked on this dude and it crashed" bug reports from =
QA :)


Andrew Grant-
Climax Brighton=20



> -----Original Message-----
> From: Rich [mailto:leg...@xm...]
> Sent: 02 August 2002 18:20
> To: gam...@li...
> Subject: Re: [GD-Windows] Finding routine that's crashing=20
>=20
>=20
>=20
> In article=20
> <9EA...@ma...>,
>     "Grills, Jeff" <jg...@so...>  writes:
>=20
> > newer version of the DLL that has a working=20
> MiniDumpWriteDump function.
> > That's another awesome function you guys should become=20
> familiar with.
>=20
> Speaking of which... I hear that the XP team is working on a way to
> let your company receive those crash reports that are collected
> automatically by XP when a program bombs out.  (I think it collects a
> minidump, I'm not entirely sure; I don't have XP installed on =
anything
> yet.)
> --=20
> Ask me about my upcoming book on Direct3D from Addison-Wesley!
>   Direct3D Book <http://www.xmission.com/~legalize/book/>
>     izfree: Open source tools for Windows Installer
>             <http://izfree.sourceforge.net>
>=20
>=20
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=3D555
>=20

RE: [GD-Windows] Finding routine that's crashing

[Andy G. <an...@mi...>]

https://winqual.microsoft.com/Default.asp

Is the site where you can sign your company up to be able to receive the
crash and hang reports from Windows XP. I think you have to pay $400 for
a Verisign ID, to make sure you really are who you say you are, but then
you can get access to your crash reports. I have worked with a couple of
developers to get them signed up - the access site is a little primitive
right now, but should improve in the future.

MiniDumps are awesome - My No.1 reason for switching to VS.NET for
development.

Andy Glaister



-----Original Message-----
From: Rich [mailto:leg...@xm...]=20
Sent: Friday, August 02, 2002 10:20 AM
To: gam...@li...
Subject: Re: [GD-Windows] Finding routine that's crashing=20


In article
<9EA...@ma...>,
    "Grills, Jeff" <jg...@so...>  writes:

> newer version of the DLL that has a working MiniDumpWriteDump
function.
> That's another awesome function you guys should become familiar with.

Speaking of which... I hear that the XP team is working on a way to
let your company receive those crash reports that are collected
automatically by XP when a program bombs out.  (I think it collects a
minidump, I'm not entirely sure; I don't have XP installed on anything
yet.)
--=20
Ask me about my upcoming book on Direct3D from Addison-Wesley!
  Direct3D Book <http://www.xmission.com/~legalize/book/>
    izfree: Open source tools for Windows Installer
            <http://izfree.sourceforge.net>


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Gamedevlists-windows mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=3D555

Re: [GD-Windows] Finding routine that's crashing

[Colin F. <cp...@ea...>]

2002 August 7th
Wednesday

First, I want to thank all of the people on this list
who shared their code and offered suggestions on how
to get a stack trace of the location of a crash.
In particular, I want to thank Brian Sharon for
following up my most recent clarification questions.


I am going to describe my paranoid, and very likely
insane, method for getting the crash trace code to
work:


[1] Under Windows 2000, install Visual Studio .NET, and you
should get the following files:

  [a] c:\program files\microsoft visual studio .net\
       vc7\platformsdk\include\dbghelp.h
     (68,880 bytes; June 9, 2001)

  [b] c:\program files\microsoft visual studio .net\
       vc7\platformsdk\lib\dbghelp.lib
     (23,316 bytes; June 9, 2001)

  [c] c:\program files\microsoft visual studio .net\
       common7\ide\dbghelp.dll
     (486,400 bytes; September 5, 2001)


[2] Copy the files mentioned above to a single folder,
   and copy this folder to your Windows 98 machine.

[3] Under Windows 98, copy the files from the folder
   mentioned in step [2] in to the root of your
   C++ application project folder.

[4] Make sure your C++ source file with the symbol
  handling code has something like this:

    #include <windows.h>

    // The following #define prevents an error
    // in "DbgHelp.h" due to deprecation of
    // functions.  I don't know the "proper"
    // way other than using this #define.
    #define _IMAGEHLP_SOURCE_
   
    #include "Dbghelp.h"

[5] It is absolutely critical to use the proper HANDLE to
  indicate the process in all of the symbol handler functions.
  You must determine your platform, and then:

  [a] Under Windows 98, use the following HANDLE:

         ::OpenProcess(PROCESS_ALL_ACCESS, FALSE, ::GetCurrentProcessId());

  [b] Under Windows 2000, Windows XP, Windows Me, use the following HANDLE:

         (HANDLE)GetCurrentProcessId()

  You will use the appropriate HANDLE ([a] or [b]) for all symbol
  handler functions, including the following:

         SymInitialize(...)
         StackWalk(...)
         SymGetModuleInfo(...)
         SymGetSymFromAddr(...)
         SymGetLineFromAddr(...)

Anyhow, these are what I consider to be the critical steps in
getting started with symbol handling and stack tracing.

Here are examples of what you get for various kinds of
"Release" builds:


[1] Default (no debugging info, no program database (PDB)):
-----------------------------------------------------------

FATAL ERROR: Unhandled exception.
             Program address: 0x00401058.
             Offending thread: 0xFFFB678D.
             Exception: Integer divide-by-zero.
             OS info: Windows 98 4.10 (build 1998).
               0x00401058  <CRASH_TRACE>
               0x00401EAB  <CRASH_TRACE>
               0xBFF8B537  <KERNEL32>
               0xBFF8B3E9  <KERNEL32>
               0xBFF89DAC  <KERNEL32>

  NOTE: As you can see, you don't get function names.


[2] Program database (PDB), but no debugging info:
-----------------------------------------------------------

FATAL ERROR: Unhandled exception.
             Program address: 0x00401058.
             Offending thread: 0xFFF9FF69.
             Exception: Integer divide-by-zero.
             OS info: Windows 98 4.10 (build 1998).
               0x00401058  main
               0x00401F0F  mainCRTStartup
               0xBFF8B537  <KERNEL32>
               0xBFF8B3E9  <KERNEL32>
               0xBFF89DAC  <KERNEL32>

  NOTE: In this case you get function names, but no
  line numbers.  (If you have a PDB file for
  kernel32.dll, I suppose you could get function
  names for that module also.)


[3] Program database (PDB), and debugging info
  (Microsoft debugging info format, "Program Database"):
-----------------------------------------------------------

FATAL ERROR: Unhandled exception.
             Program address: 0x00401058.
             Offending thread: 0xFFF84B85.
             Exception: Integer divide-by-zero.
             OS info: Windows 98 4.10 (build 1998).
               0x00401058  main  (crash_trace.cpp, line 17) <CRASH_TRACE>
               0x00401F0F  mainCRTStartup
               0xBFF8B537  <KERNEL32>
               0xBFF8B3E9  <KERNEL32>
               0xBFF89DAC  <KERNEL32>


  NOTE: In this case you can get function names
  and line numbers. (If you have a PDB file for
  kernel32.dll, I suppose you could get function
  names for that module also.)

All of this is really great!  I am really excited by
the prospect of having my release applications essentially
debug themselves when a crash occurs.  Not that my applications
ever crash (except for the contrived example shown above)...
but it's nice to know that if it ever occurs, the app
will supply detailed information.  Maybe the Heisenberg
Uncertainty Principle will lead to pathological cases
in which the mere presence of debugging information in
the application will prevent or cause crashing, but I
will relish the irony!  (I've already experienced the
seriously demented case of an exception handler causing
yet another exception!)

Thanks again!  You know who you are.

--- Colin
cp...@ea...
www.colinfahey.com

Re: [GD-Windows] Finding routine that's crashing

[Colin F. <cp...@ea...>]

2002 August 7th
Wednesday


In the e-mail I posted three seconds ago, I wrote:
==================================================

[5] It is absolutely critical to use the proper HANDLE to
  indicate the process in all of the symbol handler functions.
  You must determine your platform, and then:

  [a] Under Windows 98, use the following HANDLE:

         ::OpenProcess(PROCESS_ALL_ACCESS, FALSE, ::GetCurrentProcessId());

  [b] Under Windows 2000, Windows XP, Windows Me, use the following HANDLE:

         (HANDLE)GetCurrentProcessId()

==================================================

But I mixed up [a] and [b]!  The HANDLE's should be swapped!

Yes...It is "absolutely critical" to use the proper handle... ;-)

So much for my "public service" effort!

--- Colin

RE: [GD-Windows] Finding routine that's crashing

[Timur D. <ti...@cr...>]

Actually mine MSDN (VS.Net) says:

-------------------------------------------------------------------------=
-
SymInitialize
BOOL SymInitialize(
  HANDLE hProcess,    =20
  PSTR UserSearchPath, =20
  BOOL fInvadeProcess =20
);

hProcess=20
[in] Handle to the process for which symbols are to be maintained. If =
the application is a debugger, use the process handle for the object =
being debugged, otherwise use the GetCurrentProcess function to obtain =
the process handle.=20
-------------------------------------------------------------------------=
-

and i use GetCurrentProcess() and everything works...
so i dont sure why you use this GetCurrentProcessId() and it works, may =
be on win2k processId will be equal to process handle.

_________________
Timur Davidenko.
Crytek Studios (www.crytek.com)

> -----Original Message-----
> From: Colin Fahey [mailto:cp...@ea...]
> Sent: Thursday, August 08, 2002 3:32 AM
> To: Colin Fahey; Gam...@li...
> Subject: Re: [GD-Windows] Finding routine that's crashing
>=20
>=20
>=20
> 2002 August 7th
> Wednesday
>=20
>=20
> In the e-mail I posted three seconds ago, I wrote:
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

>=20
> [5] It is absolutely critical to use the proper HANDLE to
>   indicate the process in all of the symbol handler functions.
>   You must determine your platform, and then:
>=20
>   [a] Under Windows 98, use the following HANDLE:
>=20
>          ::OpenProcess(PROCESS_ALL_ACCESS, FALSE,=20
> ::GetCurrentProcessId());
>=20
>   [b] Under Windows 2000, Windows XP, Windows Me, use the=20
> following HANDLE:
>=20
>          (HANDLE)GetCurrentProcessId()
>=20
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

>=20
> But I mixed up [a] and [b]!  The HANDLE's should be swapped!
>=20
> Yes...It is "absolutely critical" to use the proper handle... ;-)
>=20
> So much for my "public service" effort!
>=20
> --- Colin
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=3D555
>=20

RE: [GD-Windows] Finding routine that's crashing

[<Per...@ep...>]

As an extra question on this topic. Does any of you know of a c-function
that gives you the current stack, so that I can find out what the call stack
is and print it for tracing ???

Per
"Allys are enemys too strong to be defeated, yet to weak to defeat you."

RE: [GD-Windows] Finding routine that's crashing

[Andrew G. <ag...@cl...>]

No such function exists because that type of functionality is very OS
dependent.

If you need the callstack reread the mails on this subject that were =
just
sent, they're full of pointers about how to do what you want.

Andrew Grant-
Climax Brighton=20



> -----Original Message-----
> From: Per L=F8vmo [mailto:Per...@ep...]
> Sent: 14 August 2002 09:33
> To: Gam...@li...
> Subject: RE: [GD-Windows] Finding routine that's crashing
>=20
>=20
> As an extra question on this topic. Does any of you know of a=20
> c-function
> that gives you the current stack, so that I can find out what=20
> the call stack
> is and print it for tracing ???
>=20
> Per
> "Allys are enemys too strong to be defeated, yet to weak to=20
> defeat you."
>=20
>=20

RE: [GD-Windows] Finding routine that's crashing

[Brian S. <bs...@mi...>]

My MSDN (July 2001, guess I need to update) says:

	The process handle passed to SymInitialize can be=20
	any unique value, except in the case=20
	when fInvadeProcess is TRUE.=20

This is why you might see sample code from John Robbins that just uses
"(HANDLE)1" as the first argument; if he's setting fInvadeProcess to
false, it doesn't really matter what value he uses.

It also says:

	hProcess=20
	[in] Handle to the process for which symbols are=20
	to be maintained. If the application is a debugger,=20
	use the process handle for the object being debugged,=20
	otherwise use the GetCurrentProcess function=20
	to obtain the process handle.=20
	Windows 95/98/Me: Use the process identifier, not=20
	the process handle.=20

That last bit is key.  On 2000 and XP, you can use GetCurrentProcess()
to get a pseudo-handle to the process or you can call OpenProcess(...as
below...) to get a real handle to it.  Both should work AFAIK.

On 95/98/Me, you would instead use (HANDLE)GetCurrentProcessId().  This
doesn't mean that the process ID is a substitute for the process handle,
this is just a quirk of dbghelp (again AFAIK).  (and Windows Me is a 9x
variant, Colin accidentally lumped it in with 2k and XP)

I sent Colin some code that handles all these variations, but I
unfortunately only have it on at home - on my Macintosh :).  Feel free
to ping him for a copy, or I can post it to the list later if it would
be helpful...

--brian

> -----Original Message-----
> From: Timur Davidenko [mailto:ti...@cr...]=20
> Sent: Wednesday, August 14, 2002 1:26 AM
> To: Gam...@li...
> Subject: RE: [GD-Windows] Finding routine that's crashing
>=20
>=20
> Actually mine MSDN (VS.Net) says:
>=20
> --------------------------------------------------------------
> ------------
> SymInitialize
> BOOL SymInitialize(
>   HANDLE hProcess,    =20
>   PSTR UserSearchPath, =20
>   BOOL fInvadeProcess =20
> );
>=20
> hProcess=20
> [in] Handle to the process for which symbols are to be=20
> maintained. If the application is a debugger, use the process=20
> handle for the object being debugged, otherwise use the=20
> GetCurrentProcess function to obtain the process handle.=20
> --------------------------------------------------------------
> ------------
>=20
> and i use GetCurrentProcess() and everything works...
> so i dont sure why you use this GetCurrentProcessId() and it=20
> works, may be on win2k processId will be equal to process handle.
>=20
> _________________
> Timur Davidenko.
> Crytek Studios (www.crytek.com)
>=20
> > -----Original Message-----
> > From: Colin Fahey [mailto:cp...@ea...]
> > Sent: Thursday, August 08, 2002 3:32 AM
> > To: Colin Fahey; Gam...@li...
> > Subject: Re: [GD-Windows] Finding routine that's crashing
> >=20
> >=20
> >=20
> > 2002 August 7th
> > Wednesday
> >=20
> >=20
> > In the e-mail I posted three seconds ago, I wrote:
> > =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

> >=20
> > [5] It is absolutely critical to use the proper HANDLE to
> >   indicate the process in all of the symbol handler functions.
> >   You must determine your platform, and then:
> >=20
> >   [a] Under Windows 98, use the following HANDLE:
> >=20
> >          ::OpenProcess(PROCESS_ALL_ACCESS, FALSE,=20
> > ::GetCurrentProcessId());
> >=20
> >   [b] Under Windows 2000, Windows XP, Windows Me, use the=20
> > following HANDLE:
> >=20
> >          (HANDLE)GetCurrentProcessId()
> >=20
> > =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

> >=20
> > But I mixed up [a] and [b]!  The HANDLE's should be swapped!
> >=20
> > Yes...It is "absolutely critical" to use the proper handle... ;-)
> >=20
> > So much for my "public service" effort!
> >=20
> > --- Colin

[GD-Windows] internationalization

[Daniel V. <vo...@ep...>]

Does anyone know how to get from a language id returned from say
GetUserDefaultLangID to a three letter language abbreviation like ENU, ENS,
HUN, ...?

Thanks,

-- Daniel, Epic Games Inc.