I personally never use the filters for this exact reason. The problem with
filtering is you filter out a specific message because the uses you have are
all legal, then later you modify code that generates the same warning for an
illegal use, but you won’t see.
Personally, I always rework the code if possible to eliminate the warning
without the use of the #pragma, unless I absolutly cannot get the warning
supressed another way. It is interesting to note, that I know of FT firms
that using a filter on tools like this, was a fireable offense.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply
“Jonathan Ludwig” wrote in message
news:xxxxx@ntdev…
> June (or anyone else at MS that works on PreFAST),
>
> While I’ve got your attention… Am I overly paranoid in not wanting to
> use the winpft filter? The reason it concerns me is that some of the
> warnings that were filtered out looked like good checks to have in some
> scenarios.
>
> Thanks,
>
> Jonathan Ludwig
>
> “June Blender (MSFT)” wrote in message
> news:xxxxx@ntdev…
>> Jonathan, I write the WDK (formerly DDK) docs for PREfast for Drivers.
>> I’ll be sure to get this information into the docs, if it’s still valid
>> at ship time. Thanks for bringing it up.
>> –
>> June Blender (MSFT)
>> WDK Tool Docs
>> xxxxx@microsoft.com
>>
>> “Jonathan Ludwig” wrote in message
>> news:xxxxx@ntdev…
>>> Thank you Doron!
>>>
>>> I’ve figured it out. I thought I’d post my results so others can find
>>> the
>>> answer to my questions quickly. The reason I was only disabling half of
>>> the
>>> warnings was that I had two #pragma prefast statements for one function
>>> call
>>> in four different places. Only the last statement was suppressed.I then
>>> changed it from:
>>>
>>> #pragma prefast(suppress:8126, “We have no Irp here.”)
>>> #pragma prefast(suppress:309, “The access mode is always KernelMode
>>> here.”)
>>>
>>> to:
>>>
>>> #pragma prefast(suppress:8126 309, “We have no Irp here. && The access
>>> mode
>>> is always KernelMode here.”)
>>>
>>> and this worked.
>>>
>>> I also wanted to suppress 8101: The Drivers module has inferred that the
>>> current function is a DriverEntry function… So I did this:
>>>
>>> #pragma prefast(suppress:8101, “We know this is a driver”)
>>> NTSTATUS
>>> DriverEntry(
>>>
>>> Which didn’t work so I did this:
>>>
>>> #pragma prefast(suppress:8101, “We know this is a driver”)
>>> NTSTATUS DriverEntry(
>>>
>>> Thanks,
>>>
>>> Jonathan Ludwig
>>>
>>>
>>> “Doron Holan” wrote in message
>>> news:xxxxx@ntdev…
>>> A note about #pragma prefast(suppress:xxxx): this only works if the
>>> offending code is on the /immediately/ following line. If there is a
>>> blank line or comment in between the pragma and the code, the suppress
>>> will not work. Been bitten by that a few times 
…
>>>
>>> d
>>>
>>> -----Original Message-----
>>> From: xxxxx@lists.osr.com
>>> [mailto:xxxxx@lists.osr.com] On Behalf Of Jonathan Ludwig
>>> Sent: Monday, August 22, 2005 2:21 PM
>>> To: Windows System Software Devs Interest List
>>> Subject: [ntdev] Suppressing PreFAST warnings
>>>
>>> I’m in the process of adding PreFAST to our driver builds. Our build
>>> process tolerates no warnings, so this is a good way to force developers
>>> to
>>> pass PreFAST. I started with a simple driver and found and fixed a
>>> bunch of
>>> warnings, mostly benign, but a few really good changes, that have sold
>>> me on
>>> PreFAST. If you’re not using prefast on all of your drivers, do it! I
>>> found
>>> a couple of bad bugs. I may try to use it on our usermode apps too!. I
>>> narrowed it down to 8 warnings that were incorrect in the context they
>>> were
>>> in and I couldn’t code around like not using Irp->RequestorMode in a
>>> call to
>>> ObReferenceObjectByHandle for a thread object for a system thread
>>> allocated
>>> in DriverEntry or releasing a SpinLock without having required it in a
>>> CSQ
>>> ReleaseLock routine. In other words, I can’t just rearrange the code to
>>> get
>>> around them. I searched the PreFAST help and DDK sources and found code
>>>
>>> that did this:
>>>
>>> #pragma prefast(push)
>>> #pragma prefast(suppress:8126, “I have no Irp to get a RequestorMode
>>> from”)
>>> ObReferenceObjectByHandle(…
>>> #pragma prefast(pop)
>>>
>>> Unfortunately, this only worked for half of the warnings. I don’t want
>>> to
>>> disable these warnings globally, because they are valid in other
>>> contexts.
>>>
>>> I also found that the winpft filter does suppress these, but if I can
>>> get
>>> away with it, I’d rather not use the filter. May be I’m paranoid, but
>>> I’d
>>> like to see as many warnings as possible and it concerns me that the
>>> filter
>>> disable these preFAST warnings that seem very relevant to drivers.
>>>
>>> Does anyone have any suggestions on how I can disable these other
>>> warnings?
>>> Or can somebody tell me why I should just forget my paranoia and turn
>>> the
>>> winpft filter on?
>>>
>>> Thanks,
>>>
>>> Jonathan Ludwig
>>>
>>>
>>>
>>> —
>>> Questions? First check the Kernel Driver FAQ at
>>> http://www.osronline.com/article.cfm?id=256
>>>
>>> You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
>>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>>
>>>
>>>
>>
>>
>>
>
>
>