Newbie on kdprint

I can’t find all the steps needed to debug a driver using Windbg. Is there a good tutorial out there? It seems to get more difficult each time I read something new. I have windbg on target and host sytems. I have a null serial cable. I confirmed it works via hyperlink. I have kdprint statements throughout my driver code. I have my driver built using a checked build. I can’t figure out how to actually see one of these print statements. Everything I read is vague or 100s of pages and way over my head. I just want to start off very simple. Nothing seems to be simple. Writing my driver and getting config reads to work was easier than seeing a kdprint statement.

There is a great deal of truth to what you say. As far as a tutorial,
check the web, because there is nothing official.

  1. Is your driver loading?
  2. Are you connected with WinDbg?
  3. Are your driver’s symbols loaded?

If you don’t know the answer or how to find the answer to any of these,
write back.

mm

>> xxxxx@hotmail.com 2006-10-12 20:07 >>>
I can’t find all the steps needed to debug a driver using Windbg. Is
there a good tutorial out there? It seems to get more difficult each
time I read something new. I have windbg on target and host sytems. I
have a null serial cable. I confirmed it works via hyperlink. I have
kdprint statements throughout my driver code. I have my driver built
using a checked build. I can’t figure out how to actually see one of
these print statements. Everything I read is vague or 100s of pages and
way over my head. I just want to start off very simple. Nothing seems
to be simple. Writing my driver and getting config reads to work was
easier than seeing a kdprint statement.


You are currently subscribed to windbg as: xxxxx@evitechnology.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Are you running Windows Vista on the debuggee? Vista disables debug
output by default. The DDK docs on DbgPrintEx cover the various options
for enabling and controlling debug output. The simplest thing to try is
to break into kd and do

ed nt!kd_default_mask 8

and resume prior to running through your driver code. Does that help?

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Thursday, October 12, 2006 5:07 PM
To: Kernel Debugging Interest List
Subject: [windbg] Newbie on kdprint

I can’t find all the steps needed to debug a driver using Windbg. Is
there a good tutorial out there? It seems to get more difficult each
time I read something new. I have windbg on target and host sytems. I
have a null serial cable. I confirmed it works via hyperlink. I have
kdprint statements throughout my driver code. I have my driver built
using a checked build. I can’t figure out how to actually see one of
these print statements. Everything I read is vague or 100s of pages and
way over my head. I just want to start off very simple. Nothing seems
to be simple. Writing my driver and getting config reads to work was
easier than seeing a kdprint statement.


You are currently subscribed to windbg as: xxxxx@winse.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

I am running 2000, not Vista. I could use XP if it makes life any easier but I’m assuming it won’t.

There is a great deal of truth to what you say. As far as a tutorial, check the web, because there is >nothing official.
I have found very poor/conflicting information online up to this point.

  1. Is your driver loading?
    The driver loads and works fine. I have an application I wrote to read config space and everything goes well. I just know that life won’t be so easy when I implement the DMA stuff. Before I do that I have to find my way around Windows refusal to give me memory, but that is a different issue.
  1. Are you connected with WinDbg?
    Windbg is not connecting. I have a null serial cable(verified to work via hyperlink). I have windbg on both machines. I open a kernel debug session on both machines with the same port and baudrate. Still no connection.
  1. Are your driver’s symbols loaded? If you don’t know the answer or how to find the answer to any of these, write back.
    Symbols are not loaded. This is something I just became familiar with. I have set up a symbol path to a folder I created but I have no ide what symbols are and where to get the ones needed for this folder. I realize this is important but would this prevent windbg from connecting?

I also saw something about the boot.ini file but i’m unsure what toput in here. My system seems to have many boot.ini files. I’m assuming the build or some other tool generated some for me. What role does this play and where does it belong?

xxxxx@yahoo.com wrote:

>2. Are you connected with WinDbg?
>
>
Windbg is not connecting. I have a null serial cable(verified to work via hyperlink). I have windbg on both machines. I open a kernel debug session on both machines with the same port and baudrate. Still no connection.

What do you mean by “open a kernel debug session on both machines”? You
only run windbg on one machine – your host machine, the one that
DOESN’T have your driver. On the other machine, called the “target”,
you need to turn the kernel debugger at boot time by adding /debug
parameters to boot.ini, and then choose that option at boot time.

I also saw something about the boot.ini file but i’m unsure what toput in here. My system seems to have many boot.ini files. I’m assuming the build or some other tool generated some for me. What role does this play and where does it belong?

There is only one boot.ini file, and it is in the root of your hard
drive: c:\boot.ini. If you haven’t edited it, then that is why it
isn’t working: you haven’t turned on the kernel debugger.

Your boot.ini probably looks something like this:
[boot loader]
timeout=3
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS=“Microsoft Windows XP
Professional” /fastdetect
C:\CMDCONS\BOOTSECT.DAT=“Microsoft Windows Recovery Console” /cmdcons

You meed to duplicate the line in the [operating systems] section that
refers to your installation, and then add
/debugport=com2 /baudrate=19200
to the end. So:

[boot loader]
timeout=3
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS=“Microsoft Windows XP
Professional” /fastdetect
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS=“Microsoft Windows XP
Professional” /fastdetect /debugport=com2 /baudrate=19200
C:\CMDCONS\BOOTSECT.DAT=“Microsoft Windows Recovery Console” /cmdcons

Make sure the “timeout” value is not set to 0, otherwise you never get a
chance to pick one. The next time you boot, your boot options will
include a line with the debugger. Pick that one. Windbg should connect
up early in the boot process.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Thanks, that was the missing piece. I can see print statement now. The boot process takes an insane amount of time now. Is that normal?

xxxxx@yahoo.com wrote:

Thanks, that was the missing piece. I can see print statement now. The boot process takes an insane amount of time now. Is that normal?

It depends on a number of factors. What do you mean by “an insane
amount of time”? One minute? Ten minutes? What is your baud rate?
You can use 38400 without problem on most serial ports, and 115200 on
some of them. If the baud rate is low, the module loading notifications
takes a long time.

There was another comment not too long ago on how to chase down an
excessively long boot, but I don’t remember it now. Hopefully, one of
the WinDbg team can offer enlightenment.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

>> The boot process takes an insane amount of time now. Is that normal?

Debug version of your driver can be the cause apart from other things.

On 10/13/06, xxxxx@yahoo.com
wrote:
>
> Thanks, that was the missing piece. I can see print statement now. The
> boot process takes an insane amount of time now. Is that normal?
>
> —
> You are currently subscribed to windbg as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

The usual steps for helping with a slow boot are:

  1. If you’re using serial kd make sure legacy USB support is disabled in
    the target’s BIOS.

  2. Make sure your breakpoint list has only valid breakpoints. Always
    use module qualifiers on symbols.

  3. If you’re using windbg you can try closing windows, such as the
    disassembly, locals or watch windows, to see if that helps.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Friday, October 13, 2006 10:52 AM
To: Kernel Debugging Interest List
Subject: Re: [windbg] Newbie on kdprint

xxxxx@yahoo.com wrote:

Thanks, that was the missing piece. I can see print statement now.
The boot process takes an insane amount of time now. Is that normal?

It depends on a number of factors. What do you mean by “an insane
amount of time”? One minute? Ten minutes? What is your baud rate?
You can use 38400 without problem on most serial ports, and 115200 on
some of them. If the baud rate is low, the module loading notifications
takes a long time.

There was another comment not too long ago on how to chase down an
excessively long boot, but I don’t remember it now. Hopefully, one of
the WinDbg team can offer enlightenment.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.


You are currently subscribed to windbg as: xxxxx@winse.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com