Principle and simulated source code of outputdebugstring

When debugging some programs, print them with outputdebugstring, and print them with debugview output, for example, a Windows service program. However, debugview outputs printed information of any Windows software program, such as thunder and flashget. Although debugview provides the output filtering function, it is inconvenient to filter the output every time,

So I want to simulate and implement the outputdebugstring function myself, and then write a corresponding debugview to print the output, so that I can print the outputdebugstring and use my debugview to print the output.

Myoutputdebugstring of the Lib interface I encapsulated and the corresponding mydebugview:

Http://download.csdn.net/user/woshiyipihaoma

 

Someone has done some research on the outputdebugstring principle on the Internet. I am here to show them, And I Will repost them below.

Data is transmitted between the application and the debugger through a 4 kb shared memory block, and there is a mutex and two event objects to protect access to them. The following are four kernel objects:

Object Name	Object Type
Dbwinmutex	Mutex
Dbwin_buffer	Section (shared memory)
Dbwin_buffer_ready	Event
Dbwin_data_ready	Event

Mutex is usually kept in the system, and the other three objects only appear when the debugger wants to receive information. In fact, if a debugger finds that the last three objects already exist, it will refuse to run.

When dbwin_buffer appears, it is organized into the following structure. The process ID displays the source of information, and the string data is filled with the remaining 4 K. According to the Conventions, the end of the informationAlwaysContains a NULL byte.

struct dbwin_buffer {                DWORD   dwProcessId;                char    data[4096-sizeof(DWORD)];                };                

WhenOutputdebugstring ()When the application is called, it performs the following steps. Note that errors at any location will discard the entire process and the debugging request will be considered as nothing (no strings will be sent ).

1. OpenDbwinmutexAnd wait until we have obtained exclusive access.
2. IngDbwin_bufferSegment to memory: If not found, no debugger is running and the entire request is ignored.
3. OpenDbwin_buffer_readyAndDbwin_data_readyEvent object. Like shared memory segments, the absence of objects means that no debugger is available.
4. WaitDbwin_buffer_readyThe event object is in a signal state, indicating that the memory buffer is no longer occupied. Most of the time, this event object is in a signal state as soon as it is checked, but wait for the buffer to be ready for no more than 10 seconds (timeout will discard the request ).
5. Copy the data until the memory buffer is close to 4 kb, and then save the current process ID. Always place a NULL byte to the end of the string.
6. SetDbwin_data_readyThe event object tells the debugger that the buffer is ready. The debugger removes it from there.
7. Release mutex.
8. Close the event object and segment object, but retain the mutex handle for future use.

It is easier on the debugger. Mutex is not required at all. If the event object and/or shared memory object already exist, it is assumed that other debuggers are already running. The system can only have one debugger at any time.

1. Create shared memory segments and two event objects. If it fails, exit.
2. SetDbwin_buffer_readyEvent object, the application knows that the buffer zone is available.
3. WaitDbwin_data_readyThe event object changes to a signal state.
4. Extract the string ending with the process ID and null from the memory buffer.
5. Go to step 2.

This makes us think that this is by no means a low-consumption Method for sending information, and the running speed of the application will be affected by the debugger.