[timmisiak]

I worked on the one that ships with WinDbg: https://learn.microsoft.com/en-us/windows-hardware/drivers/d...

Literally every person who uses it for debugging a hard problem absolutely raves about it. Debugging something like a stack corruption or a heap corruption is trivial. And every other class of bugs are also incredibly easy, as long as it doesn't rely on very precise timing where the tracing changes the behavior. So why don't more people use it? Why haven't more people heard about it?

I'm not entirely sure, but I do have a guess. Most bugs are shallow. We tend to think about the really hard, really deep bugs, but the vast majority of devs are working on bugs where it's easier to just add some logging to figure out a logic error.

[moremetadata]

If an app is set up to output all variables, doesn't debugview or debugview++ effectively give you the same ability to step back in time?

Of course, it means adding code to the app to output everything to debugview where as the debugger can use the debug symbols and then log everything which is alot less work, but some languages dont come with a debugger.

Stepping back in time is useful though!

[mark_undoio]

The answer, as always with engineering is a "yes but"

It's pretty appealing. I also believe MS Visual Studio had something that effectively worked like that albeit without changing the coffee manually.

But - if you've got bugs due to memory corruption, race conditions, etc then the logging doesn't necessarily tell you what you need as you don't know when the change actually happened.

The other issue is that once you've started logging everywhere the string formatting is likely going to be a significant slowdown - at which point you could have used a time travel debugger and probably get better performance.

(disclaimer: I work on a time travel debugger)

[HelloNurse]

> Of course, it means adding code to the app to output everything to debugview

It's a big deal, for example when the "app" is a third party library that cannot be altered.