For debugging, you should run the driver you’re developing on a test
machine and run the kernel debugger, WinDbg,
http://www.microsoft.com/ddk/debugging) on your development machine.
Connect the two machines with a null-modem serial cable (or if your test
machine is running XP and you have 1394 on both machines you can use
1394). Read WinDbg help on how to set up kernel debugging. If you know
the com port you’ve plugged your serial line into on each machine then
it’s very easy to set up. After plugging in your serial cable use
HyperTerm on both machines to connect to each other and ensure that you
know exactly which com ports the cable is plugged into and which baud
rate works for communications. Start with baud 115200 and if that
doesn’t work then lower the baud rate until the hyperterms are talking.
Once you’ve ascertained working com ports and baud rate, on the test
machine you need to add two switches to your BOOT.INI entry. It’s
probably best to make a copy of your current BOOT.INI entry and edit the
copy, leaving the original as an option. The switches you add to the
BOOT.INI entry are: /DEBUGPORT=COM1 /BAUDRATE=115200 Launch WinDbg and
select Kernel Debug from the File menu, then input the appropriate baud
rate and com port. WinDbg will now wait for the kernel debugging
connection to occur. Reboot your test machine and when the loader
presents you with alternative boots select the [Debug] boot option.
WinDbg on your dev machine will now connect to the test machine.
As for the driver, you’ll find that the XP DDK Toaster filter sample
driver is a perfect working filter driver for most device classes. This
driver will work just fine on W2K on up and can be built with the W2K
DDK. You can build it as is and by changing registry settings you can
make it filter volumes, disks, or other device classes. In your case
you need to develop an upper volume filter driver. Such a driver sits
directly below the file system and above the volume devices. It
receives all I/O that is passed on by the file system and its associated
cache to the media. You can build the toaster filter sample as is and
make it an upper volume filter driver by first creating a service key
for your driver and then registering it as an upper volume filter driver
for the volume device class.
First, copy YourDriver.sys to the System32\Drivers directory.
Next create the following registry key:
HKLM\SYSTEM\CurrentControlSet\Services\YourDriver
Then in this new key create the following registry values:
Value Name Data Type Data
Group REG_SZ Pnp Filter
Start REG_DWORD 0
Type REG_DWORD 1
ErrorControl REG_DWORD 1
Finally, register as an upper volume filter by adding your driver’s name
(minus the .sys extension) to the list of filters for the volume class.
This list is found in the REG_MULTI_SZ registry value (the value won’t
exist if no filters are yet registered - in this case you need to create
the value):
HKLM\SYSTEM\CurrentControlSet\Control\Class{71A27CDD-812A-11D0-BEC7-080
02BE2092F}\UpperFilters
Hope that helps.
Nate Bushman
PowerQuest Corp.
-----Original Message-----
From: Siddharth Aggarwal [mailto:xxxxx@persistent.co.in]
Sent: Friday, December 20, 2002 6:55 AM
To: File Systems Developers
Subject: [ntfsd] debugging filter drivers
Hi,
I am trying to write a upper-level storage filter driver which will
monitor
all traffic from NTFS to disk. I am totally new to this and I have
recently
started reading Rajeev Nagar’s “File System Internals”. On the practical
side, I am having a look at FileMon and Diskperf utilities.
As a first step, I would like to build these on my machine and debug
through
the code. Could somebody guide me as to what are the necessary tools
that I
would require for the same on a NT4 box. A step wise procedure to set
things
up would be very useful.
Thanks,
Siddharth
You are currently subscribed to ntfsd as: xxxxx@powerquest.com
To unsubscribe send a blank email to %%email.unsub%%