2

Here's my scenario: I have a program which produces debug output with OutputDebugString() which maybe contains messages indicating bugs. I want to run this program inside daily build and automatically listen to debug output, parse it and report suspicious output.

There're several examples of such listener implementations, for example this one. They all do the same - listen to a system-wide event and then read data from a file mapping. The problem is this protocol allows for only one instance of the listener - whoever grabs the event first is the only one to access the output.

Same with DebugView program. If I have an instance running then starting another instance yields a "disconnected" instance and it will fail to "connect local".

The daily build runs multiple programs simultaneously and so I want to be able to run several instances of this listener and have each only listen to a specific program. Looks live Visual Studio can do that - when I start a program under Visual Studio I only see the debug output from that very program, not from others and I can also run several instances of Visual Studio and debug a program it each of them at the same time

Is it possible to run several instances of program equivalent to DebugView such that each instances only listens to a specific program being observed and instances don't interfere with each other?

sharptooth
  • 167,383
  • 100
  • 513
  • 979
  • *looks live Visual Studio can do that* - you mistake. debugger got notifications via `DBG_PRINTEXCEPTION_C` and `DBG_PRINTEXCEPTION_WIDE_C` exception. *Is it possible to run several instances..* - no not possible - exist only single section, event, etc. so will be data race – RbMm Oct 14 '19 at 10:19
  • You can write a debugger, run your app under it, and get notifications just like VS does. It's not trivial to do but not rocket surgery either. – 500 - Internal Server Error Oct 14 '19 at 10:21
  • One instance can capture debug output from multiple programs you can distinguish them from process id. So one is enough.? – Rita Han Oct 15 '19 at 06:49
  • It would be much more convenient to just start an instance of listener for each program of interest. – sharptooth Oct 15 '19 at 08:28
  • 1
    @500-InternalServerError Thank you. I followed your hint and it was much easier than I would expect. I wrote a digest as an answer. – sharptooth Oct 17 '19 at 08:04

1 Answers1

3

I followed the hint given by user 500 - Internal Server Error in the comments and tried the "pretend Visual Studio" way. It's very close to "hold my beer" difficulty level (but I have 10+ years of WinAPI software development experience). The whole thing took several hours and the implementation is less than 200 lines of C++ code including some bulky code for calling WinAPI functions and the code which filters the output and reports suspicious items in a usable way.

The fun part is that I used Visual Studio to write and debug the code - Visual Studio was acting as debugger for my program being developed and the program being developed was acting as debugger to the program which was producing curious debug output and this chain works just fine.

Here's a good tutorial to get the idea and some inspiration: Writing a basic Windows debugger This is an MSDN explanation of how to write a debugger main loop: Writing the Debugger's Main Loop.

This is how it works:

  1. Start the program you want to process debug output from using CreateProcess() and passing DEBUG_ONLY_THIS_PROCESS flag. This starts the program suspended and in "being debugged" mode.
  2. Run an infinite loop and call WaitForDebugEvent() on each iteration. Calling WaitForDebugEvent() resumes the suspended program and allows it to run until the next debug event happens.
  3. Process OUTPUT_DEBUG_STRING_EVENT, use ReadProcessMemory() to copy the string from the process being debugged, process the string as you see fit.
  4. Also process EXIT_PROCESS_DEBUG_EVENT - it means the process being debugged exited and you likely want to end the loop.
  5. Also process EXCEPTION_DEBUG_EVENT - when EXCEPTION_DEBUG_INFO.dwFirstChance is zero you have to terminate the process being debugged using TerminateProcess() otherwise you'll get an inconvenient "the program has stopped working" dialog from Windows
  6. Call ContinueDebugEvent() at the end of loop iteration, pass DBG_EXCEPTION_NOT_HANDLED.

That's all. Yes, now you can claim you have experience writing a debugger.

sharptooth
  • 167,383
  • 100
  • 513
  • 979