| TIP: Click on subject to list as thread! | ANSI |
| echo: | |
|---|---|
| to: | |
| from: | |
| date: | |
| subject: | How to interpret crash c |
WV>What I (under Windows) do is the following. I start the WV>debugger and let the debugger run the app. When an WV>exception occurs, the debugger is invoked in assembler WV>mode, showing the faulty instruction. Since I don't do WV>assembler (much), I alter the invalid pointer WV>(segment:offset values, replacing them with valid values WV>(usually ds:0 or a known and sacrificable variable)), and WV>then stepping through the asm until I hit source code. WV>It works with Turbo debugger (Windows), but not with CodeView (also windows) WV>because it won't let you continue after an exception 13. So WV>the possibility is that it might work with OS/2 also. It WV>surely is the fastest method I know (at the moment) An even faster way under TD is to look at the stack window. It lists all the function calls, and will let you see the offending source line instantly. Rob. ___ X SLMR 2.1a X He's dead Jim. You get his tricorder, I'll get his wallet --- Maximus/2 2.01wb* Origin: The Idle Task... (604)275-0835 Richmond BC. (1:153/905) SEEN-BY: 12/2442 620/243 624/50 632/348 640/820 690/660 711/409 410 413 430 SEEN-BY: 711/807 808 809 934 942 949 712/353 515 713/888 800/1 7877/2809 @PATH: 153/905 828 7041 752 716 920 270/101 396/1 3615/50 229/2 12/2442 @PATH: 711/409 808 809 934 |
|
| SOURCE: echomail via fidonet.ozzmosis.com | |
Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.