Tracing - WPP, ETW, TraceView, WinDbg

OSR_Community_User · February 6, 2007, 11:42am

I have a KMDF USB driver that includes WPP tracing. The target box is XP
sp2. I have the driver code setup so that I can switch between WPP tracing
for driver release and Debug Tracing for development. I’ve been using Debug
Tracing for all of my diagnostics but I thought I would give WPP tracing a
try. I’m thinking that if I deploy a release version of the driver and
there is a problem, my first attempt at fixing the problem will be to enable
tracing at the customer’s site using a “ctl” file and then look at the
resulting “etl” output once the problem has been recorded. My second
attempt at fixing the problem will be to have the entire PC sent back in
which case I would like to connect to the box with firewire/WinDbg and view
the trace output.

I wanted to test these situations so I built the driver with WPP enabled.
For the second case where I connect to the target with WinDbg, the only way
I could find from the docs to get trace output to WinDbg is to use TraceView
(or command line equivalent) to start a trace session and enable trace
output to WinDbg as well as TraceView. I’ve tried this 2 times and always
get the crash shown below.

Question 1: Is there another way to enable trace output to WinDbg besides
using TraceView?
Question 2: Is this crash a legitimate bug?

LAST_CONTROL_TRANSFER: from 805328e7 to 804e3b25

STACK_TEXT:
ba12eb58 805328e7 00000003 ba12eeb4 00000000
nt!RtlpBreakWithStatusInstruction
ba12eba4 805333be 00000003 8069e000 f7988098 nt!KiBugCheckDebugBreak+0x19
ba12ef84 804e2158 0000000a 8069e000 00000002 nt!KeBugCheck2+0x574
ba12ef84 f7988098 0000000a 8069e000 00000002 nt!KiTrap0E+0x233
ba12f01c f7988262 80691918 0000fffc ffdff13c kdcom!KdpComputeChecksum+0x12
ba12f04c 8067cf12 00000007 ba12f1e0 ba12f1d8 kdcom!KdSendPacket+0x24
ba12f0c8 8067d0bd 00000007 ba12f1e0 ba12f1d8 nt!KdpSendWaitContinue+0x2e0
ba12f1e8 805325a4 ba12f61c ffdff13c 00000000
nt!KdpReportExceptionStateChange+0x8a
ba12f208 8067e137 ba12f670 00000000 ba12f600 nt!KdpReport+0x60
ba12f234 804fa243 ba12f670 00000000 ba12f61c nt!KdpTrap+0x108
ba12f600 804dfada ba12f61c 00000000 ba12f670 nt!KiDispatchException+0x129
ba12f668 804e0208 ba12f72c 804e3b26 badb0d00 nt!CommonDispatchException+0x4d
ba12f668 804e3b26 ba12f72c 804e3b26 badb0d00 nt!KiTrap03+0xad
ba12f6e0 805328e7 00000003 ba12fa3c 00000000
nt!RtlpBreakWithStatusInstruction+0x1
ba12f72c 805333be 00000003 c0300804 81800000 nt!KiBugCheckDebugBreak+0x19
ba12fb0c 805339ae 000000be 8069b000 0069b121 nt!KeBugCheck2+0x574
ba12fb2c 805246fb 000000be 8069b000 0069b121 nt!KeBugCheckEx+0x1b
ba12fb78 804e1ff1 00000001 8069b000 00000000 nt!MmAccessFault+0x6f5
ba12fb78 8053af55 00000001 8069b000 00000000 nt!KiTrap0E+0xcc
ba12fc60 8067d6bc 85fc1bf8 00000000 8069b000 nt!MmDbgCopyMemory+0x38a
ba12fc88 8067c504 85fc1bf8 00000000 8069b000 nt!KdpCopyMemoryChunks+0x68
ba12fd00 8067cc1c ba12fd0c 0000ffff 85fb6000 nt!KdpSendTraceData+0x28
ba12fd14 8067a1fb 85fb6001 00000000 86152010 nt!KdReportTraceData+0x41
ba12fd58 806408a0 00000000 85fb6000 00000000 nt!WmipFlushBuffer+0x336
ba12fd80 80640ac9 86152054 00000001 00000000 nt!WmipFlushActiveBuffers+0x18d
ba12fdac 8057dfed 00000001 00000000 00000000 nt!WmipLogger+0x16f
ba12fddc 804fa477 8064095a 86152000 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
kdcom!KdpComputeChecksum+12
f7988098 0fb631 movzx esi,byte ptr [ecx]

SYMBOL_STACK_INDEX: 4

SYMBOL_NAME: kdcom!KdpComputeChecksum+12

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: kdcom

IMAGE_NAME: kd1394.dll

DEBUG_FLR_IMAGE_TIMESTAMP: 41107b3a

FAILURE_BUCKET_ID: 0xD1_VRF_kdcom!KdpComputeChecksum+12

BUCKET_ID: 0xD1_VRF_kdcom!KdpComputeChecksum+12

Followup: MachineOwner

OSR_Community_User · February 6, 2007, 12:07pm

You can enable trace with the command line tools available in the
WDK/DDK:

I would recommend using the latest traceview part of the WDK and if that
fails let me know. You must also have the windbg.dll from the debugger
for traceview to work fine.

Tracelog (part of the WDK/DDK) take a look at the documentation on
MSDN. You can also use logman which is a tool part of the OS.

Fist case:
Start Tracing
Tracelog -start sessionname -guid #theProviderGuidInyourComponent -flags
yourflags -level levelIfUsed -f logfile.etl

Then run your scenario

Stop tracing.
tracelog -stop sessionname

You need the TMF files to view the events

Tracepdb -f yourdriver.pdb // this is a tool that extracts the tmf
files

tracefmt -display -p . logfile.etl // this tool will show you the
events and save them to a file.

The windbg scenario.

Enable tracing on your target machine using tracelog like above, but you
need to add the -kd obtion.

Then on your windbg kd machine, you need to use the wmitrace extension
which is part of the debugger to view the events.

!wmitrace.help to see the options.

But you must locate your trace session, which is provided when you ran
tracelog on the target machiene. Then you can see the trace buffers of
that session on the debugger.
In your debugger machine you need to have a copy of the tmf files
generated from tracepdb and your driver pdb file so that the extension
can decode the events.

!wmitrace extension should work on xp with the latest updates.

Thanks,
Jose Sua
Microsoft Corporation
This posting is provided “AS IS” with no warranties and confers no
rights.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David Voeller
Sent: Tuesday, February 06, 2007 8:42 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Tracing - WPP, ETW, TraceView, WinDbg

I have a KMDF USB driver that includes WPP tracing. The target box is
XP
sp2. I have the driver code setup so that I can switch between WPP
tracing
for driver release and Debug Tracing for development. I’ve been using
Debug
Tracing for all of my diagnostics but I thought I would give WPP tracing
a
try. I’m thinking that if I deploy a release version of the driver and
there is a problem, my first attempt at fixing the problem will be to
enable
tracing at the customer’s site using a “ctl” file and then look at the
resulting “etl” output once the problem has been recorded. My second
attempt at fixing the problem will be to have the entire PC sent back in

which case I would like to connect to the box with firewire/WinDbg and
view
the trace output.

I wanted to test these situations so I built the driver with WPP
enabled.
For the second case where I connect to the target with WinDbg, the only
way
I could find from the docs to get trace output to WinDbg is to use
TraceView
(or command line equivalent) to start a trace session and enable trace
output to WinDbg as well as TraceView. I’ve tried this 2 times and
always
get the crash shown below.

Question 1: Is there another way to enable trace output to WinDbg
besides
using TraceView?
Question 2: Is this crash a legitimate bug?

LAST_CONTROL_TRANSFER: from 805328e7 to 804e3b25

STACK_TEXT:
ba12eb58 805328e7 00000003 ba12eeb4 00000000
nt!RtlpBreakWithStatusInstruction
ba12eba4 805333be 00000003 8069e000 f7988098
nt!KiBugCheckDebugBreak+0x19
ba12ef84 804e2158 0000000a 8069e000 00000002 nt!KeBugCheck2+0x574
ba12ef84 f7988098 0000000a 8069e000 00000002 nt!KiTrap0E+0x233
ba12f01c f7988262 80691918 0000fffc ffdff13c
kdcom!KdpComputeChecksum+0x12
ba12f04c 8067cf12 00000007 ba12f1e0 ba12f1d8 kdcom!KdSendPacket+0x24
ba12f0c8 8067d0bd 00000007 ba12f1e0 ba12f1d8
nt!KdpSendWaitContinue+0x2e0
ba12f1e8 805325a4 ba12f61c ffdff13c 00000000
nt!KdpReportExceptionStateChange+0x8a
ba12f208 8067e137 ba12f670 00000000 ba12f600 nt!KdpReport+0x60
ba12f234 804fa243 ba12f670 00000000 ba12f61c nt!KdpTrap+0x108
ba12f600 804dfada ba12f61c 00000000 ba12f670
nt!KiDispatchException+0x129
ba12f668 804e0208 ba12f72c 804e3b26 badb0d00
nt!CommonDispatchException+0x4d
ba12f668 804e3b26 ba12f72c 804e3b26 badb0d00 nt!KiTrap03+0xad
ba12f6e0 805328e7 00000003 ba12fa3c 00000000
nt!RtlpBreakWithStatusInstruction+0x1
ba12f72c 805333be 00000003 c0300804 81800000
nt!KiBugCheckDebugBreak+0x19
ba12fb0c 805339ae 000000be 8069b000 0069b121 nt!KeBugCheck2+0x574
ba12fb2c 805246fb 000000be 8069b000 0069b121 nt!KeBugCheckEx+0x1b
ba12fb78 804e1ff1 00000001 8069b000 00000000 nt!MmAccessFault+0x6f5
ba12fb78 8053af55 00000001 8069b000 00000000 nt!KiTrap0E+0xcc
ba12fc60 8067d6bc 85fc1bf8 00000000 8069b000 nt!MmDbgCopyMemory+0x38a
ba12fc88 8067c504 85fc1bf8 00000000 8069b000 nt!KdpCopyMemoryChunks+0x68
ba12fd00 8067cc1c ba12fd0c 0000ffff 85fb6000 nt!KdpSendTraceData+0x28
ba12fd14 8067a1fb 85fb6001 00000000 86152010 nt!KdReportTraceData+0x41
ba12fd58 806408a0 00000000 85fb6000 00000000 nt!WmipFlushBuffer+0x336
ba12fd80 80640ac9 86152054 00000001 00000000
nt!WmipFlushActiveBuffers+0x18d
ba12fdac 8057dfed 00000001 00000000 00000000 nt!WmipLogger+0x16f
ba12fddc 804fa477 8064095a 86152000 00000000
nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
kdcom!KdpComputeChecksum+12
f7988098 0fb631 movzx esi,byte ptr [ecx]

SYMBOL_STACK_INDEX: 4

SYMBOL_NAME: kdcom!KdpComputeChecksum+12

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: kdcom

IMAGE_NAME: kd1394.dll

DEBUG_FLR_IMAGE_TIMESTAMP: 41107b3a

FAILURE_BUCKET_ID: 0xD1_VRF_kdcom!KdpComputeChecksum+12

BUCKET_ID: 0xD1_VRF_kdcom!KdpComputeChecksum+12

Followup: MachineOwner

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

OSR_Community_User · February 6, 2007, 4:23pm

I still have the crash in TraceView.

* I have WinDbg version 6.6.0007.5 on both my target and host PC.
* I am using TraceView.exe version 2.1.1 Copyright 2005 from WDK RTM 6000.
(Note that I had the same version on my target as my host but the file size
was different so I made sure to copy everything from
C:\WINDDK\6000\tools\tracing\i386 to my target box).
* I could not find a “windbg.dll” file anywhere on both my target and host
PC.

* I ran tracelog -start MySession -guid
#635CC065-EFCD-4593-84E6-BC1354963E8F -flags ff -level 5 -f MyLog.etl -kd

This resulted in the command line output:
Logger Started…
Enablling trace to logger 2
Operation Status: 0L The operation completed successfully.
Logger Name: MySession
Logger Id: 0x2
Logger Thread Id: 00000F10
Guid: 635CC065-EFCD-4593-84E6-BC1354963E8F
Buffer Size: 3 kb
Maximum Buffers: 25
Minimum Buffers: 3
Number of Bufferes: 3
Free Buffers: 2
Buffers Written: 1
Events Lost: 0
Log Buffers Lost: 0
Real Time Buffers Lost: 0
AgeLimit: 15
ClockType: SystemTime
Log Mode: Sequential
Kd Filter mode enabled
Maximum File Size: not set
Buffer Flush Timer: not set
Enabled tracing: 0x00000001
Log Filename: blah blah MyLog.etl

I loaded the wmitrace “!load wmitrace.dll” but that was as far as I got with
the command line option to send trace output to WinDbg.

* I enabled tracing using the latest version of TraceView and had a very
similar crash as the previous times.
kd> !analyze -v
********************************************
*
*
* Bugcheck Analysis *
*
*
********************************************

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address at
an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: 8069e000, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: f7988098, address which referenced memory

Debugging Details:

READ_ADDRESS: 8069e000

CURRENT_IRQL: 2

FAULTING_IP:
kdcom!KdpComputeChecksum+12
f7988098 0fb631 movzx esi,byte ptr [ecx]

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xD1

PROCESS_NAME: System

TRAP_FRAME: b9ff7b90 – (.trap ffffffffb9ff7b90)
ErrCode = 00000003
eax=00000004 ebx=85a04bf8 ecx=00000001 edx=00000002 esi=b9ff7c3c
edi=8069b000
eip=8053af55 esp=b9ff7c04 ebp=b9ff7c60 iopl=0 nv up di pl nz na po
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010002
nt!MmDbgCopyMemory+0x38a:
8053af55 f3a5 rep movs dword ptr es:[edi],dword ptr [esi]
es:0023:8069b000=50524920 ds:0023:b9ff7c3c=ffffffff
Resetting default scope

EXCEPTION_RECORD: b9ff761c – (.exr ffffffffb9ff761c)
ExceptionAddress: 804e3b25 (nt!RtlpBreakWithStatusInstruction)
ExceptionCode: 80000003 (Break instruction exception)
ExceptionFlags: 00000000
NumberParameters: 3
Parameter[0]: 00000000
Parameter[1]: 8050589d
Parameter[2]: 0000006a

LAST_CONTROL_TRANSFER: from 805328e7 to 804e3b25

STACK_TEXT:
b9ff6b58 805328e7 00000003 b9ff6eb4 00000000
nt!RtlpBreakWithStatusInstruction
b9ff6ba4 805333be 00000003 8069e000 f7988098 nt!KiBugCheckDebugBreak+0x19
b9ff6f84 804e2158 0000000a 8069e000 00000002 nt!KeBugCheck2+0x574
b9ff6f84 f7988098 0000000a 8069e000 00000002 nt!KiTrap0E+0x233
b9ff701c f7988262 80691918 0000fffc ffdff13c kdcom!KdpComputeChecksum+0x12
b9ff704c 8067cf12 00000007 b9ff71e0 b9ff71d8 kdcom!KdSendPacket+0x24
b9ff70c8 8067d0bd 00000007 b9ff71e0 b9ff71d8 nt!KdpSendWaitContinue+0x2e0
b9ff71e8 805325a4 b9ff761c ffdff13c 00000000
nt!KdpReportExceptionStateChange+0x8a
b9ff7208 8067e137 b9ff7670 00000000 b9ff7600 nt!KdpReport+0x60
b9ff7234 804fa243 b9ff7670 00000000 b9ff761c nt!KdpTrap+0x108
b9ff7600 804dfada b9ff761c 00000000 b9ff7670 nt!KiDispatchException+0x129
b9ff7668 804e0208 b9ff772c 804e3b26 badb0d00 nt!CommonDispatchException+0x4d
b9ff7668 804e3b26 b9ff772c 804e3b26 badb0d00 nt!KiTrap03+0xad
b9ff76e0 805328e7 00000003 b9ff7a3c 00000000
nt!RtlpBreakWithStatusInstruction+0x1
b9ff772c 805333be 00000003 c0300804 81800000 nt!KiBugCheckDebugBreak+0x19
b9ff7b0c 805339ae 000000be 8069b000 0069b121 nt!KeBugCheck2+0x574
b9ff7b2c 805246fb 000000be 8069b000 0069b121 nt!KeBugCheckEx+0x1b
b9ff7b78 804e1ff1 00000001 8069b000 00000000 nt!MmAccessFault+0x6f5
b9ff7b78 8053af55 00000001 8069b000 00000000 nt!KiTrap0E+0xcc
b9ff7c60 8067d6bc 85a04bf8 00000000 8069b000 nt!MmDbgCopyMemory+0x38a
b9ff7c88 8067c504 85a04bf8 00000000 8069b000 nt!KdpCopyMemoryChunks+0x68
b9ff7d00 8067cc1c b9ff7d0c 0000ffff 859f9000 nt!KdpSendTraceData+0x28
b9ff7d14 8067a1fb 859f9001 00000000 85ac5010 nt!KdReportTraceData+0x41
b9ff7d58 806408a0 00000000 859f9000 00000000 nt!WmipFlushBuffer+0x336
b9ff7d80 80640ac9 85ac5054 00000001 00000000 nt!WmipFlushActiveBuffers+0x18d
b9ff7dac 8057dfed 00000001 00000000 00000000 nt!WmipLogger+0x16f
b9ff7ddc 804fa477 8064095a 85ac5000 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
kdcom!KdpComputeChecksum+12
f7988098 0fb631 movzx esi,byte ptr [ecx]

SYMBOL_STACK_INDEX: 4

SYMBOL_NAME: kdcom!KdpComputeChecksum+12

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: kdcom

IMAGE_NAME: kd1394.dll

DEBUG_FLR_IMAGE_TIMESTAMP: 41107b3a

FAILURE_BUCKET_ID: 0xD1_VRF_kdcom!KdpComputeChecksum+12

BUCKET_ID: 0xD1_VRF_kdcom!KdpComputeChecksum+12

Followup: MachineOwner

“Jose Sua” wrote in message
news:xxxxx@ntdev…
You can enable trace with the command line tools available in the
WDK/DDK:

I would recommend using the latest traceview part of the WDK and if that
fails let me know. You must also have the windbg.dll from the debugger
for traceview to work fine.

Tracelog (part of the WDK/DDK) take a look at the documentation on
MSDN. You can also use logman which is a tool part of the OS.

Fist case:
Start Tracing
Tracelog -start sessionname -guid #theProviderGuidInyourComponent -flags
yourflags -level levelIfUsed -f logfile.etl

Then run your scenario

Stop tracing.
tracelog -stop sessionname

You need the TMF files to view the events

Tracepdb -f yourdriver.pdb // this is a tool that extracts the tmf
files

tracefmt -display -p . logfile.etl // this tool will show you the
events and save them to a file.

The windbg scenario.

Enable tracing on your target machine using tracelog like above, but you
need to add the -kd obtion.

Then on your windbg kd machine, you need to use the wmitrace extension
which is part of the debugger to view the events.

!wmitrace.help to see the options.

But you must locate your trace session, which is provided when you ran
tracelog on the target machiene. Then you can see the trace buffers of
that session on the debugger.
In your debugger machine you need to have a copy of the tmf files
generated from tracepdb and your driver pdb file so that the extension
can decode the events.

!wmitrace extension should work on xp with the latest updates.

Thanks,
Jose Sua
Microsoft Corporation
This posting is provided “AS IS” with no warranties and confers no
rights.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David Voeller
Sent: Tuesday, February 06, 2007 8:42 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Tracing - WPP, ETW, TraceView, WinDbg

I have a KMDF USB driver that includes WPP tracing. The target box is
XP
sp2. I have the driver code setup so that I can switch between WPP
tracing
for driver release and Debug Tracing for development. I’ve been using
Debug
Tracing for all of my diagnostics but I thought I would give WPP tracing
a
try. I’m thinking that if I deploy a release version of the driver and
there is a problem, my first attempt at fixing the problem will be to
enable
tracing at the customer’s site using a “ctl” file and then look at the
resulting “etl” output once the problem has been recorded. My second
attempt at fixing the problem will be to have the entire PC sent back in

which case I would like to connect to the box with firewire/WinDbg and
view
the trace output.

I wanted to test these situations so I built the driver with WPP
enabled.
For the second case where I connect to the target with WinDbg, the only
way
I could find from the docs to get trace output to WinDbg is to use
TraceView
(or command line equivalent) to start a trace session and enable trace
output to WinDbg as well as TraceView. I’ve tried this 2 times and
always
get the crash shown below.

Question 1: Is there another way to enable trace output to WinDbg
besides
using TraceView?
Question 2: Is this crash a legitimate bug?

LAST_CONTROL_TRANSFER: from 805328e7 to 804e3b25

STACK_TEXT:
ba12eb58 805328e7 00000003 ba12eeb4 00000000
nt!RtlpBreakWithStatusInstruction
ba12eba4 805333be 00000003 8069e000 f7988098
nt!KiBugCheckDebugBreak+0x19
ba12ef84 804e2158 0000000a 8069e000 00000002 nt!KeBugCheck2+0x574
ba12ef84 f7988098 0000000a 8069e000 00000002 nt!KiTrap0E+0x233
ba12f01c f7988262 80691918 0000fffc ffdff13c
kdcom!KdpComputeChecksum+0x12
ba12f04c 8067cf12 00000007 ba12f1e0 ba12f1d8 kdcom!KdSendPacket+0x24
ba12f0c8 8067d0bd 00000007 ba12f1e0 ba12f1d8
nt!KdpSendWaitContinue+0x2e0
ba12f1e8 805325a4 ba12f61c ffdff13c 00000000
nt!KdpReportExceptionStateChange+0x8a
ba12f208 8067e137 ba12f670 00000000 ba12f600 nt!KdpReport+0x60
ba12f234 804fa243 ba12f670 00000000 ba12f61c nt!KdpTrap+0x108
ba12f600 804dfada ba12f61c 00000000 ba12f670
nt!KiDispatchException+0x129
ba12f668 804e0208 ba12f72c 804e3b26 badb0d00
nt!CommonDispatchException+0x4d
ba12f668 804e3b26 ba12f72c 804e3b26 badb0d00 nt!KiTrap03+0xad
ba12f6e0 805328e7 00000003 ba12fa3c 00000000
nt!RtlpBreakWithStatusInstruction+0x1
ba12f72c 805333be 00000003 c0300804 81800000
nt!KiBugCheckDebugBreak+0x19
ba12fb0c 805339ae 000000be 8069b000 0069b121 nt!KeBugCheck2+0x574
ba12fb2c 805246fb 000000be 8069b000 0069b121 nt!KeBugCheckEx+0x1b
ba12fb78 804e1ff1 00000001 8069b000 00000000 nt!MmAccessFault+0x6f5
ba12fb78 8053af55 00000001 8069b000 00000000 nt!KiTrap0E+0xcc
ba12fc60 8067d6bc 85fc1bf8 00000000 8069b000 nt!MmDbgCopyMemory+0x38a
ba12fc88 8067c504 85fc1bf8 00000000 8069b000 nt!KdpCopyMemoryChunks+0x68
ba12fd00 8067cc1c ba12fd0c 0000ffff 85fb6000 nt!KdpSendTraceData+0x28
ba12fd14 8067a1fb 85fb6001 00000000 86152010 nt!KdReportTraceData+0x41
ba12fd58 806408a0 00000000 85fb6000 00000000 nt!WmipFlushBuffer+0x336
ba12fd80 80640ac9 86152054 00000001 00000000
nt!WmipFlushActiveBuffers+0x18d
ba12fdac 8057dfed 00000001 00000000 00000000 nt!WmipLogger+0x16f
ba12fddc 804fa477 8064095a 86152000 00000000
nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
kdcom!KdpComputeChecksum+12
f7988098 0fb631 movzx esi,byte ptr [ecx]

SYMBOL_STACK_INDEX: 4

SYMBOL_NAME: kdcom!KdpComputeChecksum+12

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: kdcom

IMAGE_NAME: kd1394.dll

DEBUG_FLR_IMAGE_TIMESTAMP: 41107b3a

FAILURE_BUCKET_ID: 0xD1_VRF_kdcom!KdpComputeChecksum+12

BUCKET_ID: 0xD1_VRF_kdcom!KdpComputeChecksum+12

Followup: MachineOwner
---------

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

OSR_Community_User · February 6, 2007, 5:04pm

I was referring to dbghelp.dll now windbg.dll, sorry for the typo.

Your logger ID is:
Logger Id: 0x2

On the debugger box.

!wmitrace.help gives all the options.

!wmitrace.searchpath to set the path to the tmf files.

!wmitrace.logger 2 gives you info about your trace session

!wmitrace.strdump 2 gives info about the trace info strucs

So once you start tracing with tracelog, you don’t need to use traceview
at all.
Check info about WPP/ETW tracing on MSDN.

The crash with traceview could be that traceview is not using 3k buffers
when starting the session. In the output from tracelog below it should
work Buffer Size: 3 kb.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David Voeller
Sent: Tuesday, February 06, 2007 1:23 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Tracing - WPP, ETW, TraceView, WinDbg

I still have the crash in TraceView.

* I have WinDbg version 6.6.0007.5 on both my target and host PC.
* I am using TraceView.exe version 2.1.1 Copyright 2005 from WDK RTM
6000.
(Note that I had the same version on my target as my host but the file
size
was different so I made sure to copy everything from
C:\WINDDK\6000\tools\tracing\i386 to my target box).
* I could not find a “windbg.dll” file anywhere on both my target and
host
PC.

* I ran tracelog -start MySession -guid
#635CC065-EFCD-4593-84E6-BC1354963E8F -flags ff -level 5 -f MyLog.etl
-kd

This resulted in the command line output:
Logger Started…
Enablling trace to logger 2
Operation Status: 0L The operation completed successfully.
Logger Name: MySession
Logger Id: 0x2
Logger Thread Id: 00000F10
Guid:
635CC065-EFCD-4593-84E6-BC1354963E8F
Buffer Size: 3 kb
Maximum Buffers: 25
Minimum Buffers: 3
Number of Bufferes: 3
Free Buffers: 2
Buffers Written: 1
Events Lost: 0
Log Buffers Lost: 0
Real Time Buffers Lost: 0
AgeLimit: 15
ClockType: SystemTime
Log Mode: Sequential
Kd Filter mode enabled
Maximum File Size: not set
Buffer Flush Timer: not set
Enabled tracing: 0x00000001
Log Filename: blah blah MyLog.etl

I loaded the wmitrace “!load wmitrace.dll” but that was as far as I got
with
the command line option to send trace output to WinDbg.

* I enabled tracing using the latest version of TraceView and had a very

similar crash as the previous times.
kd> !analyze -v
********************************************
*
*
* Bugcheck Analysis *
*
*
********************************************

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address
at
an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: 8069e000, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: f7988098, address which referenced memory

Debugging Details:

READ_ADDRESS: 8069e000

CURRENT_IRQL: 2

FAULTING_IP:
kdcom!KdpComputeChecksum+12
f7988098 0fb631 movzx esi,byte ptr [ecx]

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xD1

PROCESS_NAME: System

TRAP_FRAME: b9ff7b90 – (.trap ffffffffb9ff7b90)
ErrCode = 00000003
eax=00000004 ebx=85a04bf8 ecx=00000001 edx=00000002 esi=b9ff7c3c
edi=8069b000
eip=8053af55 esp=b9ff7c04 ebp=b9ff7c60 iopl=0 nv up di pl nz na
po
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010002
nt!MmDbgCopyMemory+0x38a:
8053af55 f3a5 rep movs dword ptr es:[edi],dword ptr [esi]
es:0023:8069b000=50524920 ds:0023:b9ff7c3c=ffffffff
Resetting default scope

EXCEPTION_RECORD: b9ff761c – (.exr ffffffffb9ff761c)
ExceptionAddress: 804e3b25 (nt!RtlpBreakWithStatusInstruction)
ExceptionCode: 80000003 (Break instruction exception)
ExceptionFlags: 00000000
NumberParameters: 3
Parameter[0]: 00000000
Parameter[1]: 8050589d
Parameter[2]: 0000006a

LAST_CONTROL_TRANSFER: from 805328e7 to 804e3b25

STACK_TEXT:
b9ff6b58 805328e7 00000003 b9ff6eb4 00000000
nt!RtlpBreakWithStatusInstruction
b9ff6ba4 805333be 00000003 8069e000 f7988098
nt!KiBugCheckDebugBreak+0x19
b9ff6f84 804e2158 0000000a 8069e000 00000002 nt!KeBugCheck2+0x574
b9ff6f84 f7988098 0000000a 8069e000 00000002 nt!KiTrap0E+0x233
b9ff701c f7988262 80691918 0000fffc ffdff13c
kdcom!KdpComputeChecksum+0x12
b9ff704c 8067cf12 00000007 b9ff71e0 b9ff71d8 kdcom!KdSendPacket+0x24
b9ff70c8 8067d0bd 00000007 b9ff71e0 b9ff71d8
nt!KdpSendWaitContinue+0x2e0
b9ff71e8 805325a4 b9ff761c ffdff13c 00000000
nt!KdpReportExceptionStateChange+0x8a
b9ff7208 8067e137 b9ff7670 00000000 b9ff7600 nt!KdpReport+0x60
b9ff7234 804fa243 b9ff7670 00000000 b9ff761c nt!KdpTrap+0x108
b9ff7600 804dfada b9ff761c 00000000 b9ff7670
nt!KiDispatchException+0x129
b9ff7668 804e0208 b9ff772c 804e3b26 badb0d00
nt!CommonDispatchException+0x4d
b9ff7668 804e3b26 b9ff772c 804e3b26 badb0d00 nt!KiTrap03+0xad
b9ff76e0 805328e7 00000003 b9ff7a3c 00000000
nt!RtlpBreakWithStatusInstruction+0x1
b9ff772c 805333be 00000003 c0300804 81800000
nt!KiBugCheckDebugBreak+0x19
b9ff7b0c 805339ae 000000be 8069b000 0069b121 nt!KeBugCheck2+0x574
b9ff7b2c 805246fb 000000be 8069b000 0069b121 nt!KeBugCheckEx+0x1b
b9ff7b78 804e1ff1 00000001 8069b000 00000000 nt!MmAccessFault+0x6f5
b9ff7b78 8053af55 00000001 8069b000 00000000 nt!KiTrap0E+0xcc
b9ff7c60 8067d6bc 85a04bf8 00000000 8069b000 nt!MmDbgCopyMemory+0x38a
b9ff7c88 8067c504 85a04bf8 00000000 8069b000 nt!KdpCopyMemoryChunks+0x68
b9ff7d00 8067cc1c b9ff7d0c 0000ffff 859f9000 nt!KdpSendTraceData+0x28
b9ff7d14 8067a1fb 859f9001 00000000 85ac5010 nt!KdReportTraceData+0x41
b9ff7d58 806408a0 00000000 859f9000 00000000 nt!WmipFlushBuffer+0x336
b9ff7d80 80640ac9 85ac5054 00000001 00000000
nt!WmipFlushActiveBuffers+0x18d
b9ff7dac 8057dfed 00000001 00000000 00000000 nt!WmipLogger+0x16f
b9ff7ddc 804fa477 8064095a 85ac5000 00000000
nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
kdcom!KdpComputeChecksum+12
f7988098 0fb631 movzx esi,byte ptr [ecx]

SYMBOL_STACK_INDEX: 4

SYMBOL_NAME: kdcom!KdpComputeChecksum+12

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: kdcom

IMAGE_NAME: kd1394.dll

DEBUG_FLR_IMAGE_TIMESTAMP: 41107b3a

FAILURE_BUCKET_ID: 0xD1_VRF_kdcom!KdpComputeChecksum+12

BUCKET_ID: 0xD1_VRF_kdcom!KdpComputeChecksum+12

Followup: MachineOwner

“Jose Sua” wrote in message
news:xxxxx@ntdev…
You can enable trace with the command line tools available in the
WDK/DDK:

I would recommend using the latest traceview part of the WDK and if that
fails let me know. You must also have the windbg.dll from the debugger
for traceview to work fine.

Tracelog (part of the WDK/DDK) take a look at the documentation on
MSDN. You can also use logman which is a tool part of the OS.

Fist case:
Start Tracing
Tracelog -start sessionname -guid #theProviderGuidInyourComponent -flags
yourflags -level levelIfUsed -f logfile.etl

Then run your scenario

Stop tracing.
tracelog -stop sessionname

You need the TMF files to view the events

Tracepdb -f yourdriver.pdb // this is a tool that extracts the tmf
files

tracefmt -display -p . logfile.etl // this tool will show you the
events and save them to a file.

The windbg scenario.

Enable tracing on your target machine using tracelog like above, but you
need to add the -kd obtion.

Then on your windbg kd machine, you need to use the wmitrace extension
which is part of the debugger to view the events.

!wmitrace.help to see the options.

But you must locate your trace session, which is provided when you ran
tracelog on the target machiene. Then you can see the trace buffers of
that session on the debugger.
In your debugger machine you need to have a copy of the tmf files
generated from tracepdb and your driver pdb file so that the extension
can decode the events.

!wmitrace extension should work on xp with the latest updates.

Thanks,
Jose Sua
Microsoft Corporation
This posting is provided “AS IS” with no warranties and confers no
rights.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David Voeller
Sent: Tuesday, February 06, 2007 8:42 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Tracing - WPP, ETW, TraceView, WinDbg

I have a KMDF USB driver that includes WPP tracing. The target box is
XP
sp2. I have the driver code setup so that I can switch between WPP
tracing
for driver release and Debug Tracing for development. I’ve been using
Debug
Tracing for all of my diagnostics but I thought I would give WPP tracing
a
try. I’m thinking that if I deploy a release version of the driver and
there is a problem, my first attempt at fixing the problem will be to
enable
tracing at the customer’s site using a “ctl” file and then look at the
resulting “etl” output once the problem has been recorded. My second
attempt at fixing the problem will be to have the entire PC sent back in

which case I would like to connect to the box with firewire/WinDbg and
view
the trace output.

I wanted to test these situations so I built the driver with WPP
enabled.
For the second case where I connect to the target with WinDbg, the only
way
I could find from the docs to get trace output to WinDbg is to use
TraceView
(or command line equivalent) to start a trace session and enable trace
output to WinDbg as well as TraceView. I’ve tried this 2 times and
always
get the crash shown below.

Question 1: Is there another way to enable trace output to WinDbg
besides
using TraceView?
Question 2: Is this crash a legitimate bug?

LAST_CONTROL_TRANSFER: from 805328e7 to 804e3b25

STACK_TEXT:
ba12eb58 805328e7 00000003 ba12eeb4 00000000
nt!RtlpBreakWithStatusInstruction
ba12eba4 805333be 00000003 8069e000 f7988098
nt!KiBugCheckDebugBreak+0x19
ba12ef84 804e2158 0000000a 8069e000 00000002 nt!KeBugCheck2+0x574
ba12ef84 f7988098 0000000a 8069e000 00000002 nt!KiTrap0E+0x233
ba12f01c f7988262 80691918 0000fffc ffdff13c
kdcom!KdpComputeChecksum+0x12
ba12f04c 8067cf12 00000007 ba12f1e0 ba12f1d8 kdcom!KdSendPacket+0x24
ba12f0c8 8067d0bd 00000007 ba12f1e0 ba12f1d8
nt!KdpSendWaitContinue+0x2e0
ba12f1e8 805325a4 ba12f61c ffdff13c 00000000
nt!KdpReportExceptionStateChange+0x8a
ba12f208 8067e137 ba12f670 00000000 ba12f600 nt!KdpReport+0x60
ba12f234 804fa243 ba12f670 00000000 ba12f61c nt!KdpTrap+0x108
ba12f600 804dfada ba12f61c 00000000 ba12f670
nt!KiDispatchException+0x129
ba12f668 804e0208 ba12f72c 804e3b26 badb0d00
nt!CommonDispatchException+0x4d
ba12f668 804e3b26 ba12f72c 804e3b26 badb0d00 nt!KiTrap03+0xad
ba12f6e0 805328e7 00000003 ba12fa3c 00000000
nt!RtlpBreakWithStatusInstruction+0x1
ba12f72c 805333be 00000003 c0300804 81800000
nt!KiBugCheckDebugBreak+0x19
ba12fb0c 805339ae 000000be 8069b000 0069b121 nt!KeBugCheck2+0x574
ba12fb2c 805246fb 000000be 8069b000 0069b121 nt!KeBugCheckEx+0x1b
ba12fb78 804e1ff1 00000001 8069b000 00000000 nt!MmAccessFault+0x6f5
ba12fb78 8053af55 00000001 8069b000 00000000 nt!KiTrap0E+0xcc
ba12fc60 8067d6bc 85fc1bf8 00000000 8069b000 nt!MmDbgCopyMemory+0x38a
ba12fc88 8067c504 85fc1bf8 00000000 8069b000 nt!KdpCopyMemoryChunks+0x68
ba12fd00 8067cc1c ba12fd0c 0000ffff 85fb6000 nt!KdpSendTraceData+0x28
ba12fd14 8067a1fb 85fb6001 00000000 86152010 nt!KdReportTraceData+0x41
ba12fd58 806408a0 00000000 85fb6000 00000000 nt!WmipFlushBuffer+0x336
ba12fd80 80640ac9 86152054 00000001 00000000
nt!WmipFlushActiveBuffers+0x18d
ba12fdac 8057dfed 00000001 00000000 00000000 nt!WmipLogger+0x16f
ba12fddc 804fa477 8064095a 86152000 00000000
nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
kdcom!KdpComputeChecksum+12
f7988098 0fb631 movzx esi,byte ptr [ecx]

SYMBOL_STACK_INDEX: 4

SYMBOL_NAME: kdcom!KdpComputeChecksum+12

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: kdcom

IMAGE_NAME: kd1394.dll

DEBUG_FLR_IMAGE_TIMESTAMP: 41107b3a

FAILURE_BUCKET_ID: 0xD1_VRF_kdcom!KdpComputeChecksum+12

BUCKET_ID: 0xD1_VRF_kdcom!KdpComputeChecksum+12

Followup: MachineOwner
---------

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Michal_Vodicka-2 · February 6, 2007, 5:16pm

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of David Voeller[SMTP:xxxxx@hunter.com]
Reply To: Windows System Software Devs Interest List
Sent: Tuesday, February 06, 2007 5:42 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Tracing - WPP, ETW, TraceView, WinDbg

I have a KMDF USB driver that includes WPP tracing. The target box is XP
sp2. I have the driver code setup so that I can switch between WPP tracing
for driver release and Debug Tracing for development. I’ve been using Debug
Tracing for all of my diagnostics but I thought I would give WPP tracing a
try. I’m thinking that if I deploy a release version of the driver and
there is a problem, my first attempt at fixing the problem will be to enable
tracing at the customer’s site using a “ctl” file and then look at the
resulting “etl” output once the problem has been recorded. My second
attempt at fixing the problem will be to have the entire PC sent back in
which case I would like to connect to the box with firewire/WinDbg and view
the trace output.

I handle problems the same way but without WPP. When a problem occurs at customer’s site, we send them version with traces (which can be both debug and release) and desired trace settings are in the driver INF file. Customer installs the driver, reproduces the problem and sends us traces captured by DebugView. Works in the most cases. For the rest sometimes helps manually invoked crashdump and having the machine with problem is the next possibility.

WPP is a good idea but too complicated to use from one side and too limited from the second side. I examined it some time before and found no real advantage over the approach I use.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

Don_Burn_1 · February 6, 2007, 5:46pm

Must be nice to have cooperative end users. Between some medical products
(where replacing the driver is a liability issue) and customers who say no
way am I putting in a diagnostic driver, I have rarely had the pleasure of
being able to use a debug priut style of trace.

I have found WPP tracing to be solid, and pretty easy to use. I do use a
WPP_DEBUG macro to allow me to DbgPrint the trace messages, with something
like:

#define WPP_DEBUG(m) ((Globals.DebugFlags.Options.WppMessages !=0) ?
KdPrint(m) : 0)

I also love the fact that WPP tracing does not print the messages for my
customers, and just produces a binary file, that I can decode. This allows
me to not share with the customer those embarassing messages of the form
“This should never happen so for now …”

Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply

----- Original Message -----
From: “Michal Vodicka”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Tuesday, February 06, 2007 5:14 PM
Subject: RE: Tracing - WPP, ETW, TraceView, WinDbg

I handle problems the same way but without WPP. When a problem occurs at
customer’s site, we send them version with traces (which can be both debug
and release) and desired trace settings are in the driver INF file.
Customer installs the driver, reproduces the problem and sends us traces
captured by DebugView. Works in the most cases. For the rest sometimes
helps manually invoked crashdump and having the machine with problem is the
next possibility.

WPP is a good idea but too complicated to use from one side and too limited
from the second side. I examined it some time before and found no real
advantage over the approach I use.

OSR_Community_User · February 6, 2007, 5:54pm

I agree with Don. WPP seems like a better way to get information without
upsetting the customer. It is also more secure from our competitor.

-Dave

“Don Burn” wrote in message news:xxxxx@ntdev…
> Must be nice to have cooperative end users. Between some medical products
> (where replacing the driver is a liability issue) and customers who say no
> way am I putting in a diagnostic driver, I have rarely had the pleasure of
> being able to use a debug priut style of trace.
>
> I have found WPP tracing to be solid, and pretty easy to use. I do use a
> WPP_DEBUG macro to allow me to DbgPrint the trace messages, with something
> like:
>
> #define WPP_DEBUG(m) ((Globals.DebugFlags.Options.WppMessages !=0) ?
> KdPrint(m) : 0)
>
> I also love the fact that WPP tracing does not print the messages for my
> customers, and just produces a binary file, that I can decode. This
> allows
> me to not share with the customer those embarassing messages of the form
> “This should never happen so for now …”
>
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> http://www.windrvr.com
> Remove StopSpam from the email to reply
>
>
> ----- Original Message -----
> From: “Michal Vodicka”
> Newsgroups: ntdev
> To: “Windows System Software Devs Interest List”
> Sent: Tuesday, February 06, 2007 5:14 PM
> Subject: RE: Tracing - WPP, ETW, TraceView, WinDbg
>
>
> I handle problems the same way but without WPP. When a problem occurs at
> customer’s site, we send them version with traces (which can be both debug
> and release) and desired trace settings are in the driver INF file.
> Customer installs the driver, reproduces the problem and sends us traces
> captured by DebugView. Works in the most cases. For the rest sometimes
> helps manually invoked crashdump and having the machine with problem is
> the
> next possibility.
>
> WPP is a good idea but too complicated to use from one side and too
> limited
> from the second side. I examined it some time before and found no real
> advantage over the approach I use.
>
>
>
>
>
>

OSR_Community_User · February 6, 2007, 6:00pm

Does environment variable TRACE_FORMAT_SEARCH_PATH=c:\blah\blah\blah\ do
essentially the same thing as !wmitrace.serachpath? I’ve been automatically
stripping my tmf files from the pdb and putting them in the directory
pointed to by that environment variable.

I will change the Buffer Size in TraceView and see what happens.

-Dave

“Jose Sua” wrote in message
news:xxxxx@ntdev…
I was referring to dbghelp.dll now windbg.dll, sorry for the typo.

Your logger ID is:
Logger Id: 0x2

On the debugger box.

!wmitrace.help gives all the options.

!wmitrace.searchpath to set the path to the tmf files.

!wmitrace.logger 2 gives you info about your trace session

!wmitrace.strdump 2 gives info about the trace info strucs

So once you start tracing with tracelog, you don’t need to use traceview
at all.
Check info about WPP/ETW tracing on MSDN.

The crash with traceview could be that traceview is not using 3k buffers
when starting the session. In the output from tracelog below it should
work Buffer Size: 3 kb.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David Voeller
Sent: Tuesday, February 06, 2007 1:23 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Tracing - WPP, ETW, TraceView, WinDbg

I still have the crash in TraceView.

* I have WinDbg version 6.6.0007.5 on both my target and host PC.
* I am using TraceView.exe version 2.1.1 Copyright 2005 from WDK RTM
6000.
(Note that I had the same version on my target as my host but the file
size
was different so I made sure to copy everything from
C:\WINDDK\6000\tools\tracing\i386 to my target box).
* I could not find a “windbg.dll” file anywhere on both my target and
host
PC.

* I ran tracelog -start MySession -guid
#635CC065-EFCD-4593-84E6-BC1354963E8F -flags ff -level 5 -f MyLog.etl
-kd

This resulted in the command line output:
Logger Started…
Enablling trace to logger 2
Operation Status: 0L The operation completed successfully.
Logger Name: MySession
Logger Id: 0x2
Logger Thread Id: 00000F10
Guid:
635CC065-EFCD-4593-84E6-BC1354963E8F
Buffer Size: 3 kb
Maximum Buffers: 25
Minimum Buffers: 3
Number of Bufferes: 3
Free Buffers: 2
Buffers Written: 1
Events Lost: 0
Log Buffers Lost: 0
Real Time Buffers Lost: 0
AgeLimit: 15
ClockType: SystemTime
Log Mode: Sequential
Kd Filter mode enabled
Maximum File Size: not set
Buffer Flush Timer: not set
Enabled tracing: 0x00000001
Log Filename: blah blah MyLog.etl

I loaded the wmitrace “!load wmitrace.dll” but that was as far as I got
with
the command line option to send trace output to WinDbg.

* I enabled tracing using the latest version of TraceView and had a very

similar crash as the previous times.
kd> !analyze -v

Bugcheck Analysis

*
*

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address
at
an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: 8069e000, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: f7988098, address which referenced memory

Debugging Details:
------------------

READ_ADDRESS: 8069e000

CURRENT_IRQL: 2

FAULTING_IP:
kdcom!KdpComputeChecksum+12
f7988098 0fb631 movzx esi,byte ptr [ecx]

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xD1

PROCESS_NAME: System

TRAP_FRAME: b9ff7b90 – (.trap ffffffffb9ff7b90)
ErrCode = 00000003
eax=00000004 ebx=85a04bf8 ecx=00000001 edx=00000002 esi=b9ff7c3c
edi=8069b000
eip=8053af55 esp=b9ff7c04 ebp=b9ff7c60 iopl=0 nv up di pl nz na
po
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010002
nt!MmDbgCopyMemory+0x38a:
8053af55 f3a5 rep movs dword ptr es:[edi],dword ptr [esi]
es:0023:8069b000=50524920 ds:0023:b9ff7c3c=ffffffff
Resetting default scope

EXCEPTION_RECORD: b9ff761c – (.exr ffffffffb9ff761c)
ExceptionAddress: 804e3b25 (nt!RtlpBreakWithStatusInstruction)
ExceptionCode: 80000003 (Break instruction exception)
ExceptionFlags: 00000000
NumberParameters: 3
Parameter[0]: 00000000
Parameter[1]: 8050589d
Parameter[2]: 0000006a

LAST_CONTROL_TRANSFER: from 805328e7 to 804e3b25

STACK_TEXT:
b9ff6b58 805328e7 00000003 b9ff6eb4 00000000
nt!RtlpBreakWithStatusInstruction
b9ff6ba4 805333be 00000003 8069e000 f7988098
nt!KiBugCheckDebugBreak+0x19
b9ff6f84 804e2158 0000000a 8069e000 00000002 nt!KeBugCheck2+0x574
b9ff6f84 f7988098 0000000a 8069e000 00000002 nt!KiTrap0E+0x233
b9ff701c f7988262 80691918 0000fffc ffdff13c
kdcom!KdpComputeChecksum+0x12
b9ff704c 8067cf12 00000007 b9ff71e0 b9ff71d8 kdcom!KdSendPacket+0x24
b9ff70c8 8067d0bd 00000007 b9ff71e0 b9ff71d8
nt!KdpSendWaitContinue+0x2e0
b9ff71e8 805325a4 b9ff761c ffdff13c 00000000
nt!KdpReportExceptionStateChange+0x8a
b9ff7208 8067e137 b9ff7670 00000000 b9ff7600 nt!KdpReport+0x60
b9ff7234 804fa243 b9ff7670 00000000 b9ff761c nt!KdpTrap+0x108
b9ff7600 804dfada b9ff761c 00000000 b9ff7670
nt!KiDispatchException+0x129
b9ff7668 804e0208 b9ff772c 804e3b26 badb0d00
nt!CommonDispatchException+0x4d
b9ff7668 804e3b26 b9ff772c 804e3b26 badb0d00 nt!KiTrap03+0xad
b9ff76e0 805328e7 00000003 b9ff7a3c 00000000
nt!RtlpBreakWithStatusInstruction+0x1
b9ff772c 805333be 00000003 c0300804 81800000
nt!KiBugCheckDebugBreak+0x19
b9ff7b0c 805339ae 000000be 8069b000 0069b121 nt!KeBugCheck2+0x574
b9ff7b2c 805246fb 000000be 8069b000 0069b121 nt!KeBugCheckEx+0x1b
b9ff7b78 804e1ff1 00000001 8069b000 00000000 nt!MmAccessFault+0x6f5
b9ff7b78 8053af55 00000001 8069b000 00000000 nt!KiTrap0E+0xcc
b9ff7c60 8067d6bc 85a04bf8 00000000 8069b000 nt!MmDbgCopyMemory+0x38a
b9ff7c88 8067c504 85a04bf8 00000000 8069b000 nt!KdpCopyMemoryChunks+0x68
b9ff7d00 8067cc1c b9ff7d0c 0000ffff 859f9000 nt!KdpSendTraceData+0x28
b9ff7d14 8067a1fb 859f9001 00000000 85ac5010 nt!KdReportTraceData+0x41
b9ff7d58 806408a0 00000000 859f9000 00000000 nt!WmipFlushBuffer+0x336
b9ff7d80 80640ac9 85ac5054 00000001 00000000
nt!WmipFlushActiveBuffers+0x18d
b9ff7dac 8057dfed 00000001 00000000 00000000 nt!WmipLogger+0x16f
b9ff7ddc 804fa477 8064095a 85ac5000 00000000
nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
kdcom!KdpComputeChecksum+12
f7988098 0fb631 movzx esi,byte ptr [ecx]

SYMBOL_STACK_INDEX: 4

SYMBOL_NAME: kdcom!KdpComputeChecksum+12

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: kdcom

IMAGE_NAME: kd1394.dll

DEBUG_FLR_IMAGE_TIMESTAMP: 41107b3a

FAILURE_BUCKET_ID: 0xD1_VRF_kdcom!KdpComputeChecksum+12

BUCKET_ID: 0xD1_VRF_kdcom!KdpComputeChecksum+12

Followup: MachineOwner
---------

“Jose Sua” wrote in message
news:xxxxx@ntdev…
You can enable trace with the command line tools available in the
WDK/DDK:

I would recommend using the latest traceview part of the WDK and if that
fails let me know. You must also have the windbg.dll from the debugger
for traceview to work fine.

Tracelog (part of the WDK/DDK) take a look at the documentation on
MSDN. You can also use logman which is a tool part of the OS.

Fist case:
Start Tracing
Tracelog -start sessionname -guid #theProviderGuidInyourComponent -flags
yourflags -level levelIfUsed -f logfile.etl

Then run your scenario

Stop tracing.
tracelog -stop sessionname

You need the TMF files to view the events

Tracepdb -f yourdriver.pdb // this is a tool that extracts the tmf
files

tracefmt -display -p . logfile.etl // this tool will show you the
events and save them to a file.

The windbg scenario.

Enable tracing on your target machine using tracelog like above, but you
need to add the -kd obtion.

Then on your windbg kd machine, you need to use the wmitrace extension
which is part of the debugger to view the events.

!wmitrace.help to see the options.

But you must locate your trace session, which is provided when you ran
tracelog on the target machiene. Then you can see the trace buffers of
that session on the debugger.
In your debugger machine you need to have a copy of the tmf files
generated from tracepdb and your driver pdb file so that the extension
can decode the events.

!wmitrace extension should work on xp with the latest updates.

Thanks,
Jose Sua
Microsoft Corporation
This posting is provided “AS IS” with no warranties and confers no
rights.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David Voeller
Sent: Tuesday, February 06, 2007 8:42 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Tracing - WPP, ETW, TraceView, WinDbg

I have a KMDF USB driver that includes WPP tracing. The target box is
XP
sp2. I have the driver code setup so that I can switch between WPP
tracing
for driver release and Debug Tracing for development. I’ve been using
Debug
Tracing for all of my diagnostics but I thought I would give WPP tracing
a
try. I’m thinking that if I deploy a release version of the driver and
there is a problem, my first attempt at fixing the problem will be to
enable
tracing at the customer’s site using a “ctl” file and then look at the
resulting “etl” output once the problem has been recorded. My second
attempt at fixing the problem will be to have the entire PC sent back in

which case I would like to connect to the box with firewire/WinDbg and
view
the trace output.

I wanted to test these situations so I built the driver with WPP
enabled.
For the second case where I connect to the target with WinDbg, the only
way
I could find from the docs to get trace output to WinDbg is to use
TraceView
(or command line equivalent) to start a trace session and enable trace
output to WinDbg as well as TraceView. I’ve tried this 2 times and
always
get the crash shown below.

Question 1: Is there another way to enable trace output to WinDbg
besides
using TraceView?
Question 2: Is this crash a legitimate bug?

LAST_CONTROL_TRANSFER: from 805328e7 to 804e3b25

STACK_TEXT:
ba12eb58 805328e7 00000003 ba12eeb4 00000000
nt!RtlpBreakWithStatusInstruction
ba12eba4 805333be 00000003 8069e000 f7988098
nt!KiBugCheckDebugBreak+0x19
ba12ef84 804e2158 0000000a 8069e000 00000002 nt!KeBugCheck2+0x574
ba12ef84 f7988098 0000000a 8069e000 00000002 nt!KiTrap0E+0x233
ba12f01c f7988262 80691918 0000fffc ffdff13c
kdcom!KdpComputeChecksum+0x12
ba12f04c 8067cf12 00000007 ba12f1e0 ba12f1d8 kdcom!KdSendPacket+0x24
ba12f0c8 8067d0bd 00000007 ba12f1e0 ba12f1d8
nt!KdpSendWaitContinue+0x2e0
ba12f1e8 805325a4 ba12f61c ffdff13c 00000000
nt!KdpReportExceptionStateChange+0x8a
ba12f208 8067e137 ba12f670 00000000 ba12f600 nt!KdpReport+0x60
ba12f234 804fa243 ba12f670 00000000 ba12f61c nt!KdpTrap+0x108
ba12f600 804dfada ba12f61c 00000000 ba12f670
nt!KiDispatchException+0x129
ba12f668 804e0208 ba12f72c 804e3b26 badb0d00
nt!CommonDispatchException+0x4d
ba12f668 804e3b26 ba12f72c 804e3b26 badb0d00 nt!KiTrap03+0xad
ba12f6e0 805328e7 00000003 ba12fa3c 00000000
nt!RtlpBreakWithStatusInstruction+0x1
ba12f72c 805333be 00000003 c0300804 81800000
nt!KiBugCheckDebugBreak+0x19
ba12fb0c 805339ae 000000be 8069b000 0069b121 nt!KeBugCheck2+0x574
ba12fb2c 805246fb 000000be 8069b000 0069b121 nt!KeBugCheckEx+0x1b
ba12fb78 804e1ff1 00000001 8069b000 00000000 nt!MmAccessFault+0x6f5
ba12fb78 8053af55 00000001 8069b000 00000000 nt!KiTrap0E+0xcc
ba12fc60 8067d6bc 85fc1bf8 00000000 8069b000 nt!MmDbgCopyMemory+0x38a
ba12fc88 8067c504 85fc1bf8 00000000 8069b000 nt!KdpCopyMemoryChunks+0x68
ba12fd00 8067cc1c ba12fd0c 0000ffff 85fb6000 nt!KdpSendTraceData+0x28
ba12fd14 8067a1fb 85fb6001 00000000 86152010 nt!KdReportTraceData+0x41
ba12fd58 806408a0 00000000 85fb6000 00000000 nt!WmipFlushBuffer+0x336
ba12fd80 80640ac9 86152054 00000001 00000000
nt!WmipFlushActiveBuffers+0x18d
ba12fdac 8057dfed 00000001 00000000 00000000 nt!WmipLogger+0x16f
ba12fddc 804fa477 8064095a 86152000 00000000
nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
kdcom!KdpComputeChecksum+12
f7988098 0fb631 movzx esi,byte ptr [ecx]

SYMBOL_STACK_INDEX: 4

SYMBOL_NAME: kdcom!KdpComputeChecksum+12

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: kdcom

IMAGE_NAME: kd1394.dll

DEBUG_FLR_IMAGE_TIMESTAMP: 41107b3a

FAILURE_BUCKET_ID: 0xD1_VRF_kdcom!KdpComputeChecksum+12

BUCKET_ID: 0xD1_VRF_kdcom!KdpComputeChecksum+12

Followup: MachineOwner
---------

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Michal_Vodicka-2 · February 6, 2007, 6:56pm

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Don Burn[SMTP:xxxxx@acm.org]
Reply To: Windows System Software Devs Interest List
Sent: Tuesday, February 06, 2007 11:46 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Tracing - WPP, ETW, TraceView, WinDbg

Must be nice to have cooperative end users.

Our users are computer (mainly notebook) manufacturers who have real interest everything works correctly before going to factory. I seldom see a report from an end user but in such cases they’re surprisingly cooperative.

Between some medical products
(where replacing the driver is a liability issue) and customers who say no
way am I putting in a diagnostic driver, I have rarely had the pleasure of
being able to use a debug priut style of trace.

Don’t they have a problem running custom tool to enable and capture your traces? Enabling them is equivallent with installing driver from the same build with traces (as we do). But maybe they don’t see such technical details.

I have found WPP tracing to be solid, and pretty easy to use.

Didn’t this thread start with BSOD caused by WPP?

I do use a
WPP_DEBUG macro to allow me to DbgPrint the trace messages, with something
like:

#define WPP_DEBUG(m) ((Globals.DebugFlags.Options.WppMessages !=0) ?
KdPrint(m) : 0)

Why not. I have a lot of code which contains traces developed before WPP. We use more granular way how to control traces (several trace areas per binary and 5 levels per area) and I haven’t found am easy way how to map our traces to WPP (discussed here few years before).

I also love the fact that WPP tracing does not print the messages for my
customers, and just produces a binary file, that I can decode. This allows
me to not share with the customer those embarassing messages of the form
“This should never happen so for now …”

I learnt to not write such messages Instead, I use ASSERT(FALSE) which causes BSOD or nicely formated and easy to find traces. More specifically, I write code following way:

if (TVERIFY(ExpectedCondition)) {
// handle normal case
}
else {
// handle unexpected case graciously
}

TVERIFY expands to assert in the build with traces and/or asserts enabled.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

OSR_Community_User · February 6, 2007, 7:05pm

Yes TRACE_FORMAT_SEARCH_PATH if you define that wmitrace extension will
pick it up automatically.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David Voeller
Sent: Tuesday, February 06, 2007 3:00 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Tracing - WPP, ETW, TraceView, WinDbg

Does environment variable TRACE_FORMAT_SEARCH_PATH=c:\blah\blah\blah\ do

essentially the same thing as !wmitrace.serachpath? I’ve been
automatically
stripping my tmf files from the pdb and putting them in the directory
pointed to by that environment variable.

I will change the Buffer Size in TraceView and see what happens.

-Dave

“Jose Sua” wrote in message
news:xxxxx@ntdev…
I was referring to dbghelp.dll now windbg.dll, sorry for the typo.

Your logger ID is:
Logger Id: 0x2

On the debugger box.

!wmitrace.help gives all the options.

!wmitrace.searchpath to set the path to the tmf files.

!wmitrace.logger 2 gives you info about your trace session

!wmitrace.strdump 2 gives info about the trace info strucs

So once you start tracing with tracelog, you don’t need to use traceview
at all.
Check info about WPP/ETW tracing on MSDN.

The crash with traceview could be that traceview is not using 3k buffers
when starting the session. In the output from tracelog below it should
work Buffer Size: 3 kb.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David Voeller
Sent: Tuesday, February 06, 2007 1:23 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Tracing - WPP, ETW, TraceView, WinDbg

I still have the crash in TraceView.

* I have WinDbg version 6.6.0007.5 on both my target and host PC.
* I am using TraceView.exe version 2.1.1 Copyright 2005 from WDK RTM
6000.
(Note that I had the same version on my target as my host but the file
size
was different so I made sure to copy everything from
C:\WINDDK\6000\tools\tracing\i386 to my target box).
* I could not find a “windbg.dll” file anywhere on both my target and
host
PC.

* I ran tracelog -start MySession -guid
#635CC065-EFCD-4593-84E6-BC1354963E8F -flags ff -level 5 -f MyLog.etl
-kd

This resulted in the command line output:
Logger Started…
Enablling trace to logger 2
Operation Status: 0L The operation completed successfully.
Logger Name: MySession
Logger Id: 0x2
Logger Thread Id: 00000F10
Guid:
635CC065-EFCD-4593-84E6-BC1354963E8F
Buffer Size: 3 kb
Maximum Buffers: 25
Minimum Buffers: 3
Number of Bufferes: 3
Free Buffers: 2
Buffers Written: 1
Events Lost: 0
Log Buffers Lost: 0
Real Time Buffers Lost: 0
AgeLimit: 15
ClockType: SystemTime
Log Mode: Sequential
Kd Filter mode enabled
Maximum File Size: not set
Buffer Flush Timer: not set
Enabled tracing: 0x00000001
Log Filename: blah blah MyLog.etl

I loaded the wmitrace “!load wmitrace.dll” but that was as far as I got
with
the command line option to send trace output to WinDbg.

* I enabled tracing using the latest version of TraceView and had a very

similar crash as the previous times.
kd> !analyze -v

Bugcheck Analysis

*
*

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address
at
an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: 8069e000, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: f7988098, address which referenced memory

Debugging Details:
------------------

READ_ADDRESS: 8069e000

CURRENT_IRQL: 2

FAULTING_IP:
kdcom!KdpComputeChecksum+12
f7988098 0fb631 movzx esi,byte ptr [ecx]

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xD1

PROCESS_NAME: System

TRAP_FRAME: b9ff7b90 – (.trap ffffffffb9ff7b90)
ErrCode = 00000003
eax=00000004 ebx=85a04bf8 ecx=00000001 edx=00000002 esi=b9ff7c3c
edi=8069b000
eip=8053af55 esp=b9ff7c04 ebp=b9ff7c60 iopl=0 nv up di pl nz na
po
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010002
nt!MmDbgCopyMemory+0x38a:
8053af55 f3a5 rep movs dword ptr es:[edi],dword ptr [esi]
es:0023:8069b000=50524920 ds:0023:b9ff7c3c=ffffffff
Resetting default scope

EXCEPTION_RECORD: b9ff761c – (.exr ffffffffb9ff761c)
ExceptionAddress: 804e3b25 (nt!RtlpBreakWithStatusInstruction)
ExceptionCode: 80000003 (Break instruction exception)
ExceptionFlags: 00000000
NumberParameters: 3
Parameter[0]: 00000000
Parameter[1]: 8050589d
Parameter[2]: 0000006a

LAST_CONTROL_TRANSFER: from 805328e7 to 804e3b25

STACK_TEXT:
b9ff6b58 805328e7 00000003 b9ff6eb4 00000000
nt!RtlpBreakWithStatusInstruction
b9ff6ba4 805333be 00000003 8069e000 f7988098
nt!KiBugCheckDebugBreak+0x19
b9ff6f84 804e2158 0000000a 8069e000 00000002 nt!KeBugCheck2+0x574
b9ff6f84 f7988098 0000000a 8069e000 00000002 nt!KiTrap0E+0x233
b9ff701c f7988262 80691918 0000fffc ffdff13c
kdcom!KdpComputeChecksum+0x12
b9ff704c 8067cf12 00000007 b9ff71e0 b9ff71d8 kdcom!KdSendPacket+0x24
b9ff70c8 8067d0bd 00000007 b9ff71e0 b9ff71d8
nt!KdpSendWaitContinue+0x2e0
b9ff71e8 805325a4 b9ff761c ffdff13c 00000000
nt!KdpReportExceptionStateChange+0x8a
b9ff7208 8067e137 b9ff7670 00000000 b9ff7600 nt!KdpReport+0x60
b9ff7234 804fa243 b9ff7670 00000000 b9ff761c nt!KdpTrap+0x108
b9ff7600 804dfada b9ff761c 00000000 b9ff7670
nt!KiDispatchException+0x129
b9ff7668 804e0208 b9ff772c 804e3b26 badb0d00
nt!CommonDispatchException+0x4d
b9ff7668 804e3b26 b9ff772c 804e3b26 badb0d00 nt!KiTrap03+0xad
b9ff76e0 805328e7 00000003 b9ff7a3c 00000000
nt!RtlpBreakWithStatusInstruction+0x1
b9ff772c 805333be 00000003 c0300804 81800000
nt!KiBugCheckDebugBreak+0x19
b9ff7b0c 805339ae 000000be 8069b000 0069b121 nt!KeBugCheck2+0x574
b9ff7b2c 805246fb 000000be 8069b000 0069b121 nt!KeBugCheckEx+0x1b
b9ff7b78 804e1ff1 00000001 8069b000 00000000 nt!MmAccessFault+0x6f5
b9ff7b78 8053af55 00000001 8069b000 00000000 nt!KiTrap0E+0xcc
b9ff7c60 8067d6bc 85a04bf8 00000000 8069b000 nt!MmDbgCopyMemory+0x38a
b9ff7c88 8067c504 85a04bf8 00000000 8069b000 nt!KdpCopyMemoryChunks+0x68
b9ff7d00 8067cc1c b9ff7d0c 0000ffff 859f9000 nt!KdpSendTraceData+0x28
b9ff7d14 8067a1fb 859f9001 00000000 85ac5010 nt!KdReportTraceData+0x41
b9ff7d58 806408a0 00000000 859f9000 00000000 nt!WmipFlushBuffer+0x336
b9ff7d80 80640ac9 85ac5054 00000001 00000000
nt!WmipFlushActiveBuffers+0x18d
b9ff7dac 8057dfed 00000001 00000000 00000000 nt!WmipLogger+0x16f
b9ff7ddc 804fa477 8064095a 85ac5000 00000000
nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
kdcom!KdpComputeChecksum+12
f7988098 0fb631 movzx esi,byte ptr [ecx]

SYMBOL_STACK_INDEX: 4

SYMBOL_NAME: kdcom!KdpComputeChecksum+12

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: kdcom

IMAGE_NAME: kd1394.dll

DEBUG_FLR_IMAGE_TIMESTAMP: 41107b3a

FAILURE_BUCKET_ID: 0xD1_VRF_kdcom!KdpComputeChecksum+12

BUCKET_ID: 0xD1_VRF_kdcom!KdpComputeChecksum+12

Followup: MachineOwner
---------

“Jose Sua” wrote in message
news:xxxxx@ntdev…
You can enable trace with the command line tools available in the
WDK/DDK:

I would recommend using the latest traceview part of the WDK and if that
fails let me know. You must also have the windbg.dll from the debugger
for traceview to work fine.

Tracelog (part of the WDK/DDK) take a look at the documentation on
MSDN. You can also use logman which is a tool part of the OS.

Fist case:
Start Tracing
Tracelog -start sessionname -guid #theProviderGuidInyourComponent -flags
yourflags -level levelIfUsed -f logfile.etl

Then run your scenario

Stop tracing.
tracelog -stop sessionname

You need the TMF files to view the events

Tracepdb -f yourdriver.pdb // this is a tool that extracts the tmf
files

tracefmt -display -p . logfile.etl // this tool will show you the
events and save them to a file.

The windbg scenario.

Enable tracing on your target machine using tracelog like above, but you
need to add the -kd obtion.

Then on your windbg kd machine, you need to use the wmitrace extension
which is part of the debugger to view the events.

!wmitrace.help to see the options.

But you must locate your trace session, which is provided when you ran
tracelog on the target machiene. Then you can see the trace buffers of
that session on the debugger.
In your debugger machine you need to have a copy of the tmf files
generated from tracepdb and your driver pdb file so that the extension
can decode the events.

!wmitrace extension should work on xp with the latest updates.

Thanks,
Jose Sua
Microsoft Corporation
This posting is provided “AS IS” with no warranties and confers no
rights.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David Voeller
Sent: Tuesday, February 06, 2007 8:42 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Tracing - WPP, ETW, TraceView, WinDbg

I have a KMDF USB driver that includes WPP tracing. The target box is
XP
sp2. I have the driver code setup so that I can switch between WPP
tracing
for driver release and Debug Tracing for development. I’ve been using
Debug
Tracing for all of my diagnostics but I thought I would give WPP tracing
a
try. I’m thinking that if I deploy a release version of the driver and
there is a problem, my first attempt at fixing the problem will be to
enable
tracing at the customer’s site using a “ctl” file and then look at the
resulting “etl” output once the problem has been recorded. My second
attempt at fixing the problem will be to have the entire PC sent back in

which case I would like to connect to the box with firewire/WinDbg and
view
the trace output.

I wanted to test these situations so I built the driver with WPP
enabled.
For the second case where I connect to the target with WinDbg, the only
way
I could find from the docs to get trace output to WinDbg is to use
TraceView
(or command line equivalent) to start a trace session and enable trace
output to WinDbg as well as TraceView. I’ve tried this 2 times and
always
get the crash shown below.

Question 1: Is there another way to enable trace output to WinDbg
besides
using TraceView?
Question 2: Is this crash a legitimate bug?

LAST_CONTROL_TRANSFER: from 805328e7 to 804e3b25

STACK_TEXT:
ba12eb58 805328e7 00000003 ba12eeb4 00000000
nt!RtlpBreakWithStatusInstruction
ba12eba4 805333be 00000003 8069e000 f7988098
nt!KiBugCheckDebugBreak+0x19
ba12ef84 804e2158 0000000a 8069e000 00000002 nt!KeBugCheck2+0x574
ba12ef84 f7988098 0000000a 8069e000 00000002 nt!KiTrap0E+0x233
ba12f01c f7988262 80691918 0000fffc ffdff13c
kdcom!KdpComputeChecksum+0x12
ba12f04c 8067cf12 00000007 ba12f1e0 ba12f1d8 kdcom!KdSendPacket+0x24
ba12f0c8 8067d0bd 00000007 ba12f1e0 ba12f1d8
nt!KdpSendWaitContinue+0x2e0
ba12f1e8 805325a4 ba12f61c ffdff13c 00000000
nt!KdpReportExceptionStateChange+0x8a
ba12f208 8067e137 ba12f670 00000000 ba12f600 nt!KdpReport+0x60
ba12f234 804fa243 ba12f670 00000000 ba12f61c nt!KdpTrap+0x108
ba12f600 804dfada ba12f61c 00000000 ba12f670
nt!KiDispatchException+0x129
ba12f668 804e0208 ba12f72c 804e3b26 badb0d00
nt!CommonDispatchException+0x4d
ba12f668 804e3b26 ba12f72c 804e3b26 badb0d00 nt!KiTrap03+0xad
ba12f6e0 805328e7 00000003 ba12fa3c 00000000
nt!RtlpBreakWithStatusInstruction+0x1
ba12f72c 805333be 00000003 c0300804 81800000
nt!KiBugCheckDebugBreak+0x19
ba12fb0c 805339ae 000000be 8069b000 0069b121 nt!KeBugCheck2+0x574
ba12fb2c 805246fb 000000be 8069b000 0069b121 nt!KeBugCheckEx+0x1b
ba12fb78 804e1ff1 00000001 8069b000 00000000 nt!MmAccessFault+0x6f5
ba12fb78 8053af55 00000001 8069b000 00000000 nt!KiTrap0E+0xcc
ba12fc60 8067d6bc 85fc1bf8 00000000 8069b000 nt!MmDbgCopyMemory+0x38a
ba12fc88 8067c504 85fc1bf8 00000000 8069b000 nt!KdpCopyMemoryChunks+0x68
ba12fd00 8067cc1c ba12fd0c 0000ffff 85fb6000 nt!KdpSendTraceData+0x28
ba12fd14 8067a1fb 85fb6001 00000000 86152010 nt!KdReportTraceData+0x41
ba12fd58 806408a0 00000000 85fb6000 00000000 nt!WmipFlushBuffer+0x336
ba12fd80 80640ac9 86152054 00000001 00000000
nt!WmipFlushActiveBuffers+0x18d
ba12fdac 8057dfed 00000001 00000000 00000000 nt!WmipLogger+0x16f
ba12fddc 804fa477 8064095a 86152000 00000000
nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
kdcom!KdpComputeChecksum+12
f7988098 0fb631 movzx esi,byte ptr [ecx]

SYMBOL_STACK_INDEX: 4

SYMBOL_NAME: kdcom!KdpComputeChecksum+12

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: kdcom

IMAGE_NAME: kd1394.dll

DEBUG_FLR_IMAGE_TIMESTAMP: 41107b3a

FAILURE_BUCKET_ID: 0xD1_VRF_kdcom!KdpComputeChecksum+12

BUCKET_ID: 0xD1_VRF_kdcom!KdpComputeChecksum+12

Followup: MachineOwner
---------

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Alex_Bendetov · February 7, 2007, 2:19am

“* I enabled tracing using the latest version of TraceView and had a very similar crash as the previous times.”

David, I think the problem is that TraceView defaults to buffer size > 3K.

When you configure trace session in TraceView make sure to select buffer size = 3K and it shoudln’t crash. On Vista appropriate checks were added, and system no-longer crashes.

Alex

From: xxxxx@hunter.com> Subject: Re:[ntdev] Tracing - WPP, ETW, TraceView, WinDbg> Date: Tue, 6 Feb 2007 15:23:27 -0600> To: xxxxx@lists.osr.com> > I still have the crash in TraceView.> > > * I have WinDbg version 6.6.0007.5 on both my target and host PC.> * I am using TraceView.exe version 2.1.1 Copyright 2005 from WDK RTM 6000. > (Note that I had the same version on my target as my host but the file size > was different so I made sure to copy everything from > C:\WINDDK\6000\tools\tracing\i386 to my target box).> * I could not find a “windbg.dll” file anywhere on both my target and host > PC.> > * I ran tracelog -start MySession -guid > #635CC065-EFCD-4593-84E6-BC1354963E8F -flags ff -level 5 -f MyLog.etl -kd> > This resulted in the command line output:> Logger Started…> Enablling trace to logger 2> Operation Status: 0L The operation completed successfully.> Logger Name: MySession> Logger Id: 0x2> Logger Thread Id: 00000F10> Guid: 635CC065-EFCD-4593-84E6-BC1354963E8F> Buffer Size: 3 kb> Maximum Buffers: 25> Minimum Buffers: 3> Number of Bufferes: 3> Free Buffers: 2> Buffers Written: 1> Events Lost: 0> Log Buffers Lost: 0> Real Time Buffers Lost: 0> AgeLimit: 15> ClockType: SystemTime> Log Mode: Sequential> Kd Filter mode enabled> Maximum File Size: not set> Buffer Flush Timer: not set> Enabled tracing: 0x00000001> Log Filename: blah blah MyLog.etl> > I loaded the wmitrace “!load wmitrace.dll” but that was as far as I got with > the command line option to send trace output to WinDbg.> > * I enabled tracing using the latest version of TraceView and had a very > similar crash as the previous times.> kd> !analyze -v> ********************************************> * > *> * Bugcheck Analysis *> * > *> ********************************************> > DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)> An attempt was made to access a pageable (or completely invalid) address at > an> interrupt request level (IRQL) that is too high. This is usually> caused by drivers using improper addresses.> If kernel debugger is available get stack backtrace.> Arguments:> Arg1: 8069e000, memory referenced> Arg2: 00000002, IRQL> Arg3: 00000000, value 0 = read operation, 1 = write operation> Arg4: f7988098, address which referenced memory> > Debugging Details:> ------------------> > > READ_ADDRESS: 8069e000> > CURRENT_IRQL: 2> > FAULTING_IP:> kdcom!KdpComputeChecksum+12> f7988098 0fb631 movzx esi,byte ptr [ecx]> > DEFAULT_BUCKET_ID: DRIVER_FAULT> > BUGCHECK_STR: 0xD1> > PROCESS_NAME: System> > TRAP_FRAME: b9ff7b90 – (.trap ffffffffb9ff7b90)> ErrCode = 00000003> eax=00000004 ebx=85a04bf8 ecx=00000001 edx=00000002 esi=b9ff7c3c > edi=8069b000> eip=8053af55 esp=b9ff7c04 ebp=b9ff7c60 iopl=0 nv up di pl nz na po > nc> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 > efl=00010002> nt!MmDbgCopyMemory+0x38a:> 8053af55 f3a5 rep movs dword ptr es:[edi],dword ptr [esi] > es:0023:8069b000=50524920 ds:0023:b9ff7c3c=ffffffff> Resetting default scope> > EXCEPTION_RECORD: b9ff761c – (.exr ffffffffb9ff761c)> ExceptionAddress: 804e3b25 (nt!RtlpBreakWithStatusInstruction)> ExceptionCode: 80000003 (Break instruction exception)> ExceptionFlags: 00000000> NumberParameters: 3> Parameter[0]: 00000000> Parameter[1]: 8050589d> Parameter[2]: 0000006a> > LAST_CONTROL_TRANSFER: from 805328e7 to 804e3b25> > STACK_TEXT:> b9ff6b58 805328e7 00000003 b9ff6eb4 00000000 > nt!RtlpBreakWithStatusInstruction> b9ff6ba4 805333be 00000003 8069e000 f7988098 nt!KiBugCheckDebugBreak+0x19> b9ff6f84 804e2158 0000000a 8069e000 00000002 nt!KeBugCheck2+0x574> b9ff6f84 f7988098 0000000a 8069e000 00000002 nt!KiTrap0E+0x233> b9ff701c f7988262 80691918 0000fffc ffdff13c kdcom!KdpComputeChecksum+0x12> b9ff704c 8067cf12 00000007 b9ff71e0 b9ff71d8 kdcom!KdSendPacket+0x24> b9ff70c8 8067d0bd 00000007 b9ff71e0 b9ff71d8 nt!KdpSendWaitContinue+0x2e0> b9ff71e8 805325a4 b9ff761c ffdff13c 00000000 > nt!KdpReportExceptionStateChange+0x8a> b9ff7208 8067e137 b9ff7670 00000000 b9ff7600 nt!KdpReport+0x60> b9ff7234 804fa243 b9ff7670 00000000 b9ff761c nt!KdpTrap+0x108> b9ff7600 804dfada b9ff761c 00000000 b9ff7670 nt!KiDispatchException+0x129> b9ff7668 804e0208 b9ff772c 804e3b26 badb0d00 nt!CommonDispatchException+0x4d> b9ff7668 804e3b26 b9ff772c 804e3b26 badb0d00 nt!KiTrap03+0xad> b9ff76e0 805328e7 00000003 b9ff7a3c 00000000 > nt!RtlpBreakWithStatusInstruction+0x1> b9ff772c 805333be 00000003 c0300804 81800000 nt!KiBugCheckDebugBreak+0x19> b9ff7b0c 805339ae 000000be 8069b000 0069b121 nt!KeBugCheck2+0x574> b9ff7b2c 805246fb 000000be 8069b000 0069b121 nt!KeBugCheckEx+0x1b> b9ff7b78 804e1ff1 00000001 8069b000 00000000 nt!MmAccessFault+0x6f5> b9ff7b78 8053af55 00000001 8069b000 00000000 nt!KiTrap0E+0xcc> b9ff7c60 8067d6bc 85a04bf8 00000000 8069b000 nt!MmDbgCopyMemory+0x38a> b9ff7c88 8067c504 85a04bf8 00000000 8069b000 nt!KdpCopyMemoryChunks+0x68> b9ff7d00 8067cc1c b9ff7d0c 0000ffff 859f9000 nt!KdpSendTraceData+0x28> b9ff7d14 8067a1fb 859f9001 00000000 85ac5010 nt!KdReportTraceData+0x41> b9ff7d58 806408a0 00000000 859f9000 00000000 nt!WmipFlushBuffer+0x336> b9ff7d80 80640ac9 85ac5054 00000001 00000000 nt!WmipFlushActiveBuffers+0x18d> b9ff7dac 8057dfed 00000001 00000000 00000000 nt!WmipLogger+0x16f> b9ff7ddc 804fa477 8064095a 85ac5000 00000000 nt!PspSystemThreadStartup+0x34> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16> > > STACK_COMMAND: kb> > FOLLOWUP_IP:> kdcom!KdpComputeChecksum+12> f7988098 0fb631 movzx esi,byte ptr [ecx]> > SYMBOL_STACK_INDEX: 4> > SYMBOL_NAME: kdcom!KdpComputeChecksum+12> > FOLLOWUP_NAME: MachineOwner> > MODULE_NAME: kdcom> > IMAGE_NAME: kd1394.dll> > DEBUG_FLR_IMAGE_TIMESTAMP: 41107b3a> > FAILURE_BUCKET_ID: 0xD1_VRF_kdcom!KdpComputeChecksum+12> > BUCKET_ID: 0xD1_VRF_kdcom!KdpComputeChecksum+12> > Followup: MachineOwner> ---------> > > “Jose Sua” wrote in message > news:xxxxx@ntdev…> You can enable trace with the command line tools available in the> WDK/DDK:> > I would recommend using the latest traceview part of the WDK and if that> fails let me know. You must also have the windbg.dll from the debugger> for traceview to work fine.> > Tracelog (part of the WDK/DDK) take a look at the documentation on> MSDN. You can also use logman which is a tool part of the OS.> > Fist case:> Start Tracing> Tracelog -start sessionname -guid #theProviderGuidInyourComponent -flags> yourflags -level levelIfUsed -f logfile.etl> > Then run your scenario> > Stop tracing.> tracelog -stop sessionname> > > You need the TMF files to view the events> > Tracepdb -f yourdriver.pdb // this is a tool that extracts the tmf> files> > > tracefmt -display -p . logfile.etl // this tool will show you the> events and save them to a file.> > > The windbg scenario.> > Enable tracing on your target machine using tracelog like above, but you> need to add the -kd obtion.> > Then on your windbg kd machine, you need to use the wmitrace extension> which is part of the debugger to view the events.> > !wmitrace.help to see the options.> > But you must locate your trace session, which is provided when you ran> tracelog on the target machiene. Then you can see the trace buffers of> that session on the debugger.> In your debugger machine you need to have a copy of the tmf files> generated from tracepdb and your driver pdb file so that the extension> can decode the events.> > !wmitrace extension should work on xp with the latest updates.> > > > Thanks,> Jose Sua> Microsoft Corporation> This posting is provided “AS IS” with no warranties and confers no> rights.> > -----Original Message-----> From: xxxxx@lists.osr.com> [mailto:xxxxx@lists.osr.com] On Behalf Of David Voeller> Sent: Tuesday, February 06, 2007 8:42 AM> To: Windows System Software Devs Interest List> Subject: [ntdev] Tracing - WPP, ETW, TraceView, WinDbg> > I have a KMDF USB driver that includes WPP tracing. The target box is> XP> sp2. I have the driver code setup so that I can switch between WPP> tracing> for driver release and Debug Tracing for development. I’ve been using> Debug> Tracing for all of my diagnostics but I thought I would give WPP tracing> a> try. I’m thinking that if I deploy a release version of the driver and> there is a problem, my first attempt at fixing the problem will be to> enable> tracing at the customer’s site using a “ctl” file and then look at the> resulting “etl” output once the problem has been recorded. My second> attempt at fixing the problem will be to have the entire PC sent back in> > which case I would like to connect to the box with firewire/WinDbg and> view> the trace output.> > I wanted to test these situations so I built the driver with WPP> enabled.> For the second case where I connect to the target with WinDbg, the only> way> I could find from the docs to get trace output to WinDbg is to use> TraceView> (or command line equivalent) to start a trace session and enable trace> output to WinDbg as well as TraceView. I’ve tried this 2 times and> always> get the crash shown below.> > Question 1: Is there another way to enable trace output to WinDbg> besides> using TraceView?> Question 2: Is this crash a legitimate bug?> > > LAST_CONTROL_TRANSFER: from 805328e7 to 804e3b25> > STACK_TEXT:> ba12eb58 805328e7 00000003 ba12eeb4 00000000> nt!RtlpBreakWithStatusInstruction> ba12eba4 805333be 00000003 8069e000 f7988098> nt!KiBugCheckDebugBreak+0x19> ba12ef84 804e2158 0000000a 8069e000 00000002 nt!KeBugCheck2+0x574> ba12ef84 f7988098 0000000a 8069e000 00000002 nt!KiTrap0E+0x233> ba12f01c f7988262 80691918 0000fffc ffdff13c> kdcom!KdpComputeChecksum+0x12> ba12f04c 8067cf12 00000007 ba12f1e0 ba12f1d8 kdcom!KdSendPacket+0x24> ba12f0c8 8067d0bd 00000007 ba12f1e0 ba12f1d8> nt!KdpSendWaitContinue+0x2e0> ba12f1e8 805325a4 ba12f61c ffdff13c 00000000> nt!KdpReportExceptionStateChange+0x8a> ba12f208 8067e137 ba12f670 00000000 ba12f600 nt!KdpReport+0x60> ba12f234 804fa243 ba12f670 00000000 ba12f61c nt!KdpTrap+0x108> ba12f600 804dfada ba12f61c 00000000 ba12f670> nt!KiDispatchException+0x129> ba12f668 804e0208 ba12f72c 804e3b26 badb0d00> nt!CommonDispatchException+0x4d> ba12f668 804e3b26 ba12f72c 804e3b26 badb0d00 nt!KiTrap03+0xad> ba12f6e0 805328e7 00000003 ba12fa3c 00000000> nt!RtlpBreakWithStatusInstruction+0x1> ba12f72c 805333be 00000003 c0300804 81800000> nt!KiBugCheckDebugBreak+0x19> ba12fb0c 805339ae 000000be 8069b000 0069b121 nt!KeBugCheck2+0x574> ba12fb2c 805246fb 000000be 8069b000 0069b121 nt!KeBugCheckEx+0x1b> ba12fb78 804e1ff1 00000001 8069b000 00000000 nt!MmAccessFault+0x6f5> ba12fb78 8053af55 00000001 8069b000 00000000 nt!KiTrap0E+0xcc> ba12fc60 8067d6bc 85fc1bf8 00000000 8069b000 nt!MmDbgCopyMemory+0x38a> ba12fc88 8067c504 85fc1bf8 00000000 8069b000 nt!KdpCopyMemoryChunks+0x68> ba12fd00 8067cc1c ba12fd0c 0000ffff 85fb6000 nt!KdpSendTraceData+0x28> ba12fd14 8067a1fb 85fb6001 00000000 86152010 nt!KdReportTraceData+0x41> ba12fd58 806408a0 00000000 85fb6000 00000000 nt!WmipFlushBuffer+0x336> ba12fd80 80640ac9 86152054 00000001 00000000> nt!WmipFlushActiveBuffers+0x18d> ba12fdac 8057dfed 00000001 00000000 00000000 nt!WmipLogger+0x16f> ba12fddc 804fa477 8064095a 86152000 00000000> nt!PspSystemThreadStartup+0x34> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16> > > STACK_COMMAND: kb> > FOLLOWUP_IP:> kdcom!KdpComputeChecksum+12> f7988098 0fb631 movzx esi,byte ptr [ecx]> > SYMBOL_STACK_INDEX: 4> > SYMBOL_NAME: kdcom!KdpComputeChecksum+12> > FOLLOWUP_NAME: MachineOwner> > MODULE_NAME: kdcom> > IMAGE_NAME: kd1394.dll> > DEBUG_FLR_IMAGE_TIMESTAMP: 41107b3a> > FAILURE_BUCKET_ID: 0xD1_VRF_kdcom!KdpComputeChecksum+12> > BUCKET_ID: 0xD1_VRF_kdcom!KdpComputeChecksum+12> > Followup: MachineOwner> ---------> > > > —> Questions? First check the Kernel Driver FAQ at> http://www.osronline.com/article.cfm?id=256> > To unsubscribe, visit the List Server section of OSR Online at> http://www.osronline.com/page.cfm?name=ListServer> > > > > —> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256> > To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
_________________________________________________________________
Live Search: Better results, fast
http://get.live.com/search/overview

OSR_Community_User · February 7, 2007, 12:01pm

The tool for enabling tracing (LOGMAN) is part of the OS. In this forum
customers use Traceview because it can enable the provider and view the
messages. But the command line tools are available for enabling tracing
and getting the trace file to be viewed by developers.

To enable tracing on a machine just do:

logman start providername -pf providerinfo.txt -o logfile.log -ets

providerinfo.txt has
{PROVIDER_GUID} flag level //sample
{d58c126f-b309-11d1-969e-0000f875a5bc} 15 5

Enabling tracing is not at all like installing a driver, the WPP tracing
code is part of the driver and just gets enabled, the events are send to
a log session. One can enable and disable tracing without the need to
reboot the machine or installing a new driver.
There is further documentation on WPP/ETW on MSDN, to clear this issue.

WPP is a layer on top of ETW, which has been further improved in Vista.

WPP is very flexible it allows fine control granularity with 32bit flags
and 256 levels for each flag for each provider GUID. If a single
provider GUID is not enough you can use several provider GUIDs to fit
your needs.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Tuesday, February 06, 2007 3:56 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Tracing - WPP, ETW, TraceView, WinDbg

From:
xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
] on behalf of Don Burn[SMTP:xxxxx@acm.org]
Reply To: Windows System Software Devs Interest List
Sent: Tuesday, February 06, 2007 11:46 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Tracing - WPP, ETW, TraceView, WinDbg

Must be nice to have cooperative end users.

Our users are computer (mainly notebook) manufacturers who have real
interest everything works correctly before going to factory. I seldom
see a report from an end user but in such cases they’re surprisingly
cooperative.

Between some medical products
(where replacing the driver is a liability issue) and customers who
say no
way am I putting in a diagnostic driver, I have rarely had the
pleasure of
being able to use a debug priut style of trace.

Don’t they have a problem running custom tool to enable and capture your
traces? Enabling them is equivallent with installing driver from the
same build with traces (as we do). But maybe they don’t see such
technical details.

I have found WPP tracing to be solid, and pretty easy to use.

Didn’t this thread start with BSOD caused by WPP?

I do use a
WPP_DEBUG macro to allow me to DbgPrint the trace messages, with
something
like:

#define WPP_DEBUG(m) ((Globals.DebugFlags.Options.WppMessages !=0) ?
KdPrint(m) : 0)

Why not. I have a lot of code which contains traces developed before
WPP. We use more granular way how to control traces (several trace areas
per binary and 5 levels per area) and I haven’t found am easy way how to
map our traces to WPP (discussed here few years before).

I also love the fact that WPP tracing does not print the messages for
my
customers, and just produces a binary file, that I can decode. This
allows
me to not share with the customer those embarassing messages of the
form
“This should never happen so for now …”

I learnt to not write such messages Instead, I use ASSERT(FALSE)
which causes BSOD or nicely formated and easy to find traces. More
specifically, I write code following way:

if (TVERIFY(ExpectedCondition)) {
// handle normal case
}
else {
// handle unexpected case graciously
}

TVERIFY expands to assert in the build with traces and/or asserts
enabled.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Michal_Vodicka-2 · February 7, 2007, 2:00pm

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Jose Sua[SMTP:xxxxx@windows.microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Wednesday, February 07, 2007 6:00 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Tracing - WPP, ETW, TraceView, WinDbg

Enabling tracing is not at all like installing a driver, the WPP tracing
code is part of the driver and just gets enabled, the events are send to
a log session.

I don’t see a substantial difference between installing the driver from the same build with traces and enabling traces in the installed driver. Both actions lead to use the same code as before and enable new code (traces) which didn’t run previously. In some cases enabling WPP code can be more dangerous. I do use driver with traces for all my development so it is well debugged. WPP code may not be tested so much; if I understand correctly, people don’t use WPP for development and build driver with traces translated to debug prints, instead.

This is the question for WPP users: do you rigorously test the release driver with traces enabled?

One can enable and disable tracing without the need to
reboot the machine or installing a new driver.

Updating a driver takes few secs and no reboot is necessary unless one develops FS related drivers.

WPP is very flexible it allows fine control granularity with 32bit flags
and 256 levels for each flag for each provider GUID. If a single
provider GUID is not enough you can use several provider GUIDs to fit
your needs.

Yes, it was the conclusion before. I’d have to use one GUID per trace area. Our typical binary has 5 - 20 areas and the whole software package has hundreds areas. They have nice names and settings are stored in the registry and our QA know how to work it with it. In many cases they send me correct traces along with bug report. They just look into registry, guess which module could cause problem and set areas which look as related to the problem. I work the same way when encounter a problem caused by module which isn’t mine. Just enable warnings for everything (if they already aren’t), run DebugView and problem can be usually located within minutes. This is code under development and areas are added without notice. They’re automatically added to registry so no problem. Where would I find the right GUIDs and to see traces?

Internal development and testing is a bit different task than problem solution on customer’s site but the point is we can use the same tools and we’re very familiar with it because use it for own development.

Maybe I’m a bit prejudiced against WPP but I have a reason. Previously, when I had a problem with OS drivers, I installed checked versions, enabled debug prints some way and it helped in many cases. Debug prints also helped with disassembly. Similarly with asserts. Now, the same Vista drivers contain WPP and NT_ASSERT nonsense which makes my work harder. It wouldn’t be a problem if MS provides bug free and well documented OS but unfortunately, it isn’t the case.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

Don_Burn_1 · February 7, 2007, 2:27pm

----- Original Message -----
From: “Michal Vodicka”
> I don’t see a substantial difference between installing the driver from
> the same build with traces and
> enabling traces in the installed driver. Both actions lead to use the
> same code as before and enable new
> code (traces) which didn’t run previously. In some cases enabling WPP
> code can be more dangerous.
> I do use driver with traces for all my development so it is well
> debugged. WPP code may not be tested > so much; if I understand
> correctly, people don’t use WPP for development and build driver with
> traces
> translated to debug prints, instead.

Gee, for many commercial users a new driver is a multi-week (some places
are multi-month) test before going to any production system. Of course
they want a fix in days! Sorry, but I have very few customers who would
ever accept “here try this driver” model of debugging.

> This is the question for WPP users: do you rigorously test the release
> driver with traces enabled?

Yes, I use WPP tracing all the time.

> > One can enable and disable tracing without the need to
> > reboot the machine or installing a new driver.
> >
> Updating a driver takes few secs and no reboot is necessary unless one
> develops FS related drivers.

Or if you have applications that depend on the driver. Try shutting down a
video production system, a trading application, or a medical database for a
fre seconds.

> Maybe I’m a bit prejudiced against WPP but I have a reason. Previously,
> when I had a problem with
> OS drivers, I installed checked versions, enabled debug prints some way
> and it helped in many cases.
> Debug prints also helped with disassembly. Similarly with asserts. Now,
> the same Vista drivers contain
> WPP and NT_ASSERT nonsense which makes my work harder. It wouldn’t be a
> problem if MS
> provides bug free and well documented OS but unfortunately, it isn’t the
> case.

I will be the first to agree that Microsoft does a lousy job on supporting
the checked build, but WPP is not the driving force here (unless they
really have changed the source a lot in Vista). In many cases WPP offers
a way to get some of the same data on the free build, you could get with
the checked build.

Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply

Michal_Vodicka-2 · February 7, 2007, 2:54pm

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Don Burn[SMTP:xxxxx@acm.org]
Reply To: Windows System Software Devs Interest List
Sent: Wednesday, February 07, 2007 8:26 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Tracing - WPP, ETW, TraceView, WinDbg

Gee, for many commercial users a new driver is a multi-week (some places
are multi-month) test before going to any production system. Of course
they want a fix in days! Sorry, but I have very few customers who would
ever accept “here try this driver” model of debugging.

Different kind of customers. All our customers accept it with no problem especially within test phase. On the other hand, we don’t have to use this method too often.

BTW, it isn’t “here try this driver”. It is “here is the diagnostic version of the same driver” which allows us to see what exactly happens on you system. The other option is “send us your hardware”.

Our customers also want fix in days (ideally signed driver). It isn’t too hard to explain we need some data for analysis and that capturing traces is faster than overseas hw transport Maybe they’d prefer WPP method but I didn’t hear any complains against debug prints, yet.

> This is the question for WPP users: do you rigorously test the release
> driver with traces enabled?

Yes, I use WPP tracing all the time.

Yesterday you wrote about using WPP_DEBUG macro which, if I understand correctly, replaces WPP traces with KdPrint.

Or if you have applications that depend on the driver. Try shutting down a
video production system, a trading application, or a medical database for a
fre seconds.

If the other option is non-working app, system or BSOD?

I will be the first to agree that Microsoft does a lousy job on supporting
the checked build, but WPP is not the driving force here (unless they
really have changed the source a lot in Vista).

I had to play with OS USB drivers at Vista and it is worse than at XP. Now I don’t remember if major problem were silly NT_ASSERTs or WPP.

In many cases WPP offers
a way to get some of the same data on the free build, you could get with
the checked build.

If you have a way how to translate captured data to traces. If MS makes it available, I wouldn’t complain at all. I’d appreciate if there is an easier way how to see diagnostic data than trying to enable some undocumented mask in a kernel driver.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

Don_Burn_1 · February 7, 2007, 3:01pm

“Michal Vodicka” wrote in message
news:xxxxx@ntdev…
> ----------
> From:
> xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com]
> on behalf of Don Burn[SMTP:xxxxx@acm.org]

> > This is the question for WPP users: do you rigorously test the release
> > driver with traces enabled?
>
> Yes, I use WPP tracing all the time.
>
Yesterday you wrote about using WPP_DEBUG macro which, if I understand
correctly, replaces WPP traces with KdPrint.

WPP_DEBUG means that WPP tracing is sent through a KdPrint, but it is not a
replacement. I.E. You still have WPP tracing, you just also have the spew
enabled in the debugger. That is why I have a conditional in the
WPP_DEBUG, so I can have neither, either or both.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply

OSR_Community_User · February 7, 2007, 3:13pm

I just got back to trying this again.

I started a new TraceView session. These are the versions of supporting files I’m using for TraceView.
Filename Version
dbghelp 6.6.0003.3
msobj80.dll 8.00.50727.762
mspdb80.dll 8.00.50727.762
msvcr80.dll 8.00.50727.762
TraceView.exe 2.1.1

These are the steps I take prior to crash:
* Start a kernel mode WinDbg session between target (XP sp2) and host (XP sp2)
* Start target TraceView
* File–>Create New Log Session
* Add Provider
* Select driver’s “pdb” file
* Select "Real Time Display
* Select Flags (all) and Level (verbose)
* Select Advanced Log Session Options–>Log Session Parameter Options (tab)
Option Defaults My Changes
State STOPPED
Event Count 0
Events Lost 0
Buffers Read 0
Flags Set
Flush Time (S) 1
Maximum Buffers 21
Minimum Buffers 4
Buffer Size 200 3072 (crash) 5120 (crash) 3(success)
Decay Time (Minutes) 20
Circular Buffer Size (MB)
Sequential Buffer Size (MB) 200
Start New File After Buffer Size (MB)
Use Global Sequence Numbers FALSE
Use Local Sequence Numbers TRUE
Level Set
WinDbg FALSE TRUE
Ignore TraceView FALSE
Virtual File Size 65536

* I turn on device connected to target.
* WinDbg catches the BSOD. (Note that the driver/WinDbg/DebugTrace works)
* I got it to work by putting 3 in for buffer size as Alex said. The interface doesn’t say what the number value is (ie. KB)

I also get A LOT of the following messages in WinDbg “Invalid parameter passed to C runtime function.” just by clicking around in the TraceView window.

Thanks for the help. At least I know I can do this with TraceView now.

-Dave
“Alex Bendetov” wrote in message news:xxxxx@ntdev…
“* I enabled tracing using the latest version of TraceView and had a very
similar crash as the previous times.”

David, I think the problem is that TraceView defaults to buffer size > 3K.

When you configure trace session in TraceView make sure to select buffer size = 3K and it shoudln’t crash. On Vista appropriate checks were added, and system no-longer crashes.

Alex

> From: xxxxx@hunter.com
> Subject: Re:[ntdev] Tracing - WPP, ETW, TraceView, WinDbg
> Date: Tue, 6 Feb 2007 15:23:27 -0600
> To: xxxxx@lists.osr.com
>
> I still have the crash in TraceView.
>
>
> * I have WinDbg version 6.6.0007.5 on both my target and host PC.
> * I am using TraceView.exe version 2.1.1 Copyright 2005 from WDK RTM 6000.
> (Note that I had the same version on my target as my host but the file size
> was different so I made sure to copy everything from
> C:\WINDDK\6000\tools\tracing\i386 to my target box).
> * I could not find a “windbg.dll” file anywhere on both my target and host
> PC.
>
> * I ran tracelog -start MySession -guid
> #635CC065-EFCD-4593-84E6-BC1354963E8F -flags ff -level 5 -f MyLog.etl -kd
>
> This resulted in the command line output:
> Logger Started…
> Enablling trace to logger 2
> Operation Status: 0L The operation completed successfully.
> Logger Name: MySession
> Logger Id: 0x2
> Logger Thread Id: 00000F10
> Guid: 635CC065-EFCD-4593-84E6-BC1354963E8F
> Buffer Size: 3 kb
> Maximum Buffers: 25
> Minimum Buffers: 3
> Number of Bufferes: 3
> Free Buffers: 2
> Buffers Written: 1
> Events Lost: 0
> Log Buffers Lost: 0
> Real Time Buffers Lost: 0
> AgeLimit: 15
> ClockType: SystemTime
> Log Mode: Sequential
> Kd Filter mode enabled
> Maximum File Size: not set
> Buffer Flush Timer: not set
> Enabled tracing: 0x00000001
> Log Filename: blah blah MyLog.etl
>
> I loaded the wmitrace “!load wmitrace.dll” but that was as far as I got with
> the command line option to send trace output to WinDbg.
>
> * I enabled tracing using the latest version of TraceView and had a very
> similar crash as the previous times.
> kd> !analyze -v
> ***
> *
>
> * Bugcheck Analysis
> *
>
>
>
> DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
> An attempt was made to access a pageable (or completely invalid) address at
> an
> interrupt request level (IRQL) that is too high. This is usually
> caused by drivers using improper addresses.
> If kernel debugger is available get stack backtrace.
> Arguments:
> Arg1: 8069e000, memory referenced
> Arg2: 00000002, IRQL
> Arg3: 00000000, value 0 = read operation, 1 = write operation
> Arg4: f7988098, address which referenced memory
>
> Debugging Details:
> ------------------
>
>
> READ_ADDRESS: 8069e000
>
> CURRENT_IRQL: 2
>
> FAULTING_IP:
> kdcom!KdpComputeChecksum+12
> f7988098 0fb631 movzx esi,byte ptr [ecx]
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> BUGCHECK_STR: 0xD1
>
> PROCESS_NAME: System
>
> TRAP_FRAME: b9ff7b90 – (.trap ffffffffb9ff7b90)
> ErrCode = 00000003
> eax=00000004 ebx=85a04bf8 ecx=00000001 edx=00000002 esi=b9ff7c3c
> edi=8069b000
> eip=8053af55 esp=b9ff7c04 ebp=b9ff7c60 iopl=0 nv up di pl nz na po
> nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00010002
> nt!MmDbgCopyMemory+0x38a:
> 8053af55 f3a5 rep movs dword ptr es:[edi],dword ptr [esi]
> es:0023:8069b000=50524920 ds:0023:b9ff7c3c=ffffffff
> Resetting default scope
>
> EXCEPTION_RECORD: b9ff761c – (.exr ffffffffb9ff761c)
> ExceptionAddress: 804e3b25 (nt!RtlpBreakWithStatusInstruction)
> ExceptionCode: 80000003 (Break instruction exception)
> ExceptionFlags: 00000000
> NumberParameters: 3
> Parameter[0]: 00000000
> Parameter[1]: 8050589d
> Parameter[2]: 0000006a
>
> LAST_CONTROL_TRANSFER: from 805328e7 to 804e3b25
>
> STACK_TEXT:
> b9ff6b58 805328e7 00000003 b9ff6eb4 00000000
> nt!RtlpBreakWithStatusInstruction
> b9ff6ba4 805333be 00000003 8069e000 f7988098 nt!KiBugCheckDebugBreak+0x19
> b9ff6f84 804e2158 0000000a 8069e000 00000002 nt!KeBugCheck2+0x574
> b9ff6f84 f7988098 0000000a 8069e000 00000002 nt!KiTrap0E+0x233
> b9ff701c f7988262 80691918 0000fffc ffdff13c kdcom!KdpComputeChecksum+0x12
> b9ff704c 8067cf12 00000007 b9ff71e0 b9ff71d8 kdcom!KdSendPacket+0x24
> b9ff70c8 8067d0bd 00000007 b9ff71e0 b9ff71d8 nt!KdpSendWaitContinue+0x2e0
> b9ff71e8 805325a4 b9ff761c ffdff13c 00000000
> nt!KdpReportExceptionStateChange+0x8a
> b9ff7208 8067e137 b9ff7670 00000000 b9ff7600 nt!KdpReport+0x60
> b9ff7234 804fa243 b9ff7670 00000000 b9ff761c nt!KdpTrap+0x108
> b9ff7600 804dfada b9ff761c 00000000 b9ff7670 nt!KiDispatchException+0x129
> b9ff7668 804e0208 b9ff772c 804e3b26 badb0d00 nt!CommonDispatchException+0x4d
> b9ff7668 804e3b26 b9ff772c 804e3b26 badb0d00 nt!KiTrap03+0xad
> b9ff76e0 805328e7 00000003 b9ff7a3c 00000000
> nt!RtlpBreakWithStatusInstruction+0x1
> b9ff772c 805333be 00000003 c0300804 81800000 nt!KiBugCheckDebugBreak+0x19
> b9ff7b0c 805339ae 000000be 8069b000 0069b121 nt!KeBugCheck2+0x574
> b9ff7b2c 805246fb 000000be 8069b000 0069b121 nt!KeBugCheckEx+0x1b
> b9ff7b78 804e1ff1 00000001 8069b000 00000000 nt!MmAccessFault+0x6f5
> b9ff7b78 8053af55 00000001 8069b000 00000000 nt!KiTrap0E+0xcc
> b9ff7c60 8067d6bc 85a04bf8 00000000 8069b000 nt!MmDbgCopyMemory+0x38a
> b9ff7c88 8067c504 85a04bf8 00000000 8069b000 nt!KdpCopyMemoryChunks+0x68
> b9ff7d00 8067cc1c b9ff7d0c 0000ffff 859f9000 nt!KdpSendTraceData+0x28
> b9ff7d14 8067a1fb 859f9001 00000000 85ac5010 nt!KdReportTraceData+0x41
> b9ff7d58 806408a0 00000000 859f9000 00000000 nt!WmipFlushBuffer+0x336
> b9ff7d80 80640ac9 85ac5054 00000001 00000000 nt!WmipFlushActiveBuffers+0x18d
> b9ff7dac 8057dfed 00000001 00000000 00000000 nt!WmipLogger+0x16f
> b9ff7ddc 804fa477 8064095a 85ac5000 00000000 nt!PspSystemThreadStartup+0x34
> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
>
>
> STACK_COMMAND: kb
>
> FOLLOWUP_IP:
> kdcom!KdpComputeChecksum+12
> f7988098 0fb631 movzx esi,byte ptr [ecx]
>
> SYMBOL_STACK_INDEX: 4
>
> SYMBOL_NAME: kdcom!KdpComputeChecksum+12
>
> FOLLOWUP_NAME: MachineOwner
>
> MODULE_NAME: kdcom
>
> IMAGE_NAME: kd1394.dll
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 41107b3a
>
> FAILURE_BUCKET_ID: 0xD1_VRF_kdcom!KdpComputeChecksum+12
>
> BUCKET_ID: 0xD1_VRF_kdcom!KdpComputeChecksum+12
>
> Followup: MachineOwner
> ---------
>
>
> “Jose Sua” wrote in message
> news:xxxxx@ntdev…
> You can enable trace with the command line tools available in the
> WDK/DDK:
>
> I would recommend using the latest traceview part of the WDK and if that
> fails let me know. You must also have the windbg.dll from the debugger
> for traceview to work fine.
>
> Tracelog (part of the WDK/DDK) take a look at the documentation on
> MSDN. You can also use logman which is a tool part of the OS.
>
> Fist case:
> Start Tracing
> Tracelog -start sessionname -guid #theProviderGuidInyourComponent -flags
> yourflags -level levelIfUsed -f logfile.etl
>
> Then run your scenario
>
> Stop tracing.
> tracelog -stop sessionname
>
>
> You need the TMF files to view the events
>
> Tracepdb -f yourdriver.pdb // this is a tool that extracts the tmf
> files
>
>
> tracefmt -display -p . logfile.etl // this tool will show you the
> events and save them to a file.
>
>
> The windbg scenario.
>
> Enable tracing on your target machine using tracelog like above, but you
> need to add the -kd obtion.
>
> Then on your windbg kd machine, you need to use the wmitrace extension
> which is part of the debugger to view the events.
>
> !wmitrace.help to see the options.
>
> But you must locate your trace session, which is provided when you ran
> tracelog on the target machiene. Then you can see the trace buffers of
> that session on the debugger.
> In your debugger machine you need to have a copy of the tmf files
> generated from tracepdb and your driver pdb file so that the extension
> can decode the events.
>
> !wmitrace extension should work on xp with the latest updates.
>
>
>
> Thanks,
> Jose Sua
> Microsoft Corporation
> This posting is provided “AS IS” with no warranties and confers no
> rights.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of David Voeller
> Sent: Tuesday, February 06, 2007 8:42 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Tracing - WPP, ETW, TraceView, WinDbg
>
> I have a KMDF USB driver that includes WPP tracing. The target box is
> XP
> sp2. I have the driver code setup so that I can switch between WPP
> tracing
> for driver release and Debug Tracing for development. I’ve been using
> Debug
> Tracing for all of my diagnostics but I thought I would give WPP tracing
> a
> try. I’m thinking that if I deploy a release version of the driver and
> there is a problem, my first attempt at fixing the problem will be to
> enable
> tracing at the customer’s site using a “ctl” file and then look at the
> resulting “etl” output once the problem has been recorded. My second
> attempt at fixing the problem will be to have the entire PC sent back in
>
> which case I would like to connect to the box with firewire/WinDbg and
> view
> the trace output.
>
> I wanted to test these situations so I built the driver with WPP
> enabled.
> For the second case where I connect to the target with WinDbg, the only
> way
> I could find from the docs to get trace output to WinDbg is to use
> TraceView
> (or command line equivalent) to start a trace session and enable trace
> output to WinDbg as well as TraceView. I’ve tried this 2 times and
> always
> get the crash shown below.
>
> Question 1: Is there another way to enable trace output to WinDbg
> besides
> using TraceView?
> Question 2: Is this crash a legitimate bug?
>
>
> LAST_CONTROL_TRANSFER: from 805328e7 to 804e3b25
>
> STACK_TEXT:
> ba12eb58 805328e7 00000003 ba12eeb4 00000000
> nt!RtlpBreakWithStatusInstruction
> ba12eba4 805333be 00000003 8069e000 f7988098
> nt!KiBugCheckDebugBreak+0x19
> ba12ef84 804e2158 0000000a 8069e000 00000002 nt!KeBugCheck2+0x574
> ba12ef84 f7988098 0000000a 8069e000 00000002 nt!KiTrap0E+0x233
> ba12f01c f7988262 80691918 0000fffc ffdff13c
> kdcom!KdpComputeChecksum+0x12
> ba12f04c 8067cf12 00000007 ba12f1e0 ba12f1d8 kdcom!KdSendPacket+0x24
> ba12f0c8 8067d0bd 00000007 ba12f1e0 ba12f1d8
> nt!KdpSendWaitContinue+0x2e0
> ba12f1e8 805325a4 ba12f61c ffdff13c 00000000
> nt!KdpReportExceptionStateChange+0x8a
> ba12f208 8067e137 ba12f670 00000000 ba12f600 nt!KdpReport+0x60
> ba12f234 804fa243 ba12f670 00000000 ba12f61c nt!KdpTrap+0x108
> ba12f600 804dfada ba12f61c 00000000 ba12f670
> nt!KiDispatchException+0x129
> ba12f668 804e0208 ba12f72c 804e3b26 badb0d00
> nt!CommonDispatchException+0x4d
> ba12f668 804e3b26 ba12f72c 804e3b26 badb0d00 nt!KiTrap03+0xad
> ba12f6e0 805328e7 00000003 ba12fa3c 00000000
> nt!RtlpBreakWithStatusInstruction+0x1
> ba12f72c 805333be 00000003 c0300804 81800000
> nt!KiBugCheckDebugBreak+0x19
> ba12fb0c 805339ae 000000be 8069b000 0069b121 nt!KeBugCheck2+0x574
> ba12fb2c 805246fb 000000be 8069b000 0069b121 nt!KeBugCheckEx+0x1b
> ba12fb78 804e1ff1 00000001 8069b000 00000000 nt!MmAccessFault+0x6f5
> ba12fb78 8053af55 00000001 8069b000 00000000 nt!KiTrap0E+0xcc
> ba12fc60 8067d6bc 85fc1bf8 00000000 8069b000 nt!MmDbgCopyMemory+0x38a
> ba12fc88 8067c504 85fc1bf8 00000000 8069b000 nt!KdpCopyMemoryChunks+0x68
> ba12fd00 8067cc1c ba12fd0c 0000ffff 85fb6000 nt!KdpSendTraceData+0x28
> ba12fd14 8067a1fb 85fb6001 00000000 86152010 nt!KdReportTraceData+0x41
> ba12fd58 806408a0 00000000 85fb6000 00000000 nt!WmipFlushBuffer+0x336
> ba12fd80 80640ac9 86152054 00000001 00000000
> nt!WmipFlushActiveBuffers+0x18d
> ba12fdac 8057dfed 00000001 00000000 00000000 nt!WmipLogger+0x16f
> ba12fddc 804fa477 8064095a 86152000 00000000
> nt!PspSystemThreadStartup+0x34
> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
>
>
> STACK_COMMAND: kb
>
> FOLLOWUP_IP:
> kdcom!KdpComputeChecksum+12
> f7988098 0fb631 movzx esi,byte ptr [ecx]
>
> SYMBOL_STACK_INDEX: 4
>
> SYMBOL_NAME: kdcom!KdpComputeChecksum+12
>
> FOLLOWUP_NAME: MachineOwner
>
> MODULE_NAME: kdcom
>
> IMAGE_NAME: kd1394.dll
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 41107b3a
>
> FAILURE_BUCKET_ID: 0xD1_VRF_kdcom!KdpComputeChecksum+12
>
> BUCKET_ID: 0xD1_VRF_kdcom!KdpComputeChecksum+12
>
> Followup: MachineOwner
> ---------
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

------------------------------------------------------------------------------
Live Search: Better results, fast Try it now!

Michal_Vodicka-2 · February 7, 2007, 3:25pm

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Don Burn[SMTP:xxxxx@acm.org]
Reply To: Windows System Software Devs Interest List
Sent: Wednesday, February 07, 2007 9:00 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Tracing - WPP, ETW, TraceView, WinDbg

WPP_DEBUG means that WPP tracing is sent through a KdPrint, but it is not a
replacement. I.E. You still have WPP tracing, you just also have the spew
enabled in the debugger. That is why I have a conditional in the
WPP_DEBUG, so I can have neither, either or both.

OK, so you have both. But does it mean WPP code is really used if you look at debug prints and don’t enable WPP capture? That’s my doubt – if all the code which runs at customer’s site with WPP enabled also runs during development.

One question (not biased, just curious – what about boot logging? Currently a customer has a problem after installing the latest Vista USB patch. It seems as in some cases (one of 20 or more) our USB device is enumerated later than usual and isn’t available immediatelly for logon. As the first step I’d need to see traces from driver start to see if there really a problem with enumeration or with our software accessing device. With DebugView it is possible but rather tedious (has to be reenabled for every boot). Is it even possible with WPP and if so, what has to be done? I asked customer to repeatedly enable boot log, reboot and repeat until problem is reproduced and then save log.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

Don_Burn_1 · February 7, 2007, 3:50pm

“Michal Vodicka” wrote in message
news:xxxxx@ntdev…

One question (not biased, just curious – what about boot logging?
Currently a customer has a problem after installing the latest Vista USB
patch. It seems as in some cases (one of 20 or more) our USB device is
enumerated later than usual and isn’t available immediatelly for logon. As
the first step I’d need to see traces from driver start to see if there
really a problem with enumeration or with our software accessing device.
With DebugView it is possible but rather tedious (has to be reenabled for
every boot). Is it even possible with WPP and if so, what has to be done? I
asked customer to repeatedly enable boot log, reboot and repeat until
problem is reproduced and then save log.

This is one area that is still a pain in the ass. I know Microsoft has
capabilities here to do this, but in part because I fall back to systems
that don’t always have it, I do fall back to KdPrint’s. Fortunately, these
are few and far between, most of the bugs are why did things fail to
function, and WPP tracing is fine in these cases.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply

OSR_Community_User · February 7, 2007, 4:26pm

In Vista this is simple. Please take a look at AutoLoggers.

AutoLogger are log sessions that you can define to enable your provider
at boot time and send the events to the AutoLogger session. You can
configure the level, and flags, keywords etc.

DownLevel Vista you have GlobalLogger. Also at MSDN for doc
This is a logger that starts at boot time, you can configure which
provider GUID you want enabled with flags and levels. The limitation
here is that there is only one logger for boot time so make sure no
other providers are enabled so you can just look at your data.

For this to work you must add to your driver.
#define WPP_GLOBALLOGGER

You can configure both autologger and globallogger with tracelog.
//documentation on MSDN look for Tracing During Boot.

For WPP when tracing in not enabled all you have is a simple compare, if
tracing enabled for the level and flags, which is very fast.
When tracing is enabled we do take the arguments and try to log the
arguments.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Wednesday, February 07, 2007 12:50 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Tracing - WPP, ETW, TraceView, WinDbg

“Michal Vodicka” wrote in message
news:xxxxx@ntdev…

One question (not biased, just curious – what about boot logging?
Currently a customer has a problem after installing the latest Vista USB

patch. It seems as in some cases (one of 20 or more) our USB device is
enumerated later than usual and isn’t available immediatelly for logon.
As
the first step I’d need to see traces from driver start to see if there
really a problem with enumeration or with our software accessing device.

With DebugView it is possible but rather tedious (has to be reenabled
for
every boot). Is it even possible with WPP and if so, what has to be
done? I
asked customer to repeatedly enable boot log, reboot and repeat until
problem is reproduced and then save log.

This is one area that is still a pain in the ass. I know Microsoft has
capabilities here to do this, but in part because I fall back to systems

that don’t always have it, I do fall back to KdPrint’s. Fortunately,
these
are few and far between, most of the bugs are why did things fail to
function, and WPP tracing is fine in these cases.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer