Dumpexam Fails To Create Stack Trace on DEC Alpha

ID: Q163571

The information in this article applies to:

Microsoft Windows NT Workstation version 4.0
Microsoft Windows NT Server version 4.0

SYMPTOMS

Dumpexam fails to create register dump and stack trace followed by disassembled code( from the area in memory around the last instruction in the stack).

This behavior is exhibited only with memory dumps generated under Windows NT 4.0 Service Pack 2 (SP2)on DEC Alpha platforms. Pre-Service Pack 2 installations do not present this problem.

MORE INFORMATION

The report generated by Dumpexam has the following sections with appropriate information in each section:

Windows NT Crash Dump Analysis; Symbol File Load Log; !drivers; !locks -p - v -d; !memusage; !vm; !errlog; !irpzone full(irpzone is no longer supported. Use irpfind to search nonpaged pool for active Irps;) !process 0 0; !process 0 7; !process; !thread; Register Dump For Processor #0; and Stack Trace.

If no relevant results are available for any of the above debug commands, an appropriate message is included in that section indicating that:


****************************************************************
** !process
****************************************************************
*
Unable to get current process pointer.
****************************************************************
** !thread
****************************************************************
*
00000000: Unable to get thread contents

After SP2 is applied, dumpexam fails to include sections following the !memusage without generating any error messages.

The following is an example of the Register Dump For Processor #0; and Stack Trace from a pre-SP2 dump:


****************************************************************
** Register Dump For Processor #0
****************************************************************
*
v0=0000000077f9a440 t0=00000000ffffffff t1=000000000012feb4
t2=0000000077f64b8d
t3=0000000000000008 t4=0000000000000000 t5=0000000068740000
t6=0000000064616572
t7=0000000000000000 s0=0000000000000000 s1=0000000041c60246
s2=000000004203015f
s3=0000000000140000 s4=0000000000143f28 s5=0000000000000000
fp=000000000012fe94
a0=0000000077f64c12 a1=0000000000140000 a2=0000000000143f28
a3=0000000077f64cec
a4=000000000012ff00 a5=0000000077f028fa t16=000000000000061b
t9=000000000012ff04
t10=000000000526e190 t11=000000007339e9aa ra=0000000000000000
t12=0000000073390000
at=000000000012ff28 gp=0000000077f3ab6c sp=0000000077f3bdd8 zero=ffffffff
pcr=0000000000141b50 softfpcr=0000000000000000 fir=0000000000143f30
psr=05264eb0
mode=0 ie=0 irql=4

****************************************************************
** Stack Trace
****************************************************************
*
Callee-SP           Arguments to Callee                 Call Site
ffffffff 73390000 : 0012fec0 00140000 77f64cec 0526e190
0x0012ff10+0x68740000
ffffffff 00000000 : 0012fec0 00140000 77f64cec 0526e190
0x73390000+0x68740000

STATUS

Microsoft has confirmed this to be a problem in Windows NT version 4.0 Service Pack 2 for Alpha platforms. We are researching this problem and will post new information here in the Microsoft Knowledge Base as it becomes available.

Additional query words: memory.txt ntstop

Keywords : kbtool kbbug4.00 ntdistrib NTSrvWkst ntutil
Version : WinNT:4.0
Platform : WINDOWS
Issue type : kbbug