/Oy- compiler option, frame pointers and DrWatson 
Author Message
 /Oy- compiler option, frame pointers and DrWatson

Hi all, ultimately this question is about the behaviour of DrWatson but I
suspect it may also be about the nature of the compiler options I've used to
build the binary. Note that in the following discussion, I'm using VisualC++
6.0 SP3 and run the apps under NT4.0 SP6a. Note also that the traces below
are best fiewed using a fixed width font.

Cheers,
Mike.

I've written a small noddy app that deliberately crashes 3 function calls
down. I've then compiled it 3 times with different optimisation options :
a) "Debug build" (/Od)
b) "Release build" (/O2)
c) "Release build _with_ stack frame generation" (/O2 /Oy-). Note that I
edited the "Project Options" edit box at the bottom to get this setting as
per compiler doc instructions.

When I run the application each time, I let DrWatson kick in and generated a
DrWatson log file.
Now the interesting thing is the portion of the DrWatson log files titled
"Stack Back Trace". I get the following :

a) As expected I get a nice stack frame produced :

*----> Stack Back Trace <----*

FramePtr ReturnAd Param#1  Param#2  Param#3  Param#4  Function Name
0012feb8 004010ac 00000003 00000004 0012ff80 0012fbbc !<nosymbols>
0012ff18 00401053 00000003 00000004 f9a00035 0012fbbc !<nosymbols>
0012ff80 004011f9 00000001 00300eb0 00300e10 f9a00035 !<nosymbols>
0012ffc0 77f1b9ea f9a00035 0012fbbc 7ffdf000 c0000005 !<nosymbols>
0012fff0 00000000 00401110 00000000 000000b0 00000100
kernel32!GetProcessPriorityBoost
00000000 00000000 00000000 00000000 00000000 00000000 !<nosymbols>

*----> Raw Stack Dump <----*
0012fe68  18 ff 12 00 bc fb 12 00 - 00 f0 fd 7f cc cc cc cc
................
0012fe78  cc cc cc cc cc cc cc cc - cc cc cc cc cc cc cc cc
................
0012fe88  cc cc cc cc cc cc cc cc - cc cc cc cc cc cc cc cc
................
0012fe98  cc cc cc cc cc cc cc cc - cc cc cc cc cc cc cc cc
................
0012fea8  cc cc cc cc cc cc cc cc - cc cc cc cc 00 00 00 00
................
0012feb8  18 ff 12 00 ac 10 40 00 - 03 00 00 00 04 00 00 00

0012fec8  80 ff 12 00 bc fb 12 00 - 00 f0 fd 7f cc cc cc cc
................
0012fed8  cc cc cc cc cc cc cc cc - cc cc cc cc cc cc cc cc
................
0012fee8  cc cc cc cc cc cc cc cc - cc cc cc cc cc cc cc cc
................
0012fef8  cc cc cc cc cc cc cc cc - cc cc cc cc cc cc cc cc
................
0012ff08  cc cc cc cc cc cc cc cc - cc cc cc cc 05 00 00 00
................
0012ff18  80 ff 12 00 53 10 40 00 - 03 00 00 00 04 00 00 00

0012ff28  35 00 a0 f9 bc fb 12 00 - 00 f0 fd 7f cc cc cc cc
5...............
0012ff38  cc cc cc cc cc cc cc cc - cc cc cc cc cc cc cc cc
................
0012ff48  cc cc cc cc cc cc cc cc - cc cc cc cc cc cc cc cc
................
0012ff58  cc cc cc cc cc cc cc cc - cc cc cc cc cc cc cc cc
................
0012ff68  cc cc cc cc cc cc cc cc - cc cc cc cc cc cc cc cc
................
0012ff78  04 00 00 00 03 00 00 00 - c0 ff 12 00 f9 11 40 00

0012ff88  01 00 00 00 b0 0e 30 00 - 10 0e 30 00 35 00 a0 f9
......0...0.5...
0012ff98  bc fb 12 00 00 f0 fd 7f - 05 00 00 c0 8b 74 11 80
.............t..

b) As expected I get very little stack frame :

*----> Stack Back Trace <----*

FramePtr ReturnAd Param#1  Param#2  Param#3  Param#4  Function Name
0012ffc0 77f1b9ea f9a70030 0012fbbc 7ffdf000 c0000005 <nosymbols>
0012fff0 00000000 00401050 00000000 000000b0 00000100
kernel32!GetProcessPriorityBoost
00000000 00000000 00000000 00000000 00000000 00000000 !<nosymbols>

*----> Raw Stack Dump <----*
0012ff6c  1f 10 40 00 03 00 00 00 - 04 00 00 00 09 10 40 00

0012ff7c  03 00 00 00 04 00 00 00 - 04 11 40 00 01 00 00 00

0012ff8c  d0 0e 30 00 50 0e 30 00 - 30 00 a7 f9 bc fb 12 00
..0.P.0.0.......
0012ff9c  00 f0 fd 7f 05 00 00 c0 - 8b 74 11 80 94 ff 12 00
.........t......
0012ffac  b4 fd 12 00 e0 ff 12 00 - 18 1b 40 00 90 40 40 00

0012ffbc  00 00 00 00 f0 ff 12 00 - ea b9 f1 77 30 00 a7 f9
...........w0...
0012ffcc  bc fb 12 00 00 f0 fd 7f - 05 00 00 c0 c8 ff 12 00
................
0012ffdc  b4 fd 12 00 ff ff ff ff - 44 b9 f3 77 48 d2 f3 77
........D..wH..w
0012ffec  00 00 00 00 00 00 00 00 - 00 00 00 00 50 10 40 00

0012fffc  00 00 00 00 b0 00 00 00 - 00 01 00 00 ff ee ff ee
................
0013000c  02 00 00 00 00 00 00 00 - 00 fe 00 00 00 00 10 00
................
0013001c  00 20 00 00 00 02 00 00 - 00 20 00 00 36 01 00 00  . .......
..6...
0013002c  ff ef fd 7f 01 00 48 05 - 00 00 00 00 00 00 00 00
......H.........
0013003c  00 00 00 00 00 00 00 00 - d8 04 13 00 0f 00 00 00
................
0013004c  f8 ff ff ff 50 00 13 00 - 50 00 13 00 80 05 13 00
....P...P.......
0013005c  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
................
0013006c  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
................
0013007c  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
................
0013008c  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
................
0013009c  00 00 00 00 00 00 00 00 - 00 00 00 00 ff ff 00 00
................

c) _Unexpectedly_ I only get a small amount of stack frame produced !? If I
examine the stack dump I can easily piece together the call stack and yet
DrWatson hasn't been able to do this for me. Is this because of the other
compiler options I've chosen ? The reason I care about this is that if I'd
made heavy use of stack based variable declarations, I wouldn't have been
able to piece the stack frame together by myself (as there would not be a
deep enough stack dump in the DrWatson log file). Any answer as to why the
stack frame trace is not as complete as it could/should be then I'd very
much appreciate it.

*----> Stack Back Trace <----*

FramePtr ReturnAd Param#1  Param#2  Param#3  Param#4  Function Name
0012ff64 00401020 00000003 00000004 0012ffc0 00401009 <nosymbols>

*----> Raw Stack Dump <----*

0012ff74  c0 ff 12 00 09 10 40 00 - 03 00 00 00 04 00 00 00

0012ff84  04 11 40 00 01 00 00 00 - d0 0e 30 00 50 0e 30 00

0012ff94  30 00 a7 f9 bc fb 12 00 - 00 f0 fd 7f 05 00 00 c0
0...............
0012ffa4  8b 74 11 80 94 ff 12 00 - ac fd 12 00 e0 ff 12 00
.t..............
0012ffb4  18 1b 40 00 90 40 40 00 - 00 00 00 00 f0 ff 12 00

0012ffc4  ea b9 f1 77 30 00 a7 f9 - bc fb 12 00 00 f0 fd 7f
...w0...........
0012ffd4  05 00 00 c0 c8 ff 12 00 - ac fd 12 00 ff ff ff ff
................
0012ffe4  44 b9 f3 77 48 d2 f3 77 - 00 00 00 00 00 00 00 00
D..wH..w........
0012fff4  00 00 00 00 50 10 40 00 - 00 00 00 00 b0 00 00 00

00130004  00 01 00 00 ff ee ff ee - 02 00 00 00 00 00 00 00
................
00130014  00 fe 00 00 00 00 10 00 - 00 20 00 00 00 02 00 00  .........
......
00130024  00 20 00 00 36 01 00 00 - ff ef fd 7f 01 00 48 05  .
..6.........H.
00130034  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
................
00130044  d8 04 13 00 0f 00 00 00 - f8 ff ff ff 50 00 13 00
............P...
00130054  50 00 13 00 80 05 13 00 - 00 00 00 00 00 00 00 00
P...............
00130064  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
................
00130074  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
................
00130084  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
................
00130094  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
................



Sun, 12 Oct 2003 21:33:48 GMT  
 /Oy- compiler option, frame pointers and DrWatson
One possible problem (since I haven't seen your source) is that the actual
crash is somewhere in a Win32 API call (because of bad arguments?). If so,
the problem can be that Win32 code does not necessarily use standard stack
frame.

That is, DrWatson tries to analyse the Win32 call's call frame as a standard
call frame, and fails. It will then also fail higher in the call stack.

If you're curious about how to improve the situation, you should look into
dbHelp.dll - this used in combination with pdb-files can manage to improve
the situation.

Regards,
Rune Christensen


Quote:
> Hi all, ultimately this question is about the behaviour of DrWatson but I
> suspect it may also be about the nature of the compiler options I've used
to
> build the binary. Note that in the following discussion, I'm using
VisualC++
> 6.0 SP3 and run the apps under NT4.0 SP6a. Note also that the traces below
> are best fiewed using a fixed width font.

> Cheers,
> Mike.

> I've written a small noddy app that deliberately crashes 3 function calls
> down. I've then compiled it 3 times with different optimisation options :
> a) "Debug build" (/Od)
> b) "Release build" (/O2)
> c) "Release build _with_ stack frame generation" (/O2 /Oy-). Note that I
> edited the "Project Options" edit box at the bottom to get this setting as
> per compiler doc instructions.

> When I run the application each time, I let DrWatson kick in and generated
a
> DrWatson log file.
> Now the interesting thing is the portion of the DrWatson log files titled
> "Stack Back Trace". I get the following :

> a) As expected I get a nice stack frame produced :

> *----> Stack Back Trace <----*

> FramePtr ReturnAd Param#1  Param#2  Param#3  Param#4  Function Name
> 0012feb8 004010ac 00000003 00000004 0012ff80 0012fbbc !<nosymbols>
> 0012ff18 00401053 00000003 00000004 f9a00035 0012fbbc !<nosymbols>
> 0012ff80 004011f9 00000001 00300eb0 00300e10 f9a00035 !<nosymbols>
> 0012ffc0 77f1b9ea f9a00035 0012fbbc 7ffdf000 c0000005 !<nosymbols>
> 0012fff0 00000000 00401110 00000000 000000b0 00000100
> kernel32!GetProcessPriorityBoost
> 00000000 00000000 00000000 00000000 00000000 00000000 !<nosymbols>

> *----> Raw Stack Dump <----*
> 0012fe68  18 ff 12 00 bc fb 12 00 - 00 f0 fd 7f cc cc cc cc
> ................
> 0012fe78  cc cc cc cc cc cc cc cc - cc cc cc cc cc cc cc cc
> ................
> 0012fe88  cc cc cc cc cc cc cc cc - cc cc cc cc cc cc cc cc
> ................
> 0012fe98  cc cc cc cc cc cc cc cc - cc cc cc cc cc cc cc cc
> ................
> 0012fea8  cc cc cc cc cc cc cc cc - cc cc cc cc 00 00 00 00
> ................
> 0012feb8  18 ff 12 00 ac 10 40 00 - 03 00 00 00 04 00 00 00

> 0012fec8  80 ff 12 00 bc fb 12 00 - 00 f0 fd 7f cc cc cc cc
> ................
> 0012fed8  cc cc cc cc cc cc cc cc - cc cc cc cc cc cc cc cc
> ................
> 0012fee8  cc cc cc cc cc cc cc cc - cc cc cc cc cc cc cc cc
> ................
> 0012fef8  cc cc cc cc cc cc cc cc - cc cc cc cc cc cc cc cc
> ................
> 0012ff08  cc cc cc cc cc cc cc cc - cc cc cc cc 05 00 00 00
> ................
> 0012ff18  80 ff 12 00 53 10 40 00 - 03 00 00 00 04 00 00 00

> 0012ff28  35 00 a0 f9 bc fb 12 00 - 00 f0 fd 7f cc cc cc cc
> 5...............
> 0012ff38  cc cc cc cc cc cc cc cc - cc cc cc cc cc cc cc cc
> ................
> 0012ff48  cc cc cc cc cc cc cc cc - cc cc cc cc cc cc cc cc
> ................
> 0012ff58  cc cc cc cc cc cc cc cc - cc cc cc cc cc cc cc cc
> ................
> 0012ff68  cc cc cc cc cc cc cc cc - cc cc cc cc cc cc cc cc
> ................
> 0012ff78  04 00 00 00 03 00 00 00 - c0 ff 12 00 f9 11 40 00

> 0012ff88  01 00 00 00 b0 0e 30 00 - 10 0e 30 00 35 00 a0 f9
> ......0...0.5...
> 0012ff98  bc fb 12 00 00 f0 fd 7f - 05 00 00 c0 8b 74 11 80
> .............t..

> b) As expected I get very little stack frame :

> *----> Stack Back Trace <----*

> FramePtr ReturnAd Param#1  Param#2  Param#3  Param#4  Function Name
> 0012ffc0 77f1b9ea f9a70030 0012fbbc 7ffdf000 c0000005 <nosymbols>
> 0012fff0 00000000 00401050 00000000 000000b0 00000100
> kernel32!GetProcessPriorityBoost
> 00000000 00000000 00000000 00000000 00000000 00000000 !<nosymbols>

> *----> Raw Stack Dump <----*
> 0012ff6c  1f 10 40 00 03 00 00 00 - 04 00 00 00 09 10 40 00

> 0012ff7c  03 00 00 00 04 00 00 00 - 04 11 40 00 01 00 00 00

> 0012ff8c  d0 0e 30 00 50 0e 30 00 - 30 00 a7 f9 bc fb 12 00
> ..0.P.0.0.......
> 0012ff9c  00 f0 fd 7f 05 00 00 c0 - 8b 74 11 80 94 ff 12 00
> .........t......
> 0012ffac  b4 fd 12 00 e0 ff 12 00 - 18 1b 40 00 90 40 40 00

> 0012ffbc  00 00 00 00 f0 ff 12 00 - ea b9 f1 77 30 00 a7 f9
> ...........w0...
> 0012ffcc  bc fb 12 00 00 f0 fd 7f - 05 00 00 c0 c8 ff 12 00
> ................
> 0012ffdc  b4 fd 12 00 ff ff ff ff - 44 b9 f3 77 48 d2 f3 77
> ........D..wH..w
> 0012ffec  00 00 00 00 00 00 00 00 - 00 00 00 00 50 10 40 00

> 0012fffc  00 00 00 00 b0 00 00 00 - 00 01 00 00 ff ee ff ee
> ................
> 0013000c  02 00 00 00 00 00 00 00 - 00 fe 00 00 00 00 10 00
> ................
> 0013001c  00 20 00 00 00 02 00 00 - 00 20 00 00 36 01 00 00  . .......
> ..6...
> 0013002c  ff ef fd 7f 01 00 48 05 - 00 00 00 00 00 00 00 00
> ......H.........
> 0013003c  00 00 00 00 00 00 00 00 - d8 04 13 00 0f 00 00 00
> ................
> 0013004c  f8 ff ff ff 50 00 13 00 - 50 00 13 00 80 05 13 00
> ....P...P.......
> 0013005c  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
> ................
> 0013006c  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
> ................
> 0013007c  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
> ................
> 0013008c  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
> ................
> 0013009c  00 00 00 00 00 00 00 00 - 00 00 00 00 ff ff 00 00
> ................

> c) _Unexpectedly_ I only get a small amount of stack frame produced !? If
I
> examine the stack dump I can easily piece together the call stack and yet
> DrWatson hasn't been able to do this for me. Is this because of the other
> compiler options I've chosen ? The reason I care about this is that if I'd
> made heavy use of stack based variable declarations, I wouldn't have been
> able to piece the stack frame together by myself (as there would not be a
> deep enough stack dump in the DrWatson log file). Any answer as to why the
> stack frame trace is not as complete as it could/should be then I'd very
> much appreciate it.

> *----> Stack Back Trace <----*

> FramePtr ReturnAd Param#1  Param#2  Param#3  Param#4  Function Name
> 0012ff64 00401020 00000003 00000004 0012ffc0 00401009 <nosymbols>

> *----> Raw Stack Dump <----*
> 0012ff64  74 ff 12 00 20 10 40 00 - 03 00 00 00 04 00 00 00  t...

> 0012ff74  c0 ff 12 00 09 10 40 00 - 03 00 00 00 04 00 00 00

> 0012ff84  04 11 40 00 01 00 00 00 - d0 0e 30 00 50 0e 30 00

> 0012ff94  30 00 a7 f9 bc fb 12 00 - 00 f0 fd 7f 05 00 00 c0
> 0...............
> 0012ffa4  8b 74 11 80 94 ff 12 00 - ac fd 12 00 e0 ff 12 00
> .t..............
> 0012ffb4  18 1b 40 00 90 40 40 00 - 00 00 00 00 f0 ff 12 00

> 0012ffc4  ea b9 f1 77 30 00 a7 f9 - bc fb 12 00 00 f0 fd 7f
> ...w0...........
> 0012ffd4  05 00 00 c0 c8 ff 12 00 - ac fd 12 00 ff ff ff ff
> ................
> 0012ffe4  44 b9 f3 77 48 d2 f3 77 - 00 00 00 00 00 00 00 00
> D..wH..w........
> 0012fff4  00 00 00 00 50 10 40 00 - 00 00 00 00 b0 00 00 00

> 00130004  00 01 00 00 ff ee ff ee - 02 00 00 00 00 00 00 00
> ................
> 00130014  00 fe 00 00 00 00 10 00 - 00 20 00 00 00 02 00 00  .........
> ......
> 00130024  00 20 00 00 36 01 00 00 - ff ef fd 7f 01 00 48 05  .
> ..6.........H.
> 00130034  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
> ................
> 00130044  d8 04 13 00 0f 00 00 00 - f8 ff ff ff 50 00 13 00
> ............P...
> 00130054  50 00 13 00 80 05 13 00 - 00 00 00 00 00 00 00 00
> P...............
> 00130064  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
> ................
> 00130074  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
> ................
> 00130084  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
> ................
> 00130094  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
> ................



Mon, 13 Oct 2003 00:09:26 GMT  
 /Oy- compiler option, frame pointers and DrWatson

Quote:
> One possible problem (since I haven't seen your source) is that the actual
> crash is somewhere in a Win32 API call (because of bad arguments?)

Hi Rune,thanks for the reply.  Here is the noddy code :

#include <stdio.h>

void main(void);
int func1(int x, int y);
int func2(int x, int y);

void main(void)
{
 int a=3, b=4, c;

 c = func1(a, b);

Quote:
}

int func1(int x, int y)
{
 int z=5;

 z = func2(x, y);
 return z;

Quote:
}

int func2(int x, int y)
{
 char *p=NULL;

 *p = 21;    // crash !!!!!
 return x + y;

Quote:
}

I told you it was noddy ! :-)

The purpose of my experiment was to see how much easier it was for me to
figure out why a simple app crashes from studying the produced DrWatson log
if I enable stack frames in my "Release" builds. What I've found is that
going through the resultant stack trace by hand is very easy, but I was
somewhat disappointed to find that DrWatson hadn't done this for me. The
reason I'm looking into this is because I'm thinking of enabling the stack
frame stuff in all my release builds and thus making my job somewhat easier
should one of my release apps ever crash (never !). As I mentioned, if I
declare up a load of local variables, the stack trace in the DrWatson won't
necessarily always be "deep" enough for me to work out the call stack -
hence my disappointment.

I'm quite convinced that DrWatson should be able to do a better job in case
c). I certainly can by hand !

I'll look into this dbhelp stuff.

Cheers,
Mike.



Mon, 13 Oct 2003 19:34:35 GMT  
 /Oy- compiler option, frame pointers and DrWatson
Here's an update :
I've just tried running the same binary that I built in c) on Win2k (no SP)
and DrWatson has done a good job ! It's got a stack trace back as far as it
can go. So, MS must have worked on some of the deficiencies in the NT4.0
DrWatson. Still like to know _why_ the NT4.0 DrWatson couldn't generate the
back trace. I'd quite like to see some documentation on this.

Cheers,
Mike.

build C) faulting on Win2k :

*----> Stack Back Trace <----*

FramePtr ReturnAd Param#1  Param#2  Param#3  Param#4  Function Name
0012FF64 00401020 00000003 00000004 0012FFC0 00401009 !<nosymbols>
0012FF74 00401009 00000003 00000004 00401104 00000001 !<nosymbols>
0012FFC0 77E87903 77E9B3C1 0012F88F 7FFDF000 C0000005 !<nosymbols>
0012FFF0 00000000 00401050 00000000 000000C8 00000100
kernel32!SetUnhandledExceptionFilter

*----> Raw Stack Dump <----*

0012ff74  c0 ff 12 00 09 10 40 00 - 03 00 00 00 04 00 00 00

0012ff84  04 11 40 00 01 00 00 00 - 30 0b 30 00 b0 0a 30 00

0012ff94  c1 b3 e9 77 8f f8 12 00 - 00 f0 fd 7f 05 00 00 c0
...w............
0012ffa4  00 00 00 00 94 ff 12 00 - b0 fb 12 00 e0 ff 12 00
................
0012ffb4  18 1b 40 00 90 40 40 00 - 00 00 00 00 f0 ff 12 00

0012ffc4  03 79 e8 77 c1 b3 e9 77 - 8f f8 12 00 00 f0 fd 7f
.y.w...w........
0012ffd4  05 00 00 c0 c8 ff 12 00 - b0 fb 12 00 ff ff ff ff
................
0012ffe4  fd 13 ea 77 08 79 e8 77 - 00 00 00 00 00 00 00 00
...w.y.w........
0012fff4  00 00 00 00 50 10 40 00 - 00 00 00 00 c8 00 00 00

00130004  00 01 00 00 ff ee ff ee - 02 00 00 00 00 00 00 00
................
00130014  00 fe 00 00 00 00 10 00 - 00 20 00 00 00 02 00 00  .........
......
00130024  00 20 00 00 bf 00 00 00 - ff ef fd 7f 01 00 08 06  .
..............
00130034  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
................
00130044  98 05 13 00 0f 00 00 00 - f8 ff ff ff 50 00 13 00
............P...
00130054  50 00 13 00 40 06 13 00 - 00 00 00 00 00 00 00 00

00130064  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
................
00130074  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
................
00130084  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
................
00130094  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
................



Tue, 14 Oct 2003 00:45:48 GMT  
 /Oy- compiler option, frame pointers and DrWatson
Dr Watson is not a full de{*filter*}. It cannot read the FPO data from pdbs, so
it cannot reliably get a callstack through frame optimized code. If you take
your .dmp file and load it into WinDbg, which can read FPO data, then you
should see the full stack.

Dr Watson uses StackWalk from imagehlp/dbghelp, as does every other Win32
de{*filter*}, but without the FPO data it easily gets lost.


Quote:
> Here's an update :
> I've just tried running the same binary that I built in c) on Win2k (no
SP)
> and DrWatson has done a good job ! It's got a stack trace back as far as
it
> can go. So, MS must have worked on some of the deficiencies in the NT4.0
> DrWatson. Still like to know _why_ the NT4.0 DrWatson couldn't generate
the
> back trace. I'd quite like to see some documentation on this.

> Cheers,
> Mike.

> build C) faulting on Win2k :

> *----> Stack Back Trace <----*

> FramePtr ReturnAd Param#1  Param#2  Param#3  Param#4  Function Name
> 0012FF64 00401020 00000003 00000004 0012FFC0 00401009 !<nosymbols>
> 0012FF74 00401009 00000003 00000004 00401104 00000001 !<nosymbols>
> 0012FFC0 77E87903 77E9B3C1 0012F88F 7FFDF000 C0000005 !<nosymbols>
> 0012FFF0 00000000 00401050 00000000 000000C8 00000100
> kernel32!SetUnhandledExceptionFilter

> *----> Raw Stack Dump <----*
> 0012ff64  74 ff 12 00 20 10 40 00 - 03 00 00 00 04 00 00 00  t...

> 0012ff74  c0 ff 12 00 09 10 40 00 - 03 00 00 00 04 00 00 00

> 0012ff84  04 11 40 00 01 00 00 00 - 30 0b 30 00 b0 0a 30 00

> 0012ff94  c1 b3 e9 77 8f f8 12 00 - 00 f0 fd 7f 05 00 00 c0
> ...w............
> 0012ffa4  00 00 00 00 94 ff 12 00 - b0 fb 12 00 e0 ff 12 00
> ................
> 0012ffb4  18 1b 40 00 90 40 40 00 - 00 00 00 00 f0 ff 12 00

> 0012ffc4  03 79 e8 77 c1 b3 e9 77 - 8f f8 12 00 00 f0 fd 7f
> .y.w...w........
> 0012ffd4  05 00 00 c0 c8 ff 12 00 - b0 fb 12 00 ff ff ff ff
> ................
> 0012ffe4  fd 13 ea 77 08 79 e8 77 - 00 00 00 00 00 00 00 00
> ...w.y.w........
> 0012fff4  00 00 00 00 50 10 40 00 - 00 00 00 00 c8 00 00 00

> 00130004  00 01 00 00 ff ee ff ee - 02 00 00 00 00 00 00 00
> ................
> 00130014  00 fe 00 00 00 00 10 00 - 00 20 00 00 00 02 00 00  .........
> ......
> 00130024  00 20 00 00 bf 00 00 00 - ff ef fd 7f 01 00 08 06  .
> ..............
> 00130034  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
> ................
> 00130044  98 05 13 00 0f 00 00 00 - f8 ff ff ff 50 00 13 00
> ............P...
> 00130054  50 00 13 00 40 06 13 00 - 00 00 00 00 00 00 00 00

> 00130064  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
> ................
> 00130074  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
> ................
> 00130084  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
> ................
> 00130094  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
> ................



Wed, 15 Oct 2003 07:54:09 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. Enabling MDI frame menu option

2. Enabling MDI frame menu option

3. 7 hrs before FLATLINE! Oy! :(

4. Some help with compiler options, by any chance?

5. Missing VC++.NET Compiler and Linker Options tab

6. CSharp Compiler Options...

7. How do I set the /EHa compiler option

8. compiler options von Visual Studio

9. gcc compiler options.

10. fsingle compiler option

11. compiler option for math.h

12. ansi c enforcing compiler options

 

 
Powered by phpBB® Forum Software