DbgPrint(Ex) output does not appear in DebugView

[R.Wieser]

Hello All,

I'm currently trying to write a (minimal, skeleton) device driver, and did
put a few DbgPrint (and later DbgPrintEx) commands in it. The problem is
that none of the output appears in DebugView. Which ofcourse makes debugging
it rather hard ...

Is there maybe something else that needs to be done (like a "debug" flag in
the executable perhaps) ?

Regards,
Rudy Wieser

[JJ]

Has Debug View's `Capture Kernel` option been ticked yet?

[R.Wieser]

JJ,

> Has Debug View's `Capture Kernel` option been ticked yet?

Yep. And I've walked thru all other menu items too. Nothing else to be
found.

I've also tried several "solutions" I found on the web (including using
DbgPrintEx and adding certain "filter nothing/display everything" keys to
the registry), but no dice there either.

And don't laugh, but only today I stumbled over the requirement (is it ?) of
some kind of "kernel-driver debugger SDK"*. Alas, the one I
downloaded-and-installed from MS didn't do the trick either.

*Though I would have assumed that DebugView (from SysInternals) would have
complained if something it needed to actually function was/is not present,
and it hasn't ...

I also read an article in which was claimed that DbgPrint on XP simply did
not want to work on some XP configurations (but which ones ...).


Part of the problem is that there seems to be nothing in regard to a "is it
present and does it function" testing button/program/dummy-driver/other
available, so I'm really feeling my way around in the dark. :-(

I really REALLY could use some help here ...

Regards,
Rudy Wieser

P.s.
I'm not using a C{something} environment, so all configuring needs to be
done manually.

[JJ]

On Fri, 14 Sep 2018 17:39:02 +0200, R.Wieser wrote:
>
> I also read an article in which was claimed that DbgPrint on XP simply did
> not want to work on some XP configurations (but which ones ...).

Which article was that?

> Part of the problem is that there seems to be nothing in regard to a "is it
> present and does it function" testing button/program/dummy-driver/other
> available, so I'm really feeling my way around in the dark. :-(
>
> I really REALLY could use some help here ...
>
> Regards,
> Rudy Wieser
>
> P.s.
> I'm not using a C{something} environment, so all configuring needs to be
> done manually.

Have you checked the compiled binary to see if it actually has code which
calls DbgPrint/Ex? Cause there's a possibility that the function is replaced
with a dummy function or NOP by either the compiler or the include file, if
a specific symbol is not defined. e.g. DEBUG or DEBUG_BUILD

[R.Wieser]

JJ,

> Which article was that?

I'm sorry, but I could not say. I was busy trying to find a solution, and as
such have, over the course of a week, visited quite a number of websites.

> Cause there's a possibility that the function is replaced
> with a dummy function or NOP by either the compiler
> or the include file

I read about it, but I think you're talking about the KdPrint macro.

And yes, I assembled the sourcefile and just took a look a peek to make
absolutily sure :

2 168 00000007 68 00000000r PUSH offset @@TXT_Hello
2 169 0000000C E8 00000000e CALL DbgPrint
2 170 00000011 83 C4 04 ADD ESP,00004h

Its there alright. :-)

I must confess that I'm not at all sure anymore if what I'm doing is what I
*should* be doing ...

Although I tried to follow a tut, its method of just setting up the relevan
registry-keys and than use "net start X" didn't want to work (got errors),
so I've been using "sc create X" followed by"sc start X" - which keeps
throwing a "The specified driver is invalid" error. :-(

Regards,
Rudy Wieser

[JJ]

On Sat, 15 Sep 2018 16:31:46 +0200, R.Wieser wrote:
> I read about it, but I think you're talking about the KdPrint macro.

No, I'm not.

> And yes, I assembled the sourcefile and just took a look a peek to make
> absolutily sure :
>
> 2 168 00000007 68 00000000r PUSH offset @@TXT_Hello
> 2 169 0000000C E8 00000000e CALL DbgPrint
> 2 170 00000011 83 C4 04 ADD ESP,00004h
>
> Its there alright. :-)

Maybe. Maybe not. It's still uncertain. The CALL instruction points to a
local code where it may actually be a dummy function. i.e. it may not
actually call DbgPrint which is in NTOSKRNL.EXE module.

> Although I tried to follow a tut, its method of just setting up the relevan
> registry-keys and than use "net start X" didn't want to work (got errors),
> so I've been using "sc create X" followed by"sc start X" - which keeps
> throwing a "The specified driver is invalid" error. :-(

It could be due to wrong value for the minimum OS version, image version, or
subsystem version in the PE fields. Otherwise, the driver registration is
incorrect.

[R.Wieser]

JJ,

> No, I'm not.

Than we have a problem ...

As far as the MS documentation is concerned DbgPrint will always appear in
the code, while KdPrint is a macro causing a DbgPrint or nothing to be
emitted, depending on a debug flag.

> Maybe. Maybe not. It's still uncertain.

No, its quite certain. For my assembler its the standard way to call a
function in a DLL.

Also, looking at the drivers imports I can see both the DbgPrint function
and the ntoskrnl.exe mentioned.

> It could be due to wrong value for the minimum OS version, image
> version, or subsystem version in the PE fields.

In the end (after a number of other "whats happening here?" headscratches)
it turned out I didn't checksum the driver, which caused it to be rejected.

After having done so the DbgPrint output popped up in DebugView.

Regards,
Rudy Wieser