Mike Nordell wrote:
> That address seems invalid.
>
> Without access to some debug info, map-file or stuff like that, a stack
> trace wouldn't usually help much either (at least not without several hours
> of disassembly).
>
> Note to Win32 builders: When building Win32 Release, some sort of debug info
> should also be generated for the same exe. PDB, DBG and/or a simple
> map-file. It should probably not be "shipped" with the binary, but it should
> be available for download to be able to look at a stack trace and get an
> idea of where it crashed.
>
> > I'll leave the debugger in this condition for a little while in case
> > somebody writes back with a question. If I can't answer your question
> > this time, I'll try to check it out on the next occurrence.
>
> If you can provide a stack-trace for the current thread and any other
> threads in the app, and a pointer to the exact same binary, I'll try to have
> a look at it (though post-mortem by disassembly is a bit time-consuming
> :-) ).
Mike,
Thanks for the response!
I shut the debugger down quite a while ago and rebooted. (After an
occurrence like this, it seems that a lot of memory is "locked up"
somewhere, and is not released for my use after simply shutting down the
debugger, but only after rebooting.)
I don't immediately know how to get a stack trace, or know what other
threads are in the app, but next time I start the debugger I'll check
out the help (or Google, or whatever) and see if I can do it.
I hate to see anybody go through any (manual?) time-consuming
disassembly, I suspect it's not really worth it -- at some point
hopefully we'll have more / better debug information available.
I did download the debug build that Nikolaj made of the same release --
I assume that it would not have the "PDB, DBG and/or a simple map-file"
that you are referring to, or even if it did, it is of no use because it
is not for exactly the same binary?
Randy Kramer
