Debugview joy for Win10

“The NEW phone book is here! The NEW phone book is here!” (The Jerk)

A new version of dbgview is available on the MS Sysinternals site which works on Win10 without the .sys renaming shuffle (v4.90).
I did notice the older version 4.81 is still in the zip file with a cap as Dbgview.exe. V4.90 is the all lowercase dbgview.exe in the zip file
dated 4/23/2019.

Thank you, Thank you Mark Russinovich!

PS: Don’t forget your DEFAULT dword value in the registry at “\HKLM\CurrentControlSet\Control\Session Manager\Debug Print Filter”
0xF gets all debug prints.

What was the prolblem with earlier DbgViews? I have version 4.76 running on W10.

On 4/24/19, RJ-2 wrote:
> OSR https://community.osr.com/
> RJ-2 started a new discussion: Debugview joy for Win10
>
> “The NEW phone book is here! The NEW phone book is here!” (The Jerk)
>
> A new version of dbgview is available on the MS Sysinternals site which
> works on Win10 without the .sys renaming shuffle (v4.90).
>
> I did notice the older version 4.81 is still in the zip file with a cap as
> Dbgview.exe. V4.90 is the all lowercase dbgview.exe in the zip file
>
> dated 4/23/2019.
>
> Thank you, Thank you Mark Russinovich!
>
> PS: Don’t forget your DEFAULT dword value in the registry at
> “\HKLM\CurrentControlSet\Control\Session Manager\Debug Print Filter”
>
> 0xF gets all debug prints.
>
> –
> Reply to this email directly or follow the link below to check it out:
> https://community.osr.com/discussion/291282/debugview-joy-for-win10
>
> Check it out:
> https://community.osr.com/discussion/291282/debugview-joy-for-win10
>

Search the list for “dbgv.sys”.
The old problem only presents itself when exercising “Capture Kernel” or “Log Boot”.

@Dejan_Maksimovic said:
What was the prolblem with earlier DbgViews? I have version 4.76 running on W10.

@RJ-2
Nice. Thanks for the info.
P.S. Looks like 1809+ versions hold [memory mapping of] driver image till driver loaded. So old trick “temporary unpack driver file/load driver/delete driver file” does not work now. Does this change discussed or described here or in any other place?

Of course I am using Capture Kernel.
I never used log boot, though.

Simply Run as Admin, and it’s working (even if you disable UAC, you
have to Run as Admin on W10)

Search the list for “dbgv.sys”.

The old problem only presents itself when exercising “Capture Kernel” or
“Log Boot”.

> @Dejan_Maksimovic said:
>
> What was the prolblem with earlier DbgViews? I have version 4.76 running
> on W10.

(I can’t resist any longer: I don’t get the fascination with this tool. I don’t use it, nobody I know ever uses it. If I want debug output, I just hook up the debugger, and I’m done. Who cares about DebugView? There, I said it and now I feel better.)

If I want debug output, I just hook up the debugger, and I’m done.
How do you insulate problem which exists on user machine only? Debug logging much simpler than anything else.

How do you insulate problem which exists on user machine only

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

Peter

I could make a pretty snubby comment here :slight_smile:

You can attach WinDBG on your client’s machine? That is rare.

You can attach WinDBG on your client’s machine? That is rare.

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?

That is rare.

Peter

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?

> You can attach WinDBG on your client’s machine? That is rare.

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?

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