windows-server-2003/sdktools/dbmon

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.