Message 2 of 2
12 Sep 17 12:57
Join Date: 23 Feb 2011
Posts To This List: 175
minifilter driver logging
I'm not sure DebugView consumes much, but DbgPrint definitely can add a lot
of overhead. You might look at WPP tracing which has low overhead
re-tracing since it stores the binary values instead of doing a full
Of course if you are actually debugging the driver, then DbgPrint and using
WinDbg to allow full debugging is the way to go.
Windows Driver Consulting
[mailto:firstname.lastname@example.org] On Behalf Of email@example.com
Sent: Tuesday, September 12, 2017 12:46 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] minifilter driver logging
I have been working for a few months on my first minifilter driver, and I am
currently using "DbgPrint" and "DebugView" for logging.
I found "DebugView" not very convenient to work with as it consumes a lot of
CPU when loaded and because I need to manually run it in order for logging
to be stored to a file.
Is there a more convenient infrastructure for driver logs? Or maybe is there
a way to capture "DbgPrint" in user space?
I am looking for something which can always store log messages to a file for
later analysis and will not have that much affect on CPU.
Also, what is the common approach for driver logging for debug and release?
NTFSD is sponsored by OSR
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software
To unsubscribe, visit the List Server section of OSR Online at