Discussion:
DbgPrint(Ex) output does not appear in DebugView
(too old to reply)
R.Wieser
2018-09-13 12:57:22 UTC
Permalink
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
2018-09-14 14:22:27 UTC
Permalink
Post by 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
Has Debug View's `Capture Kernel` option been ticked yet?
R.Wieser
2018-09-14 15:39:02 UTC
Permalink
JJ,
Post by 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
2018-09-15 13:29:41 UTC
Permalink
Post by R.Wieser
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?
Post by R.Wieser
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
2018-09-15 14:31:46 UTC
Permalink
JJ,
Post by 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.
Post by JJ
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
2018-09-16 17:30:41 UTC
Permalink
Post by R.Wieser
I read about it, but I think you're talking about the KdPrint macro.
No, I'm not.
Post by R.Wieser
And yes, I assembled the sourcefile and just took a look a peek to make
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.
Post by R.Wieser
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
2018-09-16 18:15:49 UTC
Permalink
JJ,
Post by 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.
Post by JJ
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.
Post by JJ
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

Loading...