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

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

I ususally read the assembly code to figure out how many pops happen 
before the RET; that way I get the return address to the previous 
function. If that's still in some system DLL, I repeat until I've 
wound my way back up to my app.

Another thing you can do is use the "set next instruction" feature 
to set-next and execute all appropriate pop and RET instructions until 
the PC and stack are wound out to the point where you get a stack 
trace.

Yes, this means that internal state is corrupted, but because you 
crashed already, it doesn't really matter. And as you're only 
executing pop and ret instructions, (and LEAVE and similar) manually, 
you're not likely to actually dereference bad memory and screw 
yourself more.

These mechanisms are especially useful when you find yourself eight 
levels deep in NVOGLNT.DLL or ATIOGLXX.DLL for which symbols aren't 
available outside of some remote offices, period...

Another thing to look into is trying to use WinDbg, possibly in 
remote kernel debugger mode, which uses different mechanisms to do 
the unwind (and which has access to the symbol server stuff from 
Microsoft). WinDbg needs to target an NT kernel, but as XP is the 
only OS now available, that's not so bad. And under XP, it allows you 
to remote debug with IEEE-1394, which trounces all over a 19.2 kbps 
serial cable :-)

Cheers,

				/ h+


> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Brian Hook
> Sent: Wednesday, July 31, 2002 10:41 AM
> To: gam...@li...
> Subject: [GD-Windows] Finding routine that's crashing
> 
> 
> I'm getting an exception deep inside some call such that I 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).
> 
> Is there a simple way given an address to look up what 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 seeing isn't in
> the MAP file.
> 
> Thanks,
> 
> Brian
> 
> 
> 
> -------------------------------------------------------
> 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_code=31
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=555
>