Debugview joy for Win10

Now that I think about it, you cannot attach WinDBG to an active
session, unless it was enabled from the start, so I guess you were
talking about running WinDBG on the local machine, simply instead of
DebugView :slight_smile:

The client seeing your debug output is one thing, but you attaching a
debugger to a production machine - that was impossible for me, even if
they wanted to do it remotely.

Unless you meant a live session on the local machine?

> Who cares DebugView?

Me. For me it is the most useful and the most used System Internals tools and if Mark Russinovich haven’t written it, I’d have to do it myself. The killer feature is color filters (I even asked Mark many years ago to increase their number from 10 to 20 which he did). They allow me to see anything important or unusual easily. I have set red filter to word “error”, having DbgView running all the time on the secondary monitor and if everything bad happens in my software, I immediately notice it. This way it is always debugged which improves its quality.

Of course, I use traces as the main and usually the only debugging tool so all errors are reported this way. (Debuggers are just for beginners, anyway. There, I said it and now I feel better ;-))

You can run DbgView on your client’s machine? And, if you have your client do it, you let them see your internal DbgPrint spew?

Sure, why not? I never understood why it should be a problem. However, most of my “clients” who do it are my coworkers (QA, support, FAEs…). They live in different time zones around all the World (mine is usually Hawaii ;-)) and they can capture the log when they have time. No need to work together and try to establish remote session. I just send instructions and they send back the log. Easy for everybody involved, convenient and efficient. Sometimes I just create a Jira ticket and that’s all.

I attach the kernel debugger. Why would I not want to do that?

Because it is laborious and usually, there is a firewall or policy between you and the target machine which doesn’t allow it. At least in my case. Even if it is possible, you need a cooperating and technically savvy person on the other side. Working at the same time as you do.

Michal

+1. DebugView is somewhat like being able to type “dmesg” anytime :slight_smile: Or that system logs applet of OSX :slight_smile: :slight_smile:

DebugView is somewhat like being able to type “dmesg” anytime

Precisely. 100% agreed. Equally terrible as a method for diagnosing and debugging driver problems.

If your QA folks can’t learn to setup WinDbg, I would respectfully suggest… you know what I’m going to say.

You want trace data from CUSTOMER machines, in production, you’d be mad to use DbgPrint, even if only due to the perf hit. Some ETW-based tracing is most appropriate here (choose WPP if you wish for quick and dirty).

Peter

> If your QA folks can’t learn to setup WinDbg, I would respectfully suggest…

you know what I’m going to say.

They don’t need WinDbg for anything else and DbgView is simpler to install and use. So why should I teach them to setup WinDbg?

You want trace data from CUSTOMER machines, in production, you’d be mad
to use DbgPrint, even if only due to the perf hit. Some ETW-based tracing is
most appropriate here (choose WPP if you wish for quick and dirty).

Performance hit is the same as ETW for disabled traces (default for all). For enabled it can be a bit higher but I haven’t measured the difference as it was never a problem. Actually, it can be a problem only if enormous amount of traces is generated as if we need traces from customer machines, we send precise trace configuration where isn’t such a danger.

Actually, I’m just implementing new trace library and I’m pondering also ETW variant. However, ETW is ridiculously complicated and still limited which makes mapping our traces to it rather uneasy. I’m afraid there aren’t enough advantages to justify extra work.

Michal

why should I teach them to setup WinDbg?

Oh, I dunno… maybe so they could, like, set breakpoints, alter variables (trace settings or whatever)… you know, do “debugging” stuff that you do with a debugger?

I guess it depends on the role of your QA folks in your org.

However, ETW is ridiculously complicated and still limited

ETW is annoying to get started with, I’ll grant you that. After a couple of years of promoting it to the community, a year or two of being badly burnt by it, and several years despising it… we’ve returned to using it here over the last few years. It’s as flexible and powerful as I can possibly imagine. Perhaps my imagination is limited. It’s just hard to make it through the docs and macros and figure out how to do what you need. The WPP implementation is so much horrible “pre-processor before the preprocessor” magic it can turn your stomach at times. But it’s mostly “learn once, write once” code, and terrible as that concept might be.

Peter

Errr, your customers work for you as your QA?:slight_smile:

> why should I teach them to setup WinDbg?

Oh, I dunno… maybe so they could, like, set breakpoints, alter variables
(trace settings or whatever)… you know, do “debugging” stuff that you do
with a debugger?

your customers work for you as your QA

We’ve got who separate concepts here, Mr. Maksimovic: Customers and Mr. Vodicka’s QA team. We can talk about two things at once, I think, can’t we?

Peter

It seems my last post didn’t pass through :s

@Michal_Vodicka said:
It seems my last post didn’t pass through :s

And I do t know why, and I don’t see it in the spam queue.

Another mystery of modern life, I’m afraid.

Peter

Sent via e-mail as previous ones. Well, it is the mystery of this… how do you call it?

I’ll repost it using the web interface. The advantage of the mail is the text is saved in the sent items.

Oh, I dunno… maybe so they could, like, set breakpoints, alter variables
(trace settings or whatever)… you know, do “debugging” stuff that you do
with a debugger?

That’s not their job. Also, I can hardly teach them something I don’t do. I don’t remember if I’ve ever used WinDbg for things you mention. Probably not. That debugging stuff is too laborious and extremely inefficient. I’m really lazy person so I prefer looking few minutes to the log over few hours or days of single stepping. Well, I don’t remember when I did it last time with any debugger. Maybe in previous millennium?

ETW is annoying to get started with, I’ll grant you that.

I trust you. I looked at it several times and always gave up.

we’ve returned to using it here over the last few years.

Do you have any example or an article which shows using pure ETW (without WPP) some usable way? I’d need something for inspiration and something to guess how much time it can take.

The WPP implementation is so much horrible “pre-processor before the preprocessor”

Yep, that’s horrible. The example how having too much power can be bad. I implemented something similar (traces for embedded platforms formatted at host side) and standard C preprocessor was sufficient.

I want to avoid WPP because our target is not only drivers but also apps and services. There should be unified approach for everything. ETW can be the way if I’m able to map it to trace macros we already use.

Michal

@Michal_Vodicka said:
Sent via e-mail as previous ones. Well, it is the mystery of this… how do you call it?

THAT’s not good. I need to check into that.

Thanks for letting me know

Peter

Do you have any example or an article which shows using pure ETW (without WPP)

I’d be happy to share it if we had it… but we did it was a bunch of custom WPP routines. Yuck.

Peter

I want to avoid WPP because our target is not only drivers but also apps and services.

WPP does work in usermode. Few years ago an example for this was posed by Ivan Brugiolo (IIRC), I’ve tested it, it worked.

/* And just for laughs: recently I needed trace solution for a small embedded MCU which has too little memory for printf.
Inspired by WPP, I made a simple preprocessor; it converts every instance of printf-like statement to unique macro,
which eventually moves the parameters as binary to the host, which does formatting etc.
These macros are “injected” into their respective .c files using “inject include” compiler option, -FI or -j,
so users do not see #include’s of .tmh files, and do not ask questions :wink:
The preprocessor is very crude, but works for us. Thanks for the idea, Microsoft.
The best thing about it - to change anything we just fix it in the preprocessor itself - no obscure configurations.
*/

– pa

I believe it is possible to use WPP in user mode but I still dislike this idea.

Well, I did the same as you for the same reasons (not enough memory for all trace strings) but I didn’t need extra preprocessor. The standard one was enough. C99 and gcc as I needed __VA_AGRS__ and __COUNTER__ to make unique numbers. Macros put format strings plus their identification to a separate data section which is cut out from firmware at the last build step. For host I wrote an application which receives binary data from the device debug port or SWO and formats them using info from mentioned section. And then sends it to debug output where we use DebugView for display to return to the original subject :wink: The app monitors trace section file changes and reloads it after every firmware rebuild so there is no need to do anything at the host side.

Actually, I’m just porting this to the next embedded platform as the very first step because we are so used to it we don’t want to do any work without it. Nobody wants to use a debugger anymore :wink:

@“Peter_Viscarola_(OSR)” said:

your customers work for you as your QA

We’ve got who separate concepts here, Mr. Maksimovic: Customers and Mr. Vodicka’s QA team. We can talk about two things at once, I think, can’t we?
Ah, I did not read through the enitrety of the post, so I presumed we were still talking about cusotmers (as we did at the start of the thread).

Anyway, getting our company to use WinDBG - prolly. Getting our customers to use WinDBG -no way. That requires setting up a second machine to connect WinDBG to a dead machine and reproducing the crash (which, if possible, we can do ourselves)

So why it is a big deal to persuade people use windbg? Is it mainly because of lack of physical debugger connectivity?
Serial is slow (and connector not exposed, except of IoT thingies).
Firewire is dead. USB 2 and 3 - dead? Ethernet - problematic because of ethernet h/w compatibility.
What’s left?

@Michal_Vodicka Thumbs up!
We tried to do it this simple too, but the codebase had too complicated debug stuff not feasible for C preprocessor. At least beyond my skills.
And the team demanded zero changes to existing code.
C++17 seems to enable some amazing template and constexpr tricks… Consider move to c++ :wink:

– pa

> So why it is so a big ideal to persuade people use windbg? Is it mainly

because of lack of physical debugger connectivity?
For me, primarily yes.
Also the fact that DebugView requires no installation, whereas WinDBG
requires WDK installation.

C++17 seems to enable some amazing template tricks… Consider move to c++
In kernel mode?

> So why it is so a big ideal to persuade people use windbg? Is it mainly

because of lack of physical debugger connectivity?

In my case because they don’t need it. All I need from them is to capture debug log and using DbgView is much easier. No install, just run, reproduce problem, save log and send it. For me is hard to imagine how to explain their managers why they should spend time with install, setup and learning WinDbg.

C++17 seems to enable some amazing template tricks… Consider move to
c++

I can’t; fortunately :wink: We have to support the lowest common denominator as our customers may want to port our code to virtually anything including very limited embedded platforms and use ancient toolchains. Even C99 can be a problem… but I’m going to solve it only if it really happens which is hopefully never.

Michal