I was thinking about the flush timer as described in
http://msdn.microsoft.com/en-us/library/windows/desktop/aa363687(v=vs.85).a
spx
I’ve generally macroized the WPP calls so I can flip a compile switch to
send messages to either WPP or KDPrint (or both). If I’m giving the code
to someone else, like QA, WPP is generally more useful, because I’ve never
been consistently successful getting QA groups to have kernel debuggers
connected. If I’m just debugging the code myself, with a kernel debugger
attached, I often just prefer to see the real-time KDPrint messages.
It’s also possible to dump the in memory buffer of WPP messages than have
yet to be flushed. I believe there is a windbg extension than knows how to
do this.This can be useful to see messages that didn’t get flushed just
before a crash. For early boot drivers, getting QA to have windbg over
1394 connected systems is useful, as you can then get crash dumps even if
the system didn’t boot.
Is the system fully coming up and doesn’t seem to write the log? Or are
you debugging something like a boot disk driver, and it crashes before the
boot volume is even mounted?
Actually, I like three levels of logging sophistication. 1) KDPrint/WPP
that I can send to windbg in real-time 2) WPP to a file for intermediate
and detailed field debugging 3) structured ETW event tracing, to generate
things like detailed state change and timing data, for customer site
debug/analysis and higher whole system debugging/analyzing/measuring. The
OS comes with a couple hundred ETW event sources (some poorly documented),
so you can often generate traces that show both your components and
Microsoft components. For ETW traces, you also get to use a thing called
the correlation id, which helps associate events with the originator. For
ETW logs, there is also a super cool Microsoft tool called Message
Analyzer, that can inhale ETW logs and you can build things like
meaningful protocol traces, although last time I fooled with MA the docs
for the custom language were in need of improvement.
Jan
On 11/25/14, 6:35 AM, “xxxxx@yahoo.com.vn”
wrote:
>Thank you Jan,
>I am trying to using Windbg from a host computer to try catching the
>message. The problem is that I still cannot get it to work in -kd mode to
>make the data to the debugger ~~
>Can you elaborate which options can make it flushed data out earlier?
>
>
>—
>NTDEV is sponsored by OSR
>
>Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
>OSR is HIRING!! See http://www.osr.com/careers
>
>For our schedule of WDF, WDM, debugging and other seminars visit:
>http://www.osr.com/seminars
>
>To unsubscribe, visit the List Server section of OSR Online at
>http://www.osronline.com/page.cfm?name=ListServer