Feedback on Debugview++
janwilmans opened this issue · 58 comments
- Do you use debugview++ and it works for you? Please leave a comment in this issue.
- Do you have a problem using it, a question or request, just leave a comment here too...
(or if you think it is a bug, please just submit a new issue!)
Love it! Use it nearly every day without any complaint yet and it works llike a flaw. I don't have feature requests ATM.
No issues so far, but I haven't had a lot of opportunities to use it at home or work. The last time I used it at work, it was a drop-in replacement for the original DebugView as a basic test. No additional features were really tested.
BUT, it did have less processing overhead than its precessor, especially while printing a lot verbose/information-level statements WITH the application running! There was not a noticeable application slow-down like before!
I'm looking to contribute here in the next couple of weeks. Been busy.
It's definitely better than it's precessor! Glad to see this repository is sponsored by JetBrains!
Keep up the good work!
SteeleDynamics: very interested in your contributions, what are you thinking of ?
For the console version, DebugViewConsole.exe, I got:
"DebugViewConsole 1.8.0.7 Neither output to logfile or console was specified, noting to do..."
-
"noting to do" should be "nothing to do"
-
I guessed I could use "-h" to list information about the command-line parameters. I suggest including information about "-h" in that fixed text output, e.g. like command "cp" on Unix, something like "Try `DebugViewConsole -h' for more information.".
@PeterMortensen I created #310 for first issue :)
On Windows XP 64-bit (really Windows Server 2008 in disguise) I get (I have closed the old DebugView, Visual Studio, etc.):
2017-10-17T16:36:01.35 T:\toDelete\2017-10-12\DebugViewPP\Debugview++ 1.8.07 - 32 bit version> DebugViewConsole.exe -c -p
DebugViewConsole 1.8.0.7
Listening for OutputDebugString messages...
Unexpected error occurred: CreateDBWinBufferMapping
Another DebugView++ (or similar application) might be running.
The same works on a Windows 7 64-bit system:
17-10-2017T16:22:01,60 C:\TEMP3\Debugview++ 1.8.07 - 32 bit version> DebugViewConsole.exe -c -p
DebugViewConsole 1.8.0.7
Listening for OutputDebugString messages...
1440 16:22:09.472. Error frame group #9912 on CAN 1. CAN time: 1544.542142
1440 16:22:09.481. Error frame group #9986 on CAN 1_ALL. CAN time: 2364.603400
1440 16:22:11.502. Error frame group #9913 on CAN 1. CAN time: 1546.647072
1440 16:22:11.512. Error frame group #9987 on CAN 1_ALL. CAN time: 2366.708329
1440 16:22:13.530. Error frame group #9914 on CAN 1. CAN time: 1548.752027
Process ended normally.
I would like to try v1.5, but the download links are broken (near "Download old version (stable, dated 20 Sept 2015)", on page https://github.com/CobaltFusion/DebugViewPP).
Perhaps "Another DebugView++ (or similar application) might be running." should be augmented with this possibility (running on Windows XP or whatever it is that may prevent it from working on such a system)?
Its very likely related to the debug-rights granted to the account you are running in, you can try 'run as administrator' or similar things. Or granting debug right permanently to the account. The simplest way to do that is probably to add the user to the admin group, but there may also be subtler/more specific ways. Let me know if this helps.
So v. 1.8 is supposed to work on Windows Server 2008 / Windows XP 64-bit? I thought the last working version was v. 1.5 (or is that only for Windows XP 32-bit)? Or an SP2 vs. SP3 issue? I use SP2 (yes, I know it is out of date, but now it is probably too late to upgrade).
I am logged in as administrator on the Windows XP 64-bit system. I have used Visual Studio there for many years for developing .NET applications.
I have also tried to restart the computer, but it gave the same result.
I would like to try v. 1.5, but the download links are broken.
It took some more time than I anticipated, but the v1.5 links at back up. Let me know what you find.
Sorry for the late response.
With the v. 1.5 of DebugViewConsole.exe (installed by the installer) I get the same result.
But two of the GUI versions work for capturing the debug output (but not for the programmatic access I am after), both v. 1.5 (32-bit) and v. 1.8.07 (32-bit), though the v. 1.5 version complains at startup with "Unable to capture Global Win32 Messages. Make sure you have appropriate permissions. You may need to start this application by right-clicking it and selecting 'Run As Administator' even if you have administrator rights.". They both do capture the debug output from my .NET application. (The 64-bit version, v. 1.8.07, does not start at all ("DebugView++.exe is not a valid Win32 application"), which is probably not surprising(?)).
Why would there be a difference between the command-line version and the GUI version? Aren't they more or less doing the same thing (shared code) for the initialisation part (handles \DBWIN_BUFFER, \DBWIN_BUFFER_READY, etc.)?
I have tried to fiddle with permissions, using RunAs, etc., but the results are inconclusive at this point. Stay tuned.
Try https://github.com/CobaltFusion/DebugViewPP/releases/download/1.8.0.7/DebugViewConsole.exe
(not the one from the zip, this links is actual file, it might fix your issue, let me know if it does not...)
Sorry for the late reply.
It works!!! Thank you very much.
What did you change?
I was always trying to open to Global\DBWIN_BUFFER but on windows xp that is not a valid file-descriptor.
However, the API method does not tell me that (it returns ok, even though it is not actually valid)
Now I worked around that by detecting the windows version and not even trying to open it. see 2b4aae0
Hello!
Does the log window support the UTF-8 or UTF-16 encoding? When I use the C#'s Debug.WriteLine() method with "special" characters (like α, β, °, etc) the log window is unable to display it correctly (question mark is displayed instead).
Well, I have never used those symbols specifically, but I recently tested chinese Unicode chars and that works very well now. I would welcome a failing test.
Feature request: Right-click filter option for "literal" process name and message. Basically a similar feature that procmon.exe or event log explorer has. It makes filtering out garbage much smoother.
@techtim2003 thanks for you suggestion, I'd like to make sure I understand correctly: you would like to filter by the full name of the process and the full message in one filter entry? I have spend a lot of time to make the filters understandable by humans :) and I'm having a hard time thinking what that would look like in the filter UI without creating a mess.
I simpler solution may to include the name of the process, or even the PID in the message, would that solve you case? (I personally always really disliked that about dbgview, but if its useful I could bring that back as an option?)
Just wanted to drop a line and say thank you for the highly improved DebugView, I've used it in the past and now have need of it again and it's so much better.
Congratulations on a fine product. I use it all the time. There is one thing that irks me (it's not the fault of DebugView++). I develop in Delphi. If I run a compiled app, my OutputDebugString lines go to DebugView++. All good. If I run my program from the IDE, the ODS output goes to the Delphi IDE Event Log, which has none of the filtering or highlighting abilities that DebugView++ has. AKAICT, there is no easy way or persuading Delphi to ignore ODS output and let it go to DebugView++ (well, there is - you can tell Delphi IDE to run the program without debugging - but if you do that, you lose the ability to set breakpoints, inspect variables and the call stack etc.).
I figure a way around this is to modify the app I am developing to spit the ODS output directly to DebugView++ - i.e. not call ODS, but instead call another routine that talks directly to a running instance of DebugView++.
What abilities does DebugView++ have that might help me to implement this?
- So the easiest way is this:
- first start debugview++ as usual
- pipe anything into another debugview++.exe instance, it will detect the pipe and instead of launching the UI, it will send anything from the pipe to the ODS api.
- another way is to use either TCP or UDP messages
This will cause debugview++ to start listening for messages on the specified port.
Here is an example of how to send UDP messages from your application (in c++):
https://github.com/CobaltFusion/DebugViewPP/blob/master/DbgMsgSrc/DbgMsgSrc.cpp#L277
I'm sure delphi has a component to do this as well.
Cool, thanks for that. I'll investigate when I've put out the fire...
Actually, I don't see how the first example using pipes would work in my situation. So, I would be running my app in the Delphi IDE - would I continue to call ODS as normal? I can't see how that would work. If I added the ability in my app to call the UDP message instead of Win ODS, I can see how that would work, but I can't see how running my app under the IDE could be made to provide anything that could be piped - or are you suggesting that my app would spit stuff out to the console instead of calling ODS?
If I were to use UDP, presumably the instance of DebugView++ would only display those messages from my app - or would it also grab standard ODS calls from other applications as well?
FYI: On current Windows 10, the last few executables archived here trigger my Windows Defender with a report of "Trojan:Win32/Tiggre!plock" (category Severe, so Defender insists on quarantine). Tried 1.8.0.46, 1.8.0.44, 1.8.0.33, 64 and 32 bit versions. If it could matter, this is on a VM installation of Windows 10.
I just downloaded the 1.8.0.46 source and successfully built the executable, and Windows Defender sees no threat in the 64-bit executable I built.
Thanks for reporting mark! I've seen similar reports, such as #353, and I have tried really hard to work around it, but it seems the just 'importing'/ linking to any debug function in the win32 api is considered dangerous now. So I'm not sure what to do about it.
Glad you found that the x64 version seems unaffected!
@RrnR to get back to you: yes, I was suggesting that you write to the console from your app and re-direct that console to debugview++.. If that is unpractical, the UDP message solution might be preferable .
would it also grab standard ODS calls from other applications as well
yes, it would, but if that is annoying you, you can just filter those by process name.
Thanks, it would be great if you could provide a working Delphi example!
@jan, sorry for the unintended nudge. I mean, what are the chances of two people named "Jan" on the web? ;-)
I was pretty excited about the native ability to capture UDP messages. So far though, it looks like this isn't going to work for me. I have a couple of problems.
-
I have a test app that sends 1,000 UDP messages a second, and I see many drops. I also see that when things get busy DebugView++ randomly inserts blank lines for no reason. Just for a datapoint, if I capture the UDP messages with my python relay and instead issue them with OutputDebugString(), no messages are lost. So Windows can keep up, my output is not a problem, DebugView++ just doesn't seem to be able to keep up with rapid traffic.
-
I'd like to be able to disable OutputDebugString() traffic when using UDP, this doesn't seem possible, but it's also possible I have missed this in the docs.
I need to extract the test app from our production code, will try to get that done tomorrow.
Okay, I'm able to characterize the UDP problems pretty well - figuring it out proved interesting.
As it turns out, I was sending trace from a C++ program, and I was inadvertently including the null terminator in my UDP packet.
If you run this python script, sending 100K lines at full speed across the local network, DebugView++ reliably captures all packets.
However, if you uncomment the line that appends a null terminate, you'll see some crazy erratic behavior. It's almost like the lines are capture properly, but the rendering is going nuts.
Try this out, with and without the null terminator. This might work just as well if all the traffic is going through localhost, but I was going across the network:
from __future__ import print_function
import ctypes
import socket
import sys
sock = socket.socket(socket.AF_INET, # Internet
socket.SOCK_DGRAM) # UDP
for i in range(100000):
msg = "Hello, world {0}, testing 012345678901234567890123456789".format(i)
#msg = msg + chr(0)
sock.sendto(msg, ("10.57.42.250", 9000))
#
wow, that is super helpful! I think I'll be able to fix that :) I'll investigate it !
I tried to fix the loading of filter rules with broken regular expressions, but that is not easy. Its XML, I either load the whole thing, or not. The new edge cases that will arise from loading broken regex's and still continueing are not fun to deal with. How do you get into this situation in the first place? Debugview++ shouldn't allow you to save that file, so did you edit it manually ?
No, I haven't been editing directly the XML file. I had a quick look and can't see the text that is causing it to barf. I might be a bit more structured about it and try to isolate the filter concerned.
One point is that the folder where the XML files are located is within my Dropbox synced image, so I can have access to my filters both at home and at work, but I've never known Dropbox to damage a file.
I don't understand why the exception is occurring within the LoadXML routine? I would have thought the regexp at that stage is just treated as a string by the XML loader, and you would parse it with the regexp parser after the XML had been loaded.
Finally (!) did you see my request about avoiding the need to add the UDP address and port each time I start DebugView++?
OK more information. I've isolated the expression it doesn't like:
<Text>Error\:\ </Text>
<MatchType>Regex</MatchType>
<FilterType>Token</FilterType>
The curious thing is that I don't remember recently editing this filter and I'm sure it worked previously. The specific error is:
A bit of playing about (by directly editing the XML and then reloading the filters) has determined:
<Text>Error\:\ </Text> fails (both colon and space escaped)
<Text>Error:\ </Text> fails (only space escaped)
<Text>Error\: </Text> loads ok (only colon escaped)
<Text>Error: </Text> loads OK (neither escaped)
There is definitely something amiss. If I edit the XML so that there are no escaped characters in the regex (fourth line above), the filters load OK and the colon and space are both respected. It looks like neither colon or spaces need to be escaped. However, I can escape them (it's my experience that if you escape a character that doesn't need escaping, the regex just ignores the escaping). If I edit the filter in the dialog so that it reads:
"Error\:\ "
(ignore the quotes - they are just there to make it plain there is a trailing space) then the regex is correctly interpreted and the output lines are rendered as I would expect. If I save the filters and inspect the XML, the text is stored in exactly the same way as I entered it in the filters dialog - i.e. <Text>Error\:\ </Text>. If I try to load the filter by XML filename I get the exception.
The following will hopefully make it clearer. It doesn't behave as I would have expected.
Case 1
- I start DV++ and add a filter like the one above with both colon and space escaped. It renders the output correctly.
- I then close DV++, and open it again.
- The filters that were in effect when I closed DV++ are reloaded, including the one with both colon and space escaped, and it continues to render the output correctly.
Case 2
- If I start DV++ and add a filter like the one above with both colon and space escaped, it renders the output correctly.
- Save the filter to
foo.xml. - I then close DV++, and open it again.
- The filters that were in effect when I closed DV++ are reloaded, including the one with both colon and space escaped, and it continues to render the output correctly.
- [ ]I then load
foo.xml. The exception is reported.
This curious because I would have expected the code that loads the XML would be the same in both cases, yet only one case gives the exception. I'm thinking maybe a Unicode-type problem but I really don't know.
DV++ Version: 1.8.0.46
Hi Jan,
Any progress on these issues?
- the exception loading a filter with a trailing save in the regex, as described in my previous post.
- the ability to specify the UDB host and port on the DBV++ command line.
Many thanks,
R
Hi,
Been using DebugView and then DebugView++ for a long time. In recent builds the "clear log" hotkey was changed from Ctrl-X to Ctrl-Shift-X. Is there any way to make this combination configurable?
Thank you for excellent software!
Hi,
DebugView is a very useful tool, I’m using it daily, I really like it and very easy to use. I have even created an object class to handle the statements and the indentation on the screen in order to have a better formatted view of the code. I see the beginning the end easily of a procedure sentence, with the colour it talks to you, it even helps you to get ideas. Every section areas are colorized differently with beginning and end stacking as I mention with an indentation it really helps to narrow down a bug or logic that needs to be improved or solve. I’ve been using it daily in my programming for the past 15 years. Every time I program the window it is there waiting to receive messages from the program. It is stable. The DebugView sessions of a process vary from a few hundreds lines to around 450,000 lines.
I’ll like to know if there’s a way to save with the DebugView file the bookmarks we are making, if it does, how is it done? A suggestion about the find bar, it would be nice to have an history of our search taken from our prior past sessions. The issue that I’ve encountered there is one, it is usually on a DebugView session of more than 100,000 lines, after using a forward search and when we select the previous button for an above search the DebugView crash.
Thank you for the excellent software !
Thanks you all for your nice feedback! I will see what I can do to implement your suggestions, the only limitation is time. I try to look forward and work on http://debug.vision/ which is planned as a portable successor of debugview++.
Would any of you be interested to help implement the features? the commandline options are not to difficult, but it does require work.
Also, I consider crashes not acceptable, so if you could provide we with a reproduction scenario that works, that would be really helpful.
Hi Jan and RrnR,
It is very nice of you, responding that fast with insightful information. Well, I will try to apply what you are suggesting and letting you know. I will try out Debug.Vision.
To get you in the context, well the language that I’m using to program presently, for the past 31 years, that I still enjoy using, are database’s applications created in Clarion. The way I work is a mixture between the Clarion IDE visual designer and source code programming mostly class object oriented. DebugView is a great tool to follow all these object classes, and source code generated to screen.
Furthermore, to implement DebugView, I have created in Clarion an object class called jcDebugManager and its template integrated in the Clarion IDE to enable and disable the generated code that will display or not to DebugView. As for the result, when I look at the DebugView as I mention in preceding post, I can see the colorized code and the indentation of the logic that I’ve written. Watching at the screen the structure within the program like if I was looking through the code itself with the results, which is great. And more, the way it is formatted and written from within the editor. This permits me easily to understand what I’m programming and see where I can make an improvement over the sources.
Over the years, I found out, there are a lot of DebugView statements that I want; it can be messy between the real code and the DebugView statements. For readability, it would have been nice to get the code in and out when needed. When done manually I don’t want to remove those statements because it is so useful. With that in mind, for the other part, from within the IDE through the jcDebugManager template by turning the code generation on or off; I can effortlessly generate or not the DebugView statements. Other reasons why, when the program is done with implementing all these DebugView statements, as for the result, it is hard to read. I have to make a distinction between the real code statements and DebugView statements; I can get easily lost. Moreover, we do not need all these DebugView statements on the final version. When I program the object class manually most of the time, I keep the DebugView statements of what I’ve done with the jcDebugManager object. So to enable and disable these keep statements, I have a variable that handles a switch to turn it on or off the view to screen; this, without removing the DebugView statements from the program. From the IDE, it is another story; with the jcDebugManager template, I can remove totally the DebugView code statements from the source code program as well as implementing the variable to turn on and off DebugView.
Regarding the crash, to put you in context, it happens only on a large file when the program has just run, with the program process checked and doing the search next and pressing the previous buttons, it crashes. I have tried after with the same file with the DebugView the program did not crash everything went well. The difference between the two, one has a program process check and the other one none. I think it must have something to do with the process checked.
While talking about the process tabs another idea, it will be nice to add process sessions and a button to clear all the processes instead of doing it one by one. I’m sending in the file attachment, the DebugView file and the filter settings.
Meanwhile is there a way for us to contribute. You are doing a great job; it is such a useful tool, and you have made a considerable improvement to the DebugView.
Thanks again and have a great day,
Joliciel
Hi.
I am running into an issue that could be configuration, but not certain. I am using the 64 bit version 1.8.0.86. When I load a log file to review at a later date, the logged "process" has been replaced with the log's filename. This prevents me from filtering a lot of noise out from processes I do not care about. If I view the .dblog in a text editor, it does look like the process name is there for each log entry. What am I doing wrong?
Here is a snippet from the raw log:
0.000000 2020/01/28 10:08:45.758 7128 devenv.exe Informational: ---------- Run started ----------
And what it shows up as in DVPP:
1 10:08:45.758 7128 2020-01-28 Std Tests.dblog Informational: ---------- Run started ----------
"2020-01-28 Std Tests.dblog" is in the process col but is the name of the log file.
DVPP is a great tool - thanks for all the hard work!
I use DebugView++ practically every day as I am working :-)
I attached a sample of emitting telemetry and observing it in DebugView++. As you can possibly tell the telemetry has a format that emits multiple lines as a single record with a JSON payload.
I have a question and a thought:
a) In looking through the source it looks like, but I am not certain, the output could be processed as messages rather than lines. That would allow filtering by message (fabulous) rather than by line (inside a message).
b) I often, and we've talked about this before, redirect console-streams with Ansi TTY sequences. Those are easy enough to detect and filter while ingesting a message. But I was not clear how hard it would be to pass those ansi-codes through to actually display their color/style values.
c) I can readily set up UDP or TCP stream providers to front end filter and feed through multiple data sources, or provide multiple channels to DebugView++. Is this something that has been done, are there other examples.
Very best and greatful regards,
David Simmons
Use the app all the time, have also modified source to include some features helpful for robotics/ROS. Very near perfect, I have a small wish list, maybe I will write and submit these mods if I can get to them, but they are:
-
interpret VT100/DEC escape sequences for client app-generated color and formatting: As of Windows 10, windows joins other OSs as supporting color and highlighted console text via the old style terminal code escape sequences. Color in logging is, obviously, very helpful and many console environments, even modern ones, use them. Supporting them is trivial. But it would enable the programmer to simply include the color and highlight they want in their app as opposed to needing to create it on DVPP. Outside of coloring, the ability to have the app being debugged send a "clear" signal to DVPP to clear the old logs would be a god send. It would also be great if the client app could inform DVPP of the coloring, it, after all, "knows best."
-
repetition-suppress log filter: Ability to mark certain log messages as only printing once per some period of time so long as their contents don't change. This is very useful for real-time applications like robotics where you don't need to see a position log sent to you 1000s of times when the robot is sitting still. Just once and awhile, like a heartbeat.
-
click through to visual studio: as with the errors window window of Visual Studio, ability to click a given log and be brought back to the source line in visual studio when double-clicked. A very simple VSIX could accommodate that and, perhaps, become a foundation for other interactions.
-
UTF-8 support. This is not the same as wide-char unicode support which I believe is supported. Subtle but this is the only widely accepted way to support unicode characters without requiring a double-byte conversion of apps which is not always or even often possible, particularly for those of us working with a great deal of legacy libraries. Here is a fail case:
I am sending:
u8"←"
which is turned into an ordinary C string with these bytes/chars per the UTF-8 convention:
\xE2\x86\x90
I am not an expert at Unicode et. al. But I don't think the UTF-8 system aligns with the way UNICODE is conventionally handled, as UTF-8 can variably have, I think, up to 5 bytes to represent a non-ascii char. and so :
DVPP prints: "â–²""
We used DebugView and now my whole team uses DebugView++
DebugView++ is awesome! It's a huge upgrade.
I love the view settings, how easy to config filter and color messages / hide noise from other processes
I use multiple views and the Link views button is very usefull
Keep up the good work! we love it!
@codenotes nice suggestions, however, I'm not adding new features to debugview++ anymore. I'm trying to get https://debug.vision/ off the ground. It aims to be multi-platform and also to have UTF-8 support.