@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 
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 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
@“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++
– 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 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
Windbg does not require WDK install on the target. At times I have even just copied windbg.exe and the DLLs that it needs to my target system.
Bill Wandel