Debugging a printer driver?

[Laura Keller [MSFT]]

How to Debug a Printer Driver

We've tried to cover all the essential steps here for debugging a printer
driver, but if you need additional information, please reply asap to this
thread and we'll work on getting that information added too.

Step 1: Install the latest debugging tools from
http://www.microsoft.com/ddk/debugging/. It is essential that you install
the latest version of the debugger. Read the debugger documentation to
become familiar with the numerous debugging commands. The debugger
documentation also contains a guide for setting up user-mode debugging. You
do not need two machines in order to do user-mode debugging.

Step 2: Install the current symbols from
http://www.microsoft.com/ddk/debugging/symbols.asp.

Step 3: Install the latest checked build. Or, for maximum system speed,
install only the components you need. Typically, you will replace the
following retail binaries with their corresponding checked builds:

- unidrv.dll

- unidrvui.dll

- unires.dll

For details, see "Partial Checked Build" in the index of the Driver
Development Kit (DDK,) which is available to everyone from the MSDN Library.

Step 4: Install the checked build of OEMUNI sample or the printer driver
that you are debugging.

To begin debugging, do an "Attach to Process" in WinDbg for user-mode
debugging. For print drivers, you will either need to attach to the printing
application or to the spooler process (spoolsv.exe), depending on what
component you are debugging. Typically, the configuration DLL is loaded by
the printing application, while the rendering module is loaded by the
spooler process.

A special case is "FILE:" printing, which does not use spooling. In this
case, the rendering module is also loaded by the printing application. Try
the following:

1. Install the OEMUNI sample on the "FILE:" port.

2. Open WordPad.

3. Do an "Attach to Process" in WinDbg and select the WordPad process.

4. Start a print job from WordPad. You are now ready to debug the OEMUNI
sample.

Some additional tips:

You can enable verbose debugging in Unidrv by changing the value of the
"giDebugLevel" debugger variable from its default of 3 (ERROR or WARNING) to
1, or VERBOSE. To do this, execute the following debugger command:

ed unidrv!giDebugLevel 1

The same variable will also enable verbose debugging for the OEMUNI sample.
To do this, execute the following command:

ed oemuni!giDebugLevel 1

You can also add your own debugging statements to the OEMUNI sample.

--
Laura Keller [MSFT]
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

[Abhishek Gattani]

Greetings,

My problem is local user mode debugging for a (virtual) printer driver on
the line of a PDF Writer or a Image Printer.
Let me explain my situation
I have a printer driver with three components dlls
one the user mode dll umdrv.dll
another the kernel mode dll kmdrv.dl
and a user interface dll uidrv.dll
my sources are in the folder

d:\SingleSrc\umdrv\src

d:\SingleSrc\kmdrv\src

d:\SingleSrc\drvui\src

I have DDK installed in D:\ddk
amd the Win32 SDK on d:\mssdk

Now i got to checked build environment and use build -cZ to build my dll and
lib.

Firstly I don't know whether symbol files for the same are build or not.
Please enlighten me with this.

Following are the settings for WiDbg

Symbol file path:
SRV*f:\websymbols*http://msdl.microsoft.com/download/symbols
Note: I am trying to use the symbols directly from the micrsoft serve would
this work?

Source file path:
D:\SingleSrc\UMDRV\Src;D:\SingleSrc\KMDRV\Src;D:\SingleSrc\Drvui\Src

Image File path:
D:\WINNT\system32\spool\drivers\w32x86\2
Note: this is the place where i put my DLLs.

Do I have to make any further settings for WinDBG user mode debugging?

Now I belive the next step is to attach to a process. Mine is a printer
driver , similar to a PDF Writer where any application which can print its
output is captured and then saved to file in the form of a raster image.
About the processes which I have come to know I should attach are csrss.exe
, spoolss.exe or printing application such as notepad.exe.

Now i am not sure which process I have to actually attach to. Please tell me
this...
Now after making the above settings when I click attach to any of the above
processes what is displayed is a disassembly code. Though i load the sources
but still I am unable to do source level debugging. What could be the
reason? when I press F10 control moves from one line to another but I am
also not sure what is happening.

What should I do to my source file that is umdrv.c for user mode so that the
windbg breaks into that.
I am right now not interested to debug the kernel mode only the user mode
hence please do confirm that user-mode debugging can help or not.
I read this article though backdated that one cannot do local user-mode
debugging for printer drivers.

Tell me what more can I do?

I need serious help. Looking forward for a reply

Best Wishes
Abhishek

"Laura Keller [MSFT]" <Lake...@online.microsoft.com> wrote in message
news:OCJJ90#nCHA.2224@TK2MSFTNGP09...