gamedevlists-windows Mailing List for gamedev (Page 47)
Brought to you by:
vexxed72
Menu
▾
▴
gamedevlists-windows — List for discussing game development on the Windows platform
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(48) |
Oct
(58) |
Nov
(49) |
Dec
(38) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(124) |
Feb
(83) |
Mar
(17) |
Apr
(37) |
May
(12) |
Jun
(20) |
Jul
(47) |
Aug
(74) |
Sep
(62) |
Oct
(72) |
Nov
(54) |
Dec
(13) |
| 2003 |
Jan
(36) |
Feb
(8) |
Mar
(38) |
Apr
(3) |
May
(6) |
Jun
(133) |
Jul
(20) |
Aug
(18) |
Sep
(12) |
Oct
(4) |
Nov
(28) |
Dec
(36) |
| 2004 |
Jan
(22) |
Feb
(51) |
Mar
(28) |
Apr
(9) |
May
(20) |
Jun
(9) |
Jul
(37) |
Aug
(20) |
Sep
(23) |
Oct
(15) |
Nov
(23) |
Dec
(27) |
| 2005 |
Jan
(22) |
Feb
(20) |
Mar
(5) |
Apr
(14) |
May
(10) |
Jun
|
Jul
(6) |
Aug
(6) |
Sep
|
Oct
(12) |
Nov
(1) |
Dec
|
| 2006 |
Jan
(18) |
Feb
(4) |
Mar
(3) |
Apr
(6) |
May
(4) |
Jun
(3) |
Jul
(16) |
Aug
(40) |
Sep
(6) |
Oct
(1) |
Nov
|
Dec
(2) |
| 2007 |
Jan
(5) |
Feb
(2) |
Mar
(4) |
Apr
(1) |
May
(13) |
Jun
|
Jul
(26) |
Aug
(3) |
Sep
(10) |
Oct
|
Nov
(4) |
Dec
(5) |
| 2008 |
Jan
(1) |
Feb
|
Mar
(4) |
Apr
|
May
|
Jun
(5) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Julien K. <ma...@ju...> - 2002-08-05 16:37:23
|
Could you explain your Problem with this approach a little bit more precise ? Thanks Julien Koenen ----- Original Message ----- From: "Javier Arevalo" <ja...@py...> To: <gam...@li...> Sent: Monday, August 05, 2002 9:09 AM Subject: Re: [GD-Windows] Detecting mouse exiting window? > Julien Koenen <ma...@ju...> wrote: > > > You can Capture the Mouse-Cursor. > > Than you will get all Mouse-Move-Messages and you can check if the > > Mouse-Pos is still in your Window. > > > I strongly advise against this. It will hurt you later with usability > problems when the user wonders why his mouse doesn't seem to work properly. > > Javier Arevalo > Pyro Studios > > > > > ------------------------------------------------------- > 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 |
|
From: Nicolas R. <nic...@fr...> - 2002-08-05 12:23:54
|
Yes... template and DLLs are badly working together...
Under VC7 you can at least declare the template exported...
template<class T> class __declspec(dllexport) mytemplate
{
};
will correctly export the template.
Note however that the export is only done on used template definitions... Export/import
scheme defined automatically by VC++ is not sufficient...
Let say you have a header containing:
template<class T> class MYDLL_API mytemplate
{
};
A DLL is compiling with MYDLL_API to __declspec(dllexport). If it use it with T =
MyDLLClass1 and MyDLLClass2, only mytemplate<DLLClass1> and mytemplate<DLLClass2> will be
exported.
If an external program is including the header (with MYDLL_API to __declspec(dllimport))
it won't be able to use the template for a "ExeClass" since it won't be exported by any
DLL...
Still havent find any way to correctly export the template itself (but using the #pragma
warning(disable:xxxx) before using a non exported template).
Nicolas.
-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
jason zhang
Sent: lundi 5 août 2002 09:48
To: gam...@li...
Subject: [GD-Windows] dll export and template
There was a compile warning when I use template in my export class of DLL. And the
compiler
will give an error if I put __declspec(dllexport) keyword before the my template
definition.
My question is whether it is safe if I just disable the warning.
The warning is:
"The specified base class was not declared with the __declspec(dllexport) keyword.A base
class or structure must be declared with the __declspec(dllexport) keyword if a function
in a derived class is to be exported. "
.
The code is:
template<class T> mytemplate
{
T t;
public:
void SetData( T &_t ){ t = _t; }
};
class MYDLL_API MyClass
{
mytemplate<int> data;
public:
....
};
N±ùµéX²²u¼)çYé¢g¢½é¶ÚþØHzGû©uëËÂ)£
j) ²Ñç¾X¶ÌÚ²X¶Ëº·~zwÛ³ÿ˲qç®zßËþX¶)£øç¾X¶ÌÚ°
+²§ÿ¢êyúé·ùVr{÷®é®ét
|
|
From: jason z. <dir...@21...> - 2002-08-05 07:40:25
|
VGhlcmUgd2FzIGEgY29tcGlsZSB3YXJuaW5nIHdoZW4gSSAgdXNlIHRlbXBsYXRlIGluIG15IGV4 cG9ydCBjbGFzcyBvZiBETEwuICBBbmQgdGhlIGNvbXBpbGVyDQp3aWxsIGdpdmUgYW4gZXJyb3Ig aWYgSSBwdXQgX19kZWNsc3BlYyhkbGxleHBvcnQpIGtleXdvcmQgYmVmb3JlIHRoZSBteSB0ZW1w bGF0ZSBkZWZpbml0aW9uLiANCk15IHF1ZXN0aW9uIGlzIHdoZXRoZXIgaXQgaXMgc2FmZSBpZiBJ IGp1c3QgZGlzYWJsZSB0aGUgd2FybmluZy4gDQoNClRoZSB3YXJuaW5nIGlzOg0KIlRoZSBzcGVj aWZpZWQgYmFzZSBjbGFzcyB3YXMgbm90IGRlY2xhcmVkIHdpdGggdGhlIF9fZGVjbHNwZWMoZGxs ZXhwb3J0KSBrZXl3b3JkLkEgYmFzZSBjbGFzcyBvciBzdHJ1Y3R1cmUgbXVzdCBiZSBkZWNsYXJl ZCB3aXRoIHRoZSBfX2RlY2xzcGVjKGRsbGV4cG9ydCkga2V5d29yZCBpZiBhIGZ1bmN0aW9uIGlu IGEgZGVyaXZlZCBjbGFzcyBpcyB0byBiZSBleHBvcnRlZC4gIg0KLg0KVGhlIGNvZGUgaXM6DQp0 ZW1wbGF0ZTxjbGFzcyBUPiBteXRlbXBsYXRlDQp7DQogICAgVCB0Ow0KcHVibGljOg0KICAgIHZv aWQgU2V0RGF0YSggVCAmX3QgKXsgdCA9IF90OyB9DQp9Ow0KDQpjbGFzcyBNWURMTF9BUEkgTXlD bGFzcw0Kew0KICAgIG15dGVtcGxhdGU8aW50PiBkYXRhOw0KDQpwdWJsaWM6DQogICAgLi4uLg0K fTsNCg0KDQo= |
|
From: Javier A. <ja...@py...> - 2002-08-05 07:08:35
|
Julien Koenen <ma...@ju...> wrote: > You can Capture the Mouse-Cursor. > Than you will get all Mouse-Move-Messages and you can check if the > Mouse-Pos is still in your Window. I strongly advise against this. It will hurt you later with usability problems when the user wonders why his mouse doesn't seem to work properly. Javier Arevalo Pyro Studios |
|
From: Rich <leg...@xm...> - 2002-08-03 18:15:39
|
They've been having trouble with the streaming windows media (the Sonera server just isn't up to the load), so they've made the .wmv files available for download. <http://www.assemblytv.net/download_02.php?langID=0&time=1028349610> -- 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> |
|
From: Julien K. <ma...@ju...> - 2002-08-03 10:37:28
|
You can Capture the Mouse-Cursor. Than you will get all Mouse-Move-Messages and you can check if the Mouse-Pos is still in your Window. Julien ----- Original Message ----- From: "Brian Hook" <bri...@py...> To: <gam...@li...> Sent: Saturday, August 03, 2002 1:46 AM Subject: RE: [GD-Windows] Detecting mouse exiting window? > Er, no, especially since it's nowhere in my help docs =( > > And, unfortunately, I need to run on Win95 still (yeah yeah yeah...). > > I "fixed" the problem by sitting in my WM_TIMER and calling > GetCursorPos() and generating application mouse moved events if the > mouse it outside the window. *puke* But it works. =) > > Thanks, > > -Hook > > > -----Original Message----- > > From: Andy Glaister [mailto:an...@mi...] > > Sent: Friday, August 02, 2002 4:44 PM > > To: Brian Hook; gam...@li... > > Subject: RE: [GD-Windows] Detecting mouse exiting window? > > > > > > Have you tried WM_MOUSELEAVE which is in Win98-> ? > > > > -----Original Message----- > > From: Brian Hook [mailto:bri...@py...] > > Sent: Friday, August 02, 2002 4:32 PM > > To: gam...@li... > > Subject: [GD-Windows] Detecting mouse exiting window? > > > > > > Is there a clean way of detecting when the mouse cursor has > > exited my window? WM_MOUSEMOVE and WM_NCMOUSEMOVE messages > > stop coming in the moment the mouse exits the window. The > > only other thing I can think of is to actually poll the mouse > > position and see if it's in my client area (blech). > > > > Brian > > > > > > > > ------------------------------------------------------- > > 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_id=555 |
|
From: Colin F. <cp...@ea...> - 2002-08-03 00:18:06
|
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...
|
|
From: Brian H. <bri...@py...> - 2002-08-02 23:46:39
|
Er, no, especially since it's nowhere in my help docs =( And, unfortunately, I need to run on Win95 still (yeah yeah yeah...). I "fixed" the problem by sitting in my WM_TIMER and calling GetCursorPos() and generating application mouse moved events if the mouse it outside the window. *puke* But it works. =) Thanks, -Hook > -----Original Message----- > From: Andy Glaister [mailto:an...@mi...] > Sent: Friday, August 02, 2002 4:44 PM > To: Brian Hook; gam...@li... > Subject: RE: [GD-Windows] Detecting mouse exiting window? > > > Have you tried WM_MOUSELEAVE which is in Win98-> ? > > -----Original Message----- > From: Brian Hook [mailto:bri...@py...] > Sent: Friday, August 02, 2002 4:32 PM > To: gam...@li... > Subject: [GD-Windows] Detecting mouse exiting window? > > > Is there a clean way of detecting when the mouse cursor has > exited my window? WM_MOUSEMOVE and WM_NCMOUSEMOVE messages > stop coming in the moment the mouse exits the window. The > only other thing I can think of is to actually poll the mouse > position and see if it's in my client area (blech). > > Brian > > > > ------------------------------------------------------- > 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 > > |
|
From: Andy G. <an...@mi...> - 2002-08-02 23:43:54
|
Have you tried WM_MOUSELEAVE which is in Win98-> ? -----Original Message----- From: Brian Hook [mailto:bri...@py...]=20 Sent: Friday, August 02, 2002 4:32 PM To: gam...@li... Subject: [GD-Windows] Detecting mouse exiting window? Is there a clean way of detecting when the mouse cursor has exited my window? WM_MOUSEMOVE and WM_NCMOUSEMOVE messages stop coming in the moment the mouse exits the window. The only other thing I can think of is to actually poll the mouse position and see if it's in my client area (blech). Brian ------------------------------------------------------- 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 |
|
From: Brian H. <bri...@py...> - 2002-08-02 23:32:21
|
Is there a clean way of detecting when the mouse cursor has exited my window? WM_MOUSEMOVE and WM_NCMOUSEMOVE messages stop coming in the moment the mouse exits the window. The only other thing I can think of is to actually poll the mouse position and see if it's in my client area (blech). Brian |
|
From: Andy G. <an...@mi...> - 2002-08-02 18:40:58
|
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 |
|
From: Jon W. <hp...@mi...> - 2002-08-02 18:30:16
|
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
>
|
|
From: Andrew G. <ag...@cl...> - 2002-08-02 17:38:03
|
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 |
|
From: Brian S. <bs...@mi...> - 2002-08-02 17:30:20
|
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
|
|
From: Rich <leg...@xm...> - 2002-08-02 17:20:11
|
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>
|
|
From: Grills, J. <jg...@so...> - 2002-08-02 16:53:05
|
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
|
|
From: Brian S. <bs...@mi...> - 2002-08-02 16:41:09
|
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
|
|
From: Rich <leg...@xm...> - 2002-08-02 13:47:55
|
<http://www.assemblytv.net/> For details and schedule. -- 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> |
|
From: Andrew G. <ag...@cl...> - 2002-08-02 10:37:23
|
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
>
|
|
From: Colin F. <cp...@ea...> - 2002-08-02 09:05:33
|
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
|
|
From: Colin F. <cp...@ea...> - 2002-08-01 21:58:40
|
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 |
|
From: Andrew G. <ag...@cl...> - 2002-08-01 21:45:57
|
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 |
|
From: <cas...@ya...> - 2002-08-01 21:23:43
|
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... 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 _______________________________________________________________ Yahoo! Messenger Nueva versión: Webcam, voz, y mucho más ¡Gratis! Descárgalo ya desde http://messenger.yahoo.es |
|
From: Nicolas Q. <ji...@us...> - 2002-08-01 15:23:22
|
--- This email was certified virus free upon leaving my computer... If there is something in it when you get it, it got picked up on the way... :) Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.380 / Virus Database: 213 - Release Date: 24/7/2002 |
|
From: Jon W. <hp...@mi...> - 2002-07-31 20:36:29
|
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 > |
14 messages has been excluded from this view by a project administrator.
