Ok, it looks like there are two issues here. First, getting the driver
properly installed. Second, verifying that the driver is installed and
being able to manipulate it under the debugger.
To get your driver properly installed, you’ll need to write an INF file, or
do what everyone usually does and mangle an existing one. Try starting with
the INF file from the parallel-port driver you started with. Since it
sounds like your driver is a filter driver layered on an existing driver,
you’ll need to add entries for your “ppfilter” driver to the existing INF
file.
First, add a section that describes the device service. This may sound a
bit strange, but this is a hold-over from the NT3.x / NT4.x driver model –
every driver has an entry in the Service Control Manager’s database. The
command-line app sc.exe is a (crude) front-end to the SCM. The SCM contains
entries that describe both user-mode services (such as Task Scheduler, SQL
Server, etc.) as well as device drivers. To see an example of an existing
device driver’s entry, run “sc qc tcpip” (qc = query configuration). Be
careful with using sc to modify the configuration of services, because you
can quite easily hose a machine by disabling or confusing an essential
driver or service.
So, in your INF file, you need to add an entry that describes this service.
Since you’re modifying an existing driver’s INF file, there should already
be one there to serve as a template. It should be something like this:
[ppfilter_Service]
DisplayName=Whatever You Want Here
ServiceType=1 ; 1=SERVICE_KERNEL_DRIVER
StartType=3 ; 3=SERVICE_DEMAND_START
ErrorControl=1 ; 1=SERVICE_ERROR_NORMAL
ServiceBinary=%12%\ppfilter.sys
Next, you’ll need to modify the device installation section, so that it does
create this service entry when the device is installed. Find the existing
AddService=… entry, and add the name of the above section. Something
like:
[… mydeviceentry …]
AddService=fdo_service_section_name, ppfilter_Service
“fdo_service_section_name” is just a placeholder for whatever is already
there. That section needs to be preserved.
Next, add ppfilter.sys to the [SourceDisksFiles] section, and to the
“CopyFiles” section. The existing sections should serve as templates.
Next, you’ll need to add a registry entry that identifies your filter as an
upper-layer filter. Look for an AddReg section, and add a line like this:
[… blah blah .AddReg]
HKR,“UpperFilters”,0x10000,“ppfilter”
This installs a registry entry that PNP uses to build the list of upper
filters. Next, use Device Manager and re-install the drivers for your
serial port device. Using Device Manager, select device properties, go to
Driver tab, click “Update Driver…”. Now you’ll have to dodge all manner
of dialogs and refuse all sorts of attempts to find the right driver for
you. Choose no to searching the web for drivers, choose “install from a
specific location”, choose “don’t search, i’ll choose”, click “Have Disk”,
browse to the directory containing your INF file, and choose your driver.
You can also bypass the GUI and use a command-line tool from the DDK. This
can be a big help during development, to avoid the long series of GUI
prompts. The utility is in WINDDK\2600\src\setup\devcon. Build the
utility, and use the “update” command. You’ll need to provide the hardware
ID of the device to update, and the path to your INF file. You can find the
hardware ID by going to the device property page, clicking Details, and
choosing “Hardware IDs” from the drop-down. Be advised that this will
update the drivers for ALL devices whose hardware ID matches, rather than
just one device!
Device Manager *should* copy your ppfilter.sys to
%systemroot%\system32\drivers\ppfilter.sys, and should create a service
definition. You can verify this by using “sc qc ppfilter” to check that the
device driver entry has been created in the SCM. You can also use “sc query
ppfilter” to see the current status of the driver (as opposed to its
configuration) – this will tell you whether PNP+kernel has loaded your
driver or not. Example outputs:
[D:] sc qc serial
[SC] GetServiceConfig SUCCESS
SERVICE_NAME: serial
TYPE : 1 KERNEL_DRIVER
START_TYPE : 1 SYSTEM_START
ERROR_CONTROL : 0 IGNORE
BINARY_PATH_NAME : system32\DRIVERS\serial.sys
LOAD_ORDER_GROUP : Extended base
TAG : 1
DISPLAY_NAME : Serial port driver
DEPENDENCIES :
SERVICE_START_NAME :
[D:] sc query serial
SERVICE_NAME: serial
TYPE : 1 KERNEL_DRIVER
STATE : 4 RUNNING
(STOPPABLE,NOT_PAUSABLE,IGNORES_SHUTDOWN)
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0
If you can’t get your system to this point, where you can verify that the
driver entry has been created and the state is RUNNING, then you know that
your driver is not being loaded by the OS.
INF files are maddening. They are poorly documented, and you don’t get much
diagnostic output from the apps that use them. One of the places you can
look, though, is at the file %systemroot%\setupapi.log. The SetupDi*
functions write to this file, and these are what Device Manager uses to
install device drivers. The Windows DDK provides some info on interpreting
this file, too. See:
*
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/install/hh/
install/troubleshoot_836ef6f8-9331-4228-8b49-65484adef442.xml.asp -
Interpreting setupapi.log
*
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/install/hh/
install/troubleshoot_9cef0df9-240c-4d89-b696-8b404098ba83.xml.asp - Using
SetupAPI logging
*
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/install/hh/
install/troubleshoot_66a07114-953e-49aa-bebf-f9b4ca60a6dd.xml.asp - How to
control how much detail is written to this log file
So, ok, let’s assume that the driver is properly installed. The next thing
to do is to verify this using KD/WINDBG. First, break in and do this:
bu ppfilter!DriverEntry
“bu” sets up an “unresolved” breakpoint, and is very useful. The debugger
will attempt to resolve all unresolved breakpoints, every time a driver is
loaded/unloaded. Now, start your device (enable it in the Device Manager,
or reboot your debug target with the “.reboot” command). The breakpoint
should fire.
Also, yes, “lm” or “lm m ppfilter” should definitely list your device
driver. If your driver is not listed in its output, then your driver is
definitely not loaded.
Once you’ve gotten to that point, you can deal with whether or not symbols
are properly loading. But verifying that the driver really is installed
should be done before dealing with symbols, breakpoints, etc.
If you get stuck on any of these steps, please send a description to the
list, and I’ll try to help.
– arlie
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Stacy Meszaros
Sent: Wednesday, October 05, 2005 11:58 AM
To: Kernel Debugging Interest List
Subject: [windbg] Loading user symbols and setting breakpoints
First, let me state that I am new to WinDbg. What I have accomplished so
far is to:
1.Create a parallel port filter driver and build it with the DDK checked
build environment.
-
Establish a serial link between my host and target computers (both
running Windows XP (free not checked) )
-
set the symbol file path for Windows XP from the symbol server and my
driver - here is the path
SRV*c:\win_xp_symbols*http://msdl.microsoft.com/download/symbols;
C:\WINDDK\3790.1830\src\wdm\par_io\objchk_wxp_x86\i386;
C:\WINDDK\3790.1830\src\wdm\par_io;
C:\WINDDK\3790.1830\src\wdm\par_io\objchk_wxp_x86
- start my filter driver (the one I need to debug) on the target system - I
started it with the filtject dll that Walter Oney supplies in his companion
documentation to his book “Programming the Microsoft Windows Driver Model”
The only evidence I have that the driver has loaded is the registry
HKEY_LOCAL_MACHINE-SYSTEM-CurrentControlSet-Enum-ACPI-PNP0401-4&F29DB88&0-Up
perFilters = ppfilter, which is the name of my filter driver.
However, lm (list modules command) on the debugger of the host computer does
not list ppfilter as a module (should it??) AND
I am having problems setting a breakpoint in the driver - I can load the
source file, but when I try to set a breakpoint (by clicking on the hand
icon while the cursor is on the line where I want the break) I get this
message:
Symbol information for the current line could not be located in the
currently loaded symbols.
I have tried numerous times to reload the symbols, and ultimately, I set the
!sym noisy ‘flag’ to get the following output which is just a snippet of
what actually comes out. I’m afraid this means nothing to me - hopefully
someone out there will understand what it is trying to tell me.
DBGHELP: C:\Program Files\Debugging Tools for Windows\i81xdnt5.dll - file
not found
DBGHELP: invalid path:
SRV*c:\win_xp_symbols*http://msdl.microsoft.com/download/symbols
DBGHELP: i81xdnt5.dll not found in
C:\WINDDK\3790.1830\src\wdm\par_io\objchk_wxp_x86\i386
DBGHELP: i81xdnt5.dll not found in C:\WINDDK\3790.1830\src\wdm\par_io
DBGHELP: i81xdnt5.dll not found in
C:\WINDDK\3790.1830\src\wdm\par_io\objchk_wxp_x86
DBGENG: \SystemRoot\System32\i81xdnt5.dll - Image mapping disallowed by
non-local path.
DBGHELP: unrecognized OMF sig: b00 *** WARNING: Unable to verify timestamp
for i81xdnt5.dll
*** ERROR: Module load completed but symbols could not be loaded for
i81xdnt5.dll
DBGHELP: i81xdnt5 - no symbols loaded
.
DBGHELP: C:\WINDDK\3790.1830\src\wdm\par_io\objchk_wxp_x86\i386\NAVENG.pdb -
file not found
DBGHELP:
C:\WINDDK\3790.1830\src\wdm\par_io\objchk_wxp_x86\i386\symbols\sys\NAVENG.pd
b - file not found
DBGHELP:
C:\WINDDK\3790.1830\src\wdm\par_io\objchk_wxp_x86\i386\sys\NAVENG.pdb - file
not found
DBGHELP: C:\WINDDK\3790.1830\src\wdm\par_io\NAVENG.pdb - file not found
DBGHELP: C:\WINDDK\3790.1830\src\wdm\par_io\symbols\sys\NAVENG.pdb - file
not found
DBGHELP: C:\WINDDK\3790.1830\src\wdm\par_io\sys\NAVENG.pdb - file not found
DBGHELP: C:\WINDDK\3790.1830\src\wdm\par_io\objchk_wxp_x86\NAVENG.pdb - file
not found
DBGHELP:
C:\WINDDK\3790.1830\src\wdm\par_io\objchk_wxp_x86\symbols\sys\NAVENG.pdb -
file not found
DBGHELP: C:\WINDDK\3790.1830\src\wdm\par_io\objchk_wxp_x86\sys\NAVENG.pdb -
file not found
DBGHELP: C:\build\NAVENG.pdb - file not found
*** ERROR: Module load completed but symbols could not be loaded for
naveng.sys
.
Same kinds of messages for SYMREDRV.SYS, SYMTDI.SYS, SYMEVENT.SYS ETC ETC
And just to round out the information, my driver is loaded from Drive C of
the target machine, my symbols are loaded from Drive C of my host machine,
is this a possible problem, should the driver by on a shared network drive??
Thanks so much,
Stacy
You are currently subscribed to windbg as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com