- the regular expressions of the filters are PCRE2 instead of std::regex: lookbehind works,
(?<=id=)\d+highlights only the number afterid=(fixes #411), and so do lookahead, named groups and possessive quantifiers. Filtering is about 3 times faster (150000 lines in 60 ms instead of 200 ms). A pattern that backtracks without end no longer freezes the window, it counts as 'no match'. Patterns are written as before, except for the rare differences between the two syntaxes (an invalid pattern is reported when you press OK in the filter dialog, with the position of the problem), see the PCRE2 syntax. Highlighting of token filters is case insensitive like the filter itself. - fixed: after 'Reset View to this line' the offset time (the Time column when it does not show the clock time) is relative to that line, it starts at 0.000000 again (fixes #282)
- boost is no longer used: the build does not download it any more, the unit tests use GoogleTest (fetched by CMake when it configures)
- the configuration (.dbconf) and the filter files are saved as JSON. Files of older versions (XML) are still read: they are converted when loaded and the old file is kept as
.archived - fixed: the window froze while a large amount of debug output was received (2 million lines took 30 seconds), it responds immediately now
- fixed: 'DebugViewConsole -u' crashed, it sends a default test message now
- releases are made with utils/release.py (clean build, git tag, zip and GitHub release), see the top of the script
- the whole message is shown in a tooltip when hovering the message column (fixes #372)
- dropping an empty file on the window no longer fails, it is tailed until content appears.
- Copy View is faster for a large log: when the filters are not changed in the dialog, the lines of the view are copied instead of filtering the whole log buffer again (fixes #284)
- changes of the filters of a view can be undone with Ctrl+Z and redone with Ctrl+Y (or Ctrl+Shift+Z) while the log has the focus, also in the View menu: adding a filter with Ctrl+E, Ctrl+I, Ctrl+H, Ctrl+K, excluding lines, adding process filters and the filter dialog (fixes #278)
- documentation: Views, filters and the log buffer explains what a view is, how filters apply to views (not to the memory buffer), and how reset view, reset to line and clear view work (fixes #316)
- new: dark theme (Options, Dark Theme) for the log: dark background, text, selection and match colors, dark header and scrollbars and a dark title bar. It is remembered between runs. The menu, toolbar and status bar are drawn by Windows and keep their colors (fixes #368)
- DebugView++ is per-monitor DPI aware: on a monitor with scaling (125%, 150%, ...) it is no longer stretched (blurry) by Windows, the font and columns are scaled and are scaled again when the window is moved to another monitor (fixes #321). The toolbar icons are not scaled yet.
- the history size (Log, History...) works: the oldest messages are removed when there are more, in blocks of 400, and the setting is remembered between runs (fixes #409)
- pressing Enter in the log view sends an Enter to the stdin of the processes that DebugView++ is running (for batch files with 'pause', or programs that wait for Enter), (fixes #293)
- the width and order of the columns, as changed by the user, are saved in the dbconf (and in the settings) and are kept when columns are shown or hidden (fixes #346)
- DebugViewConsole (and DebugView++) can run as a windows service: in session 0 the global DBWIN_BUFFER is the same as the local one, so no second reader is created (fixes #349)
- the status bar shows 'Searching', 'Found' or 'Not found' for the text being searched, as soon as the search starts and ends (fixes #366)
- the commandline of a process is logged with its 'has terminated' message (fixes #401), this needs Windows 8.1 or later.
- new commandline argument /delay: to deliberately slow down every process that calls OutputDebugString (fixes #400)
- new: UTF-8 messages are decoded properly (falling back to the ANSI code page for invalid UTF-8) and a leading UTF-8 BOM is stripped, contributed by Shan Zhou (#425)
- fixed #415: lines longer than ~2340 characters were invisible (GDI cannot draw text wider than 32767 pixels), selecting text in such lines works too.
- fixed #301: loading a DebugView++ logfile no longer replaces the process names with the filename.
- kernel messages: the driver is now loaded with NtLoadDriver and is placed in System32\drivers (it was System32\driver), a different driver file is replaced, and failures give a clear error message, thanks to x64bugreport (#413).
- kernel messages: fixed lost messages caused by the 1Hz poll rate and stale capture state on start/stop, contributed by Jiahe Wang.
- fixed wildcard filters: '?' matches exactly one character instead of also matching nothing.
- fixed a crash when a tailed file disappears or is rotated.
- fixed lines from tailed Sysinternals and DebugView++ logfiles occasionally being parsed as plain text (a race when the file reader started).
- fixed an out-of-bounds read when receiving a short message from a Dbgview agent.
- fixed a data race between adding/removing log sources and processing messages, and a process handle leak for messages of removed sources.
- fixed timestamps going back a day after midnight in Sysinternals logfiles saved in a US region format, which also failed for logs spanning more than a month.
- more reliable tests (tailing tests no longer depend on fixed sleeps), contributed by Shan Zhou; stricter Str()/WStr() conversions that no longer print a pointer instead of text.
- build: all compiler and linker warnings are errors now, third party headers are included as SYSTEM, vscode settings and recommended extensions were added, and CI was updated.
- bugfix: every 5000th line was not visible in the viewer (thanks to roman-orekhov for reporting and reproducing)
- bugfix: unicode message were messed up (depending on windows utf-8 settings)
- new features: capture kernel messages, verbose mode and pass-through mode, big thanks to x64bugreport and 593749519 for providing information, contributions and test scenarios.
- fixed #365: support for messages from UWP applications (poorly tested), feedback welcome!
- fixed #396: depending on the runtime dlls, this broke when we moved to cmake, now we link the runtime statically again.
- fixed title bar not being updated when 'Global Win32' was toggled.
- new commandline argument /tab: to select a tab that get focus at startup, contributed by KirisameMarisa
- removed color support from 'include' filter by request (a highlight filter can still achieve the same result), contributed by Ishmaeel.
- faster building by adding /MP.
-- Notice:
- This project is in low-maintenance mode, this means new features are only added if PRs are provided with tests.
- Updates are limited to keeping the status-quo and OS-related updated.
- I'm looking for maintainers, so if you would like to join me in bugfixing or adding features, please let me know.
- 2022 update: The project was migrated to VS2022 and boost 1.80, WindowsXP (32 bit) support was removed.
- the OutputForwarder companion extension for VS2022 can be found in the Visual Studio Marketplace
- nuget.exe can be downloaded from https://www.nuget.org/downloads
Download latest release, I would really like to hear what you think! Leave any comments here
Download head version ** only pick this if your feeling lucky and want to try the latest commits **
Questions? Find me at @janwilmans.bsky.social or chat on discord as 'janwilmans'. There is also a slack channel. If you need an invite, go here.
Debugview++ started as a viewer for Win32 OutputDebugString messages in the style of Sysinternals DebugView. However, it can now be attached to virtually any other kind of logging, such as:
- tailing ascii and UTF logfiles (just drag it onto the window)
- Android ADB (or any console based standard output)
- serial ports (using plink)
- sockets, telnet or ssh ports (also using plink)
- it can listen for UDP messages, handy in distributed systems
See examples down below.
This project is sponsored by:
Build in code analysis, handy auto-fixes and refactoring options
Gather and analyse crash information.
We use Incredibuild to make use of all cores of multiple machines to accelerate building our C++ projects.
- first of all, with debugview++ you can see messages from different processes, not just 'attached' processes.
- also: filtering, coloring and linking. To make sense of a large amount of information humans need to filter it or order it understand it. Also it helps if important events have different colors to quickly interpret the occurring patterns.
- finally, filtering is nice, but sometimes you need to see a line in its context to understand it, this is where linked views can help to quickly switch between a fully filtered view and a fully detailed view.
New in stable version 1.8.x:
- bugfixes (namely in file-tailing)
- tested on windows 10
- last version with (official) XP support (v141_xp target)
- internal refactoring from boost to C++11/14 constructs
- better commandline support using docopt.cpp
- added filtering command line options
- no other new features planned, if you're missing something you need, file an issue!
Features we dream about and will create when we choose to spend the time:
- a gantt chart-like view, a horizontal timeline, with bars/flags/signs on it to identify events
- a better plugin based input system
- transparent background streaming to disk
- proper memory limits
Known issues:
- the history limit doesn't work right, this is troublesome for long-running duration-tests. A workaround is to send 'DBGVIEWCLEAR' before each test-cycle (this clears all logs from memory).
- there is no 'pass-through' mode like the original dbgview had, if you can help me implement this, please contact me.
- same goes for catching kernel messages, help wanted.
Here are some features:
- single selfcontaining executable, setup is provided but not required
- minimal delay of the traced application, compared to the original dbgview a factor of 10 better.
- fast and responsive user-interface, even with +50.000 incoming lines per second
- runs without prerequisites on WinXPSP3 and up (v1.5 and earlier also on WinXPSP2)
- in-memory compressed logbuffer using google snappy (typically -50% RAM consumption)
- tailing files (drag ascii or UTF files into debugview to tail it)
And more features:
- capture both Win32 and Global Win32 messages
- tabbed views
- resolve process PID to name and track their lifetime
- filter by process or message
- advanced filtering, exclude, track, stop, clear (optionally using regular expressions)
- line and token highlighting (create your own syntax highlighting)
- SAIT (search-as-I-type) + token highlighting
- bookmarks
- statusbar shows detailed log/view/selection information
- open saved logs for post-mortem analysis
- commandline version
- capture stdin piped messages, allows you to connect any kind of logging
- beep-filter for monitoring without seeing the screen (To hear it make sure a 'Default Beep' sound is defined in Control Panel->Sounds)
- clear Log now releases the message buffer instead of reusing the memory (useful when running debugview for a very long time)
- tailing logfiles over samba network (experimental)
- support for reading and tailing Sysinternals Dbgview logfiles (in the four most common formats)
- socket listening, Log->Sources->Add can add TCP and UDP listeners, the protocol is sending raw newline terminated strings. Multiple lines can be send in one packet.
- dbgview agent client mode allowing logging of kernel messages
- timezone independent and human readable timestamps in the logfiles
- add basic support for unicode, UTF-8 via OutputDebugString and both UTF8 and UTF16 with BOMs when reading files
- View->Process Colors, easy way to give every process its own color!
- Options->Link views, best effort to synchronize the line-selection over all views
Screenshot demonstrating bookmarks and highlighting features.
Highlighted:
- regex (token filter):
[^\s]*\\[\\\w+\.\s]+filenames in blue - regex (token filter):
0x\w+hexadecimal numbers in red - regex (highlight filter):
Unittestlines with the word 'Unittest' have a lightgreen background - a doubleclick on 'bytes' causes all instances of 'bytes' to highlight in yellow
See https://www.pcre.org/current/doc/html/pcre2syntax.html for all options for supported regular expressions (PCRE2: lookbehind, lookahead, named groups, ...)
Android ADB example:
Screenshot demonstrating connecting to ADB logcat (Android Debug Bridge)
Connect any pipe:
To connect directly to a port or service, plink can be used, make sure an instance of debugview++ is already running before running this command:
plink -ssh -batch -v 192.168.0.1 2>&1 | debugview++
Notice that 2>&1 is used before the pipe (|) symbol to redirect stderr to stdout.
Connect to sysinternals dbgview agent for kernel messages:
Example: connect to sysinternals DbgView Agent, first start Dbgview.exe /a /k (/k for kernel messages) And connect DebugView++ using Log->Connect DebugView Agent. Note that 'Log->Connect DebugView Agent' assumes the agent is running on the same workstation as DebugView++ so it connects to 127.0.0.1. If you need to connect to a remote agent, use Log->Sources...->Add->DbgView Agent and fill in the ip-address.
Use RegexGroups + Token Highlighting:
Suppose you want to highlight some data value in your logging, since the actually value may differ, you cannot use normal matching to highlight them. With RegexGroups you can match text before or _after the actual token you want to highlight.
Example:
Filters can be defined per view, for example choose File -> New View, and the filter dialog will popup. Filters decide what a view shows, they do not change what is stored, see Views, filters and the log buffer. Pressing OK will open a new view without any filters.
Different types of filters:
All filters support regular expressions, if you are not familiar with regular expressions you can just type any word or part of a word to match.
- include: if an include filter is added only lines containing a matching expression will be included.
- exclude: lines containing a matching expression will be excluded from the view, excluding always takes precedence over including
- once: only the first line containing a matching expression will be included, this resets automatically at 'clear view'.
- highlight: lines containing a matching expression will be highlighted using the specified foreground and background colors
- token: only the matching expression will be highlighted using the specified foreground and background colors
- track: lines containing a matching expression will be focused and centered if possible. Note: auto scroll turns off if a track filter is matched
- stop: if a matching expression is found autoscroll is turned off, all track filters will be disabled and the line is focused. Note: stop filters work only if autoscroll is on, think of a stop-filter as a single-shot track filter
- beep: a standard windows beep (configurable in config panel->sounds) is played
Practical uses:
Include, exclude, once and highlight filters are the most intuitive filters to use. Track and stop can be a little confusing, let me try to give some examples.
track: use this filter to focus interesting lines that do not occur very often, but at a regular interval, for example, so you are monitoring a process that logs output every 30 seconds and you need to check the result.
stop: this filter is good when some special event occurs (an exception?) and you want to inspect the context of the event in the log before continuing. A press of the 'end' button will resume auto scrolling.
views: every tab is a view on one shared log buffer, filters apply to the view and never remove a message from the buffer. See Views, filters and the log buffer for how this works and for examples.
- reset view; make the first line in the logbuffer the first line in the view
- reset view to this line; make the current like the first line in the view
- clear view; make next incoming message the first line in the view
- clear log (Log menu); remove all messages from the log buffer, in all views
link views: the selected line in the current view is located re-selected when you switch to another view. This is done on a best-effort bases, so if the exact line is not found, the nearest line is selected. In that case switching views will cause the currently selected line to change.
Consider this use case:
If you want to have auto scroll on, but some high frequency messages are annoying you, but you cannot exclude them because they help you diagnose your event when it occurs, try this:
Use two views, one where the diagnostic messages are filtered and autoscroll is on, and one where the messages are included (and maybe highlighted), next turn on the 'link views' feature.
Now you can monitor the filtered view, and when your event occurs, select a line and switch to the unfiltered view, the same line is now highlighted, but in full unfiltered context.
process colors: If enabled each process (even processed with identical names) will get a its own background color automatically without adding any filters.
Auto Scroll: scrolls down to new incoming lines automatically
Auto Scroll Stop: If enabled 'auto scroll' is turned on when the last line in the view is selected, and also turned off if any other line is selected.
Bookmarks: bookmarks are view specific and can be placed on a line by clicking left of the line number or Ctrl+F2, press F2 to move to the next bookmark. Bookmarks are temporary, so cannot be saved.
ClockTime: when enabled the time is displayed as provided by the system's real-time clock (RTC). Such a timestamp has a 16ms resolution on a typical desktop PC. When disabled, time is displayed as a relative time to the first message, however this timestamp is obtained from the High-Performance Counter (HPC) which typically has a sub-microsecond resolution.
The resolution should not be confused with accuracy here, the recorded timestamp is not the actual time the message occurred, it is the time the message was received by DebugView++. Also there is no guarantee that the time between occurrence and reception of messages is constant, however in practice this is pretty constant :)
This project has a special configuration:
- 32bit debug/release configurations are targeted to v140_XP, SDK v7.0 (windows XP SP3 and up)
- 64bit debug/release configurations are targeted to v141, SDK v8.1 (runs on windows 7 and up)
- only the release configurations also build the Wix installer
The projects are configured to use Nuget to get there dependencies (WTL and Snappy). The unit tests use GoogleTest, CMake downloads it when it configures the project (a release tag, pinned in CMakeLists.txt), so the first configure needs internet access. nlohmann/json, pugixml and PCRE2 are included in application/Libraries. However, to build the installer you have to install Wix Toolset manually
ctest -C Release --output-on-failure in the build directory runs the two test programs. A single test can be run with
bin\DebugviewppTest.exe --gtest_filter=*LogSourceLoopback*, --gtest_list_tests lists them. The tests that read the debug output
(DBWIN_BUFFER) share a buffer with the whole machine, so they can fail when another program is writing debug output at the same moment.
git clone --recurse-submodules https://github.com/CobaltFusion/DebugViewPP.git
(don't forget to include --recurse-submodules, otherwise you will get an error message saying docopt.h is missing.) You press 'build' and visual studio will download WTL the first time only and then build the project. It is as simple as that... if it is not, contact me (jan), so I can fix any remaining issues.
Since we use ATL and support Windows XP still some extra installation options are required, verify that the following option are installed:
- zip.exe, http://gnuwin32.sourceforge.net/packages/zip.htm, choose [zip-3.0-setup.exe] decompress the archive and you're done (add zip.exe to the path)
There are known issues with compilation using Visual Studio 2019 16.10.x (preview at March 11, 2021).
-= Cobalt Fusion =-
Jan Wilmans mailto:janwilmans at gmail.com
Gert-Jan de Vos mailto:boosttestui@on.nl