0

I'd like to extend my application with a kind of logging, where one can choose to log to a file and/or to log to the "Visual Studio" "output" window.

For the latter, it seems that the function OutputDebugString() is doing the trick, but only for "Debug" builds, and I'd wish to have this also for "Release" builds, so I came up with the idea of using tracepoints (at least, I think that tracepoints are also writing to the "output" window for "release" builds), but here I have a rather frustrating problem:
Tracepoints are a special kind of breakpoints and seem to be written to *.suo files, being present in <project directory>\.vs\<project name>\v15 directory (see Where are Visual Studio breakpoints saved?., thank you, Max).
My idea was to write a postbuild event, adding a tracepoint to every line in the *.suo file where a log() operation was called.

This, however, is not possible, for the simple reason that the *.suo files are binary :-(

Does anybody know of another way to add tracepoints to an application at build-time or how to write (with a "Debug"/"Release" switch) to the "output" window of Visual Studio?

Thanks in advance

Dominique
  • 16,450
  • 15
  • 56
  • 112

1 Answers1

0

OutputDebugString() should work in Release builds - if there is anything to consume the output (such as WinDbg.) Debugging Tools for Windows (WinDbg, KD, CDB, NTSD) As to why it's not - probably want to look into that, as it's possible your application isn't building quite the way you expect otherwise.

As I understand it, Tracepoints only work in a debugger (Debug or Release) - but the way I believe this works is, the debugger will, on application load/startup, (or during a run) actually replace instructions with a BRK and when the application triggers the break, the debugger catches it, substitutesthe original instruction back in, before performing whatever task it should (whether that be pause, increment a counter, etc.) - but I think Tracepoints will only work with an attached debugger, as otherwise there's nothing to perform the replace, catch and substitute operations, and the code runs uninterrupted.

However, if I read your intentions correctly, you might actually want to use something like Event Tracing* instead. This should output what you want to see to a standard windows log file, will work in debug or release, inside or outside of a debugger. However it won't output to the VS output window. For that, OutputDebugString() should the be correct operation.

*Disclaimer - not used them myself, as we use VS output and WinDbg for now - but it looks like a better way for deployed applications, going forwards.

Rags
  • 311
  • 1
  • 7