Feedback on Debugview++

[janwilmans]

• 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!)

[hoppfrosch]

Love it! Use it nearly every day without any complaint yet and it works llike a flaw. I don't have feature requests ATM.

[SteeleDynamics]

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!

[janwilmans]

SteeleDynamics: very interested in your contributions, what are you thinking of ?

[harriv]

1. Yes, works mostly great :)
2. Few feature request: #213 #109 (I'd like to have daily timestamp on filename, but it's minor detail:), #209 #135

[PeterMortensen]

For the console version, DebugViewConsole.exe, I got:

"DebugViewConsole 1.8.0.7 Neither output to logfile or console was specified, noting to do..."

1. "noting to do" should be "nothing to do"

2. 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.".

[harriv]

@PeterMortensen I created #310 for first issue :)

[PeterMortensen]

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)?

[janwilmans]

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.

[PeterMortensen]

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.

[janwilmans]

I am logged in as administrator on the Windows XP 64-bit system.

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.

v1.8 should just work, although I do not guarantee anymore that future versions will keep working, I have not needed to break anything. I will put the links back soon.

[janwilmans]

It took some more time than I anticipated, but the v1.5 links at back up. Let me know what you find.

[PeterMortensen]

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.

[janwilmans]

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...)

[PeterMortensen]

Sorry for the late reply.

It works!!! Thank you very much.

What did you change?

[janwilmans]

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 2b4aae048237bea83df2ff0c28ea50ebc3de7e57

[janwilmans]

@harriv , about #213 #109, #209 #135, I would like them too, however, they are not trivial to implement in the current design. I'm considering a redesign/ new implementation, that is portable and allows me to implement these features also, see https://github.com/CobaltFusion/DebugVisualizer

[ItsGeekman]

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).

[janwilmans]

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.

[techtim2003]

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.

[janwilmans]

@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?)

[cpriest]

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.

[RrnR]

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?

[janwilmans]

That is actually quite easy to do, if you can write to stdout, you can just pipe that into debugview++. Alternately, you can send udp messages...

I can point you in the right direction, but I'm not at my desk right now, I'll respond asap

On Thu, Apr 25, 2019, 22:20 RrnR [email protected] wrote:

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?

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/CobaltFusion/DebugViewPP/issues/283#issuecomment-486823315, or mute the thread https://github.com/notifications/unsubscribe-auth/ABNITBFEIV62XAGJUERNJOTPSIG7VANCNFSM4DT2BERA .

[janwilmans]

1. 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.

2. 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.

[RrnR]

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?

[markbearden]

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.

https://www.microsoft.com/en-us/wdsi/threats/malware-encyclopedia-description?Name=Trojan:Win32/Tiggre!plock&ThreatID=-2147243670

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.

[janwilmans]

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!

[janwilmans]

@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.

[RrnR]

Thanks @Jan. I'll probably go the UDP way, I'm imagining it would be less impact. If I end up with something that's reusable and useful (Delphi) I'll post it.

[janwilmans]

Thanks, it would be great if you could provide a working Delphi example!