DebugView help not working on Windows XP X64 Pro and Windows 7 x64 (?)

  • Thread starter Thread starter Skybuck Flying
  • Start date Start date
S

Skybuck Flying

Hello,

There is one little problem with DebugView:

The help file is not working ?!

I suspect this problem must be known for some time now ???!!!???

I could try and view it on windows xp 32 bit... on my other computer.

Or maybe in windows 95 on my virtual pc :) or even in vmware ;) :)

I got a couple of those (w95's ;)) <- fast ;) :)

But I still ask this question:

Is there an update help file somewhere ?

And is the help actually any good ?

I am still a little bit confused about DebugView ?!?

Is there indeed some latency before dbgprints come into it ?

Or is it a bit shaky ?

I would guess it has some lag because of all the strings and such ?

I do hope these strings are only present in the debug mode of windows ?

Don't tell me this lag is actually present in windows itself under normal
mode ?

I wouldn't believe it anyway because how would computer games have any good
latency ?!?

But anyway suppose that the message are done in normal mode as well then
maybe that
should not be done and would make windows a hell lot faster ?!? ;)

Bye,
Skybuck.
 
Skybuck Flying said:
I am still a little bit confused about DebugView ?!?

Is there indeed some latency before dbgprints come into it ?
Click to expand...

Yes. Debug prints are stored in a circular buffer in the kernel. DebugView
has to periodically check the circular buffer to see if there is anything
new there. There's no callback, since this wasn't the primary way debug
messages were designed to be read. So, it's polled, and polling scheme
naturally have some latency.
I do hope these strings are only present in the debug mode of windows ?
Click to expand...

What strings?
Don't tell me this lag is actually present in windows itself under normal
mode ?
Click to expand...

The lag is not caused by the generation of the messgaes. The lag is just a
manifestation of the method DebugView has to use to fetch the messages.
I wouldn't believe it anyway because how would computer games have any good
latency ?!?
Click to expand...

What on earth does DebugView latency have to do with computer games?
But anyway suppose that the message are done in normal mode as well then
maybe that should not be done and would make windows a hell lot faster ?!? ;)
Click to expand...

Generating a debug message takes virtually no time at all.
 
I do hope these strings are only present in the debug mode of windows ?
What strings?
Click to expand...

These kind of strings:

"blablabla"

Example:

DEBUGP(MP_TRACE, ("<-- NICCopyPacket\n"));
What on earth does DebugView latency have to do with computer games?
Click to expand...

If the debugview latency was caused by the strings, then it would effect
computer games
as well since they would use these kind of drivers too...
Generating a debug message takes virtually no time at all.
Click to expand...

I would expect the DEBUGP statement to be completely removed from drivers.

If that is not the case and there is actually a call executed then this will
still slow down the software
quite a lot.

Bye,
Skybuck.
 
Skybuck Flying said:
I would expect the DEBUGP statement to be completely removed from drivers.

If that is not the case and there is actually a call executed then this
will still slow down the software
quite a lot.
Click to expand...

Yes, debug prints (via kernel debugger) have certain performance
cost, and are usually disabled in release version of drivers.
But without them, debugging could be a bit harder.

--pa
 
There are several items about debug print statements that are important:

1. Memory for the string(s)
2. Code to execute to prepare and display the strings
3. The OS call to actually do the output to the debug display
device/program

Some of the macros only compile to generating code if DBG is greater than
zero. Others such as DbgPrint() work even in free builds. If the OS, such
as Vista and later, have a filtering method to suppresses output unless some
flag is set it eliminates some output. However, I don't know if most of the
rest of the code executes before that decision is made - and I have no
desire to trace the code and see where it is blocked. There is an issue in
some drivers, mostly hardware based, where debug code can change the
behavior significantly enough to hide a bug or in some cases actually create
an error.

I develop with checked builds of my drivers until very late in the process.
However I have been doing this so long, I don't find too many timing
dependencies where a working checked driver will not work in a free build.
I have seen the reverse though.
 
Back
Top