As we know, DebugView can catchs kernel log created by DbgPrint.
Can anybody tell me the theory or offer me some information ??
thanks
“the theory of offer… information” about WHAT exactly?
Peter
OSR
You might want to take a look at DbgSetDebugPrintCallback().
Good luck,
mm
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Tuesday, January 18, 2011 10:15 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] catch log
As we know, DebugView can catchs kernel log created by DbgPrint.
Can anybody tell me the theory or offer me some information ??
thanks
NTDEV is sponsored by OSR
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
On 01/18/2011 04:14 PM, xxxxx@hotmail.com wrote:
As we know, DebugView can catchs kernel log created by DbgPrint.
Can anybody tell me the theory or offer me some information ??
thanks
As we know, you are too lazy to do a Google search, so we’ll do it and
post the search results for you:
http://www.osronline.com/article.cfm?id=295
http://www.osronline.com/ddkx/ddtools/debugfns_9ecz.htm
Hopefully the offered information is helpful.
It seems that I can use DbgSetDebugPrintCallback() to do test.
I have found an article which is listed as follows:
Capturing DbgPrint calls in Windows Vista
A couple of days ago I downloaded and installed the Windows Vista Beta 2 for the first time. One of the first things that caught my eye was a new export in the kernel, called DbgSetDebugPrintCallback. It looked like Microsoft had implemented a standardized way to capture DbgPrint calls. I tried to find some documentation describing the new routine but I could not find anything anywhere, so I decided to do some reversing.
Reversing DbgSetDebugPrintCallback
First of all I reversed the DbgSetDebugPrintCallback routine itself. It turned out that it takes two parameters. The first parameter is a pointer to the callback function we wish to register; the second one is a BOOLEAN that tells the routine whether to register or unregister the callback function.
The kernel keeps one single internal pointer to one single callback function at a time. When we register a new callback function the internal pointer must be NULL. When we unregister a callback function, the kernel compares the pointer we pass with the internal pointer. For the unregistering to succeed the two pointers must be equal. The internal pointer is then reset to NULL.
To find out which parameters the callback function takes I had to do some reversing of the kernel code that calls it. Determining the number of parameters and the exact meaning of two of them turned out to be really simple. Determining the exact type of the third parameter (or rather the first one) turned out to be a bit more work. Since there is quite a bit of code involved I will just continue with the full results of my work:
NTSTATUS DbgSetDebugPrintCallback(IN PDEBUGPRINT_CALLBACK_FUNCTION Function, IN BOOLEAN Mode);
Function - Pointer to the DebugPrintCallback routine to register or unregister.
Mode - TRUE to register the callback function; FALSE to unregister it.
void DebugPrintCallback(IN PANSI_STRING String, IN ULONG ComponentId, IN ULONG Level);
String - A pointer to the debugging message string.
ComponentID - See the documentation for DbgPrintEx.
Level - See the documentation for DbgPrintEx.
Using DbgSetDebugPrintCallback in practice
First of all, DbgSetDebugPrintCallback is a kernel routine so it has to be called from kernel mode.
I am not sure if Microsoft intends to ever document DbgSetDebugPrintCallback or not. At this point there seems to be no documentation and I have not been able to find the routine in any include files or lib files. To get a pointer to the DbgSetDebugPrintCallback routine we can simply call MmGetSystemRoutineAddress and ask for it.
One last note - if you plan to make it possible to unload your driver you must not forget to unregister the callback function before the driver unloads. Obvious but easy to forget anyway.
/Arne
===============================================
You might want to take a look at DbgSetDebugPrintCallback().
“the theory of offer… information” about WHAT exactly?
=================================================
It means that I want to catch the log created by “DbgPrint” in my own driver.
I need a method to catch the log.
>It means that I want to catch the log created by “DbgPrint” in my own
driver.
I need a method to catch the log.
If it’s your driver, why not just wrap your DbgPrint calls in an inline
function or macro that logs the trace statements?
-scott
–
Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc.
http://www.osronline.com
Hope to see you at the next OSR kernel debugging class February 14th in
Columbia, MD!
wrote in message news:xxxxx@ntdev…
“the theory of offer… information” about WHAT exactly?
=================================================
It means that I want to catch the log created by “DbgPrint” in my own
driver.
I need a method to catch the log.
Have you considered ETW instead? It is very powerful and has a ready usermode API.
–pa
xxxxx@hotmail.com wrote:
“the theory of offer… information” about WHAT exactly?
=================================================
It means that I want to catch the log created by “DbgPrint” in my own driver.
I need a method to catch the log.
In most circumstances, the best and most expedient solution here is to
use dbgview and save the log file from there. Dbgview can save the log
to disk in real-time.
If you are planning to monitor the output to look for specific events to
respond to, then I submit that you have a flawed design.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
>If it’s your driver, why not just wrap your DbgPrint calls in an inline
function or macro that logs the trace statements?
I want to get the formatted string created by dbgprint.
when I get the formatted string, I can write a file in my driver.
>In most circumstances, the best and most expedient solution here is to
use dbgview and save the log file from there. Dbgview can save the log
to disk in real-time.
If you are planning to monitor the output to look for specific events to
respond to, then I submit that you have a flawed design.
The log will record some error information in my driver.
As you know, we can’t tell users to open dbgview to save log.
>Have you considered ETW instead? It is very powerful and has a ready usermode
API.
The ETW of WDF?
let me have a try.
xxxxx@hotmail.com wrote:
I want to get the formatted string created by dbgprint.
when I get the formatted string, I can write a file in my driver.
This statement is confusing. Are you saying you want to monitor the
debug output of driver A from driver B? Why don’t you just modify
driver A to keep debug information in your own circular buffer, then
provide a private ioctl to return that buffer? Then, all you need is a
simple user-mode application to go read the accumulated information.
The log will record some error information in my driver.
As you know, we can’t tell users to open dbgview to save log.
This paragraph is wrong in several ways. A released driver should not
be sending anything to the debug log. The debug log is intended for
debugging messages in exceptional conditions. In exceptional
conditions, I have no problem at all directing my clients to download
dbgview to capture the output of my checked driver. We are partners in
the process of isolating the problem.
If you have error information that needs to be recorded by your released
driver, then you should be using the event log, not the debug log.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.