Well, normally you would use KdPrint, which is a macro which does nothing in
a release version (if you call DbgPrint explicitly, those calls remain in
the release version). Also, not DbgPrintEx/KdPrintEx allow you to do
selective debugging; the mechanisms are weird and convoluted, but do work.
These calls consume time, because (at least to the best of my knowledge)
they are essentially “synchronous” and don’t return until all the bytes have
been transmitted across the debug port (normally at 115200, this is still an
unacceptable delay in an ISR or anything at DPC level).
There is, or at least was at one time, a limit of 512 characters in the
final formatted string. What was not defined was what happened if you
exceeded this (did you get some fatal buffer overflow or did it just
truncate the message? Inquiring Minds Want To Know)
As far as I know, DbgPrint consumes no significant resources, beyond time.
But that is a critical resource for some devices, and therefore you must use
DbgPrint with caution, even in checked builds. Consume too much time at the
wrong place in your code and your device might see this as a failure. For
example, if the DbgPrint causes you to take so much time reading that the
internal buffers on the device overflow because you are missing your
realtime window.
Restricting the DbgPrints to error conditions only (instead of just logging
all kinds of normal-flow events) is one way to see if this is the cause of
the problem. Once you’ve got an error, you are already in trouble, and
taking extra time to report this probably will have no effect on what you
are doing. Maybe. Probably. Sort of. It all depends on your device. In
the case of ISR and DPC, your DbgPrint messages can consume enough time that
*other* devices are deprived of their necessary time windows, and therefore
they can start failing also. Remember, you’ve got nominally 10us at ISR and
50us at DPC, and that isn’t nearly enough time to do a single DbgPrint
statement, so anyhing at those levels is violating the basic guidelines for
response time.
joe
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Tuesday, December 28, 2010 12:25 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Is Debug statements will affect the performance of the
writing and reading driver
Hi,
I developed the USB driver, Driver is builded on chk-x86 on xp. [for the
debug purpose] I added the Dbgprint statement in all the functions.
For continuous “read and write failing” - test application the file size is
around 350kb.
i Commented all the DbgPrint statements used. Driver is builded on chk-x86
on xp. [for the debug purpose] Again i tried, for the test application, the
same file size, “the read and write is working”
Is this is because of memory consumption for the debug statements?
Is any limitation of using Dbgprint statements?
Please any body tell the reason? How to achieve this.
Thanks in advance.
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
–
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.