I think that sort of misses the point. WFP, for developers, is a Royal PITA.
The ‘rules’ appear to change with every OS release, and perhaps with every
service pack. My understanding is that the clampdown is just getting worse,
specifically for longhorn. On the other hand virii suck too, and certainly
loadable kernel dlls are a prime target.
Test versions of the os - as in the msdn and oem distributions, ought to
allow a simple wfp disable mechanism. (The msdn distributions could drop
this policy on activation so that your licensed production versions would be
fully protected, oem test distributions won’t even activate.)
=====================
Mark Roddy
-----Original Message-----
From: Mathieu Routhier [mailto:xxxxx@cvds.com]
Sent: Wednesday, June 16, 2004 9:38 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WFP is evil
Would it be possible, in your case, to insert a filter driver and basically
ignore the other driver instead of replacing the driver file?
I’m pretty sure you thought of that before.
Also, did you try to write an INF with a date more recent than the system
driver but the same HWID so you can “update” the driver for this device?
Mat
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bill McKenzie
Sent: Wednesday, June 16, 2004 3:45 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] WFP is evil
Have I mentioned lately that I hate WFP and the lack of any reasonable,
consistent and reliable way to turn it off?
Okay, so I am working on a driver that just happens to replace an existing
system driver. Silly me. Everything is going along fine for hours and then
suddenly I start having some issues. I end up spending close to a friggin
half an hour trying to figure out why I can’t get my symbols to match up in
WinDbg. I know it can’t be WFP because I have set the proper values in my
target’s registry, I have yet to reboot my target without a debugger hooked
up, and just to make sure I renamed all of the cab files in my
\Windows\Driver Cache directory and deleted everything in my
\Windows\System32\DllCache directory. So, there is absolutely no way it
could be WFP screwing me up right? Well no, actually it can. Despite all
of my best efforts, I made the single mistake of putting XP SP1 on my
target. SP1 adds some cab files in another directory. One of these somehow
avoided all of the rules and allowed WFP to blow away my driver when I
copied it in. Oh, but not everytime??
Once I renamed all of the new SP1 cab files all went as planned. I would
have looked to WFP right away, but I knew I had it turned off for good.
I
didn’t notice that I was replacing the same version of driver for a few
copies. Yet another half an hour of my life flushed down the ‘completely
unnecessary and highly irritating waste of my time’ toilet.
Someone please take away this scourge on all driver developers everywhere
and give us some sane way to shut this crap off once and for all!!
–
Bill McKenzie
Software Engineer - Prism 802.11 Wireless Solutions Conexant Systems, Inc.
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@cvds.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com