Driver Problems? Questions? Issues?
Put OSR's experience to work for you! Contact us for assistance with:
  • Creating the right design for your requirements
  • Reviewing your existing driver code
  • Analyzing driver reliability/performance issues
  • Custom training mixed with consulting and focused directly on your specific areas of interest/concern.
Check us out. OSR, the Windows driver experts.

On-Access, Transparent, Per-File Data Encryption:

OSR's File Encryption Solution Framework (FESF) provides all the infrastructure you need to build a transparent file encryption product REALLY FAST.

Super flexible policy determination and customization, all done in user-mode. Extensive starter/sample code provided.

Proven, robust, flexible. In use in multiple commercial products.

Currently available on Windows. FESF for Linux will ship in 2018.

For more info: https://www.osr.com/fesf

Go Back   OSR Online Lists > ntfsd
Welcome, Guest
You must login to post to this list
  Message 1 of 2  
12 Sep 17 12:47
Mickey H
xxxxxx@gmail.com
Join Date: 23 Jul 2017
Posts To This List: 19
minifilter driver logging

Hi, 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? Thanks
  Message 2 of 2  
12 Sep 17 12:57
Don Burn
xxxxxx@windrvr.com
Join Date: 23 Feb 2011
Posts To This List: 167
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 https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/wpp-softwa re-tracing since it stores the binary values instead of doing a full "printf" implementation. Of course if you are actually debugging the driver, then DbgPrint and using WinDbg to allow full debugging is the way to go. Don Burn Windows Driver Consulting Website: http://www.windrvr.com -----Original Message----- From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com xxxxx@lists.osr.com Sent: Tuesday, September 12, 2017 12:46 PM To: Windows File Systems Devs Interest List <xxxxx@lists.osr.com> Subject: [ntfsd] minifilter driver logging Hi, 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? Thanks --- NTFSD is sponsored by OSR MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at <http://www.osr.com/seminars> To unsubscribe, visit the List Server section of OSR Online at <http://www.osronline.com/page.cfm?name=ListServer>
Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You must login to OSR Online AND be a member of the ntfsd list to be able to post.

All times are GMT -5. The time now is 13:27.


Copyright ©2015, OSR Open Systems Resources, Inc.
Based on vBulletin Copyright ©2000 - 2005, Jelsoft Enterprises Ltd.
Modified under license