Thread: RE: [GD-Windows] Finding routine that's crashing
Brought to you by:
vexxed72
From: Brian S. <bs...@mi...> - 2002-07-31 17:54:17
|
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 |
From: Brian H. <bri...@py...> - 2002-07-31 19:03:11
|
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 |
From: Rich <leg...@xm...> - 2002-07-31 19:16:18
|
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> |
From: Paul B. <pa...@mi...> - 2002-07-31 19:21:23
|
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 |
From: Brian S. <bs...@mi...> - 2002-07-31 19:22:56
|
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. |
From: Brian H. <bri...@py...> - 2002-07-31 19:41:11
|
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 > > |
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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: Colin F. <cp...@ea...> - 2002-08-08 01:21:11
|
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 |
From: Colin F. <cp...@ea...> - 2002-08-08 01:34:04
|
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 |
From: Timur D. <ti...@cr...> - 2002-08-14 08:26:08
|
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 |
From: <Per...@ep...> - 2002-08-14 08:35:16
|
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." |
From: Andrew G. <ag...@cl...> - 2002-08-14 10:28:24
|
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 |
From: Brian S. <bs...@mi...> - 2002-08-14 16:09:21
|
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 |
From: Daniel V. <vo...@ep...> - 2002-08-16 22:54:01
|
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. |