windows-server-2003/sdktools/dbmon/readme.txt

DBMON notes

10/7/94


The first DWORD of the shared memory buffer contains the process ID of the
client that sent the debug string.  DBMON will print the process ID if the
previous line printed was from another process, or if the previous line was
from the same process and ended in a newline.

The shared memory buffer must be 4096 bytes.  If it is larger, it won't do any
good.  If it is smaller, nothing terrible will happen, but strings larger than
the buffer will not be delivered, and a complaining message will be sent to the
kernel debugger by the client.  Why is it this size?  Because shared memory
comes in page-sized chunks, so we might as well ask for as much as will be used
on the machines with the smallest pages.  On machines with larger pages, the
remainder of the page will be wasted anyway.

Event DBWIN_BUFFER_READY must be an auto-reset event, so that only one client
thread will use the buffer at a time.  Using a manual reset event with
PulseEvent will not work.

Event DBWIN_DATA_READY need not be auto-reset, but it is simpler that way.

Allowing multiple copies of DBMON to run might be amusing, put not particularly
useful.  As I originally wrote it, the messages were distributed randomly among
the DBMON instances or be garbled.  I added a check for ERROR_ALREADY_EXISTS so
it won't run twice.  The worst you can do to the client is cause it to print a
message on the kernel debugger, as above.

If DBMON is broken and never calls SetEvent(AckEvent), it will cause a 10
second delay in the client every time OutputDebugString is called, then the
message will be printed on the kernel debugger.

OutputDebugString will force synchronization of client threads when DBMON is
running.  Letting the kernel debugger catch the strings will also synchronize
threads, but the timing effects may be different.  Caveat emptor.

In a GUI version of DBMON, use MsgWaitForMultipleObjects.