After running prefast I have realized that some warnings are valid ones…
Its basically that prefast has no way to figure that one out…
How do we deal with such warnings?
Regds,
-Praveen
Personally, I keep my drivers PREfast clean. The problem is yes there are
superfulous warnings, but if you do not clean them up, you need to analyze
every run to see if there are new warnings that are valid.
A lot of the warnings are easy to clean up. For instance the potentially
NULL pointer warnings (when you know the path is impossible) add the check
to the if stateement for the NULL pointer. The optimizer will remove it in
many cases in the free build so there is no cost for the additional check,
and it makes things safe. The potential unitialized variable, can easily be
handled by initialing the variable to a safe value.
For the tough ones there is #pragma to disable or enable the warning, so do
it around the offending statement.
Cleaning up PREfast warnings are pretty easy, if you want a challenge
eliminate all the warnings from PC-Lint (some of us do).
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply
“Praveen Kumar Amritaluru” wrote in message
news:xxxxx@ntdev…
> After running prefast I have realized that some warnings are valid ones…
> Its basically that prefast has no way to figure that one out…
>
> How do we deal with such warnings?
>
> Regds,
> -Praveen
>
>
> if you want a challenge eliminate all the warnings from PC-Lint
That is for sure. I was apalled PC-Lint even flags the use of “int” as a warning! But you can selectively turn on and off certain ones. I took the route of turn on all warnings, and then turn off as I encounter ones I don’t want. You can also do really nifty stuff like tell it to treat KdPrint like printf and it will check all of your format string parameters to perfection, wow! While writing code, I always compile using PC-Lint rather than use “build” which I reserve until just before test. The types of bugs you can find at compile time before doing any testing is astonishing. I wish Microsoft would make their samples lint clean. You can get lint from here:
But PREfast is still useful additionally because it has special knowledge about specific kernel call usage.
eof
wrote in message news:xxxxx@ntdev…
> That is for sure. I was apalled PC-Lint even flags the use of “int” as a
> warning! But you can selectively turn on > and off certain ones. I took
> the route of turn on all warnings, and then turn off as I encounter ones I
> don’t
> want. You can also do really nifty stuff like tell it to treat KdPrint
> like printf and it will check all of your format
> string parameters to perfection, wow! While writing code, I always compile
> using PC-Lint rather than use
> “build” which I reserve until just before test. The types of bugs you can
> find at compile time before doing any
> testing is astonishing. I wish Microsoft would make their samples lint
> clean. You can get lint from here:
PREfast is comming out with a new version in the WDK that has the ability to
annotate functions with a much more powerful set of checks than Lint has.
With these changes the best things about PC-Lint are the checks for fields
and variables the are unreferenced (but perhaps assigned), the strict sign
versus unsigned checking, and similar items. Note: I do the opposite of
you, almost every flag is on, I have a long set of items disabled for
Microsoft macros, but not much else, it takes a bit to keep things clean but
it finds bugs.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply
I think I am running the one you mention below.
I am running this on Vista.
“Don Burn” wrote in message news:xxxxx@ntdev…
>
> PREfast is comming out with a new version in the WDK that has the ability
> to annotate functions with a much more powerful set of checks than Lint
> has. With these changes the best things about PC-Lint are the checks for
> fields and variables the are unreferenced (but perhaps assigned), the
> strict sign versus unsigned checking, and similar items. Note: I do the
> opposite of you, almost every flag is on, I have a long set of items
> disabled for Microsoft macros, but not much else, it takes a bit to keep
> things clean but it finds bugs.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> http://www.windrvr.com
> Remove StopSpam from the email to reply
>
>
>
>
>
>
PC-Lint has several problems with driver code. They have no knowledge of
SEH and especially __finally{} blocks. The default is for ‘new’ to throw
C++ exceptions, though this can be overridden with a flag setting. Prefast
has problems with calls that require APCs be disabled before an ERESOURCE
can be acquired if the acquisition is not straight line code. I haven’t
looked at the WDK lately, so maybe some of this is fixed.
“Praveen Kumar Amritaluru” wrote in message
news:xxxxx@ntdev…
>I think I am running the one you mention below.
> I am running this on Vista.
>
>
> “Don Burn” wrote in message news:xxxxx@ntdev…
>
>>
>> PREfast is comming out with a new version in the WDK that has the ability
>> to annotate functions with a much more powerful set of checks than Lint
>> has. With these changes the best things about PC-Lint are the checks for
>> fields and variables the are unreferenced (but perhaps assigned), the
>> strict sign versus unsigned checking, and similar items. Note: I do the
>> opposite of you, almost every flag is on, I have a long set of items
>> disabled for Microsoft macros, but not much else, it takes a bit to keep
>> things clean but it finds bugs.
>>
>>
>> –
>> Don Burn (MVP, Windows DDK)
>> Windows 2k/XP/2k3 Filesystem and Driver Consulting
>> http://www.windrvr.com
>> Remove StopSpam from the email to reply
>>
>>
>>
>>
>>
>>
>
>
>
Note the latest version does understand SEH including __finally.
But yeah, lots of tweeks to get it setup for drivers and a lot of it is due to the DDK headers not being as clean as they could be. I am sure we are all writing the same -emacro’s. But lint is very nice for tweeking. You have excellent control over customization. So you can just ignore certain warnings in say IoSetCompletionRoutine, but still allow these warnings to be spotted elsewhere where they might be a real problem.
And Don said “PREfast is comming out with a new version in the WDK that has the ability to annotate functions with a much more powerful set of checks than Lint has”. I’ll believe it when I see it, sounds good though! I love good tools. Lint is amazing. One thing it does is look at each call you make to a function, simulating the call with each of these sets of parameters. It essentially executes your code before you do and can catch NULL dereferences, overflows, and many other problems.
LINT can also can look at all source files together to give even greater analysis. Removing unused fluff is always nice, even though the compiler/linker will do that for you, but it’s just one thing lint does. Its ability to find bugs before executing the code is why I use it. It makes for rapid development and higher quality. I like how one button push can do what otherwise requires compilation, test, bsod, debug, and do it all again to certify a fix. And sometimes that one button press can detect what might otherwise slip through and ship.
eof
Have they added a way to know that the allocation calls in the kernel are
mapped to equivalent mallocs? That was another frustrating one for me since
the docs don’t provide good examples. With tags and some that have sizes in
different locations in the parameter list, this was far more difficult than
it should have been.
wrote in message news:xxxxx@ntdev…
> Note the latest version does understand SEH including __finally.
>
> But yeah, lots of tweeks to get it setup for drivers and a lot of it is
> due to the DDK headers not being as clean as they could be. I am sure we
> are all writing the same -emacro’s. But lint is very nice for tweeking.
> You have excellent control over customization. So you can just ignore
> certain warnings in say IoSetCompletionRoutine, but still allow these
> warnings to be spotted elsewhere where they might be a real problem.
>
> And Don said “PREfast is comming out with a new version in the WDK that
> has the ability to annotate functions with a much more powerful set of
> checks than Lint has”. I’ll believe it when I see it, sounds good though!
> I love good tools. Lint is amazing. One thing it does is look at each call
> you make to a function, simulating the call with each of these sets of
> parameters. It essentially executes your code before you do and can catch
> NULL dereferences, overflows, and many other problems.
>
> LINT can also can look at all source files together to give even greater
> analysis. Removing unused fluff is always nice, even though the
> compiler/linker will do that for you, but it’s just one thing lint does.
> Its ability to find bugs before executing the code is why I use it. It
> makes for rapid development and higher quality. I like how one button push
> can do what otherwise requires compilation, test, bsod, debug, and do it
> all again to certify a fix. And sometimes that one button press can detect
> what might otherwise slip through and ship.
>
> eof
>
>
PC-Lint is a *very* good tool. Sure, it spews a truckload… but that’s what lint is all about. With patience, it catches all sorts of nastiness.
I really wish more driver devs would use PC-Lint. Then again, I really wish more driver devs would use driver verifier. So, I s’pose wishing for folks to use PC-Lint is nothing but a dream.
As Don mentioned, the current trend at MSFT is towards the use of source code annotations to clarify the use of parameters, the constraints on functions, and (in general) the intent of your code. Personally, I’m conflicted about this. There’s nothing I hate more than spending the afternoon adding __ecount’s to code I’ve already written, and SOME of the annotations are positively inscrutable. OTOH, I can certainly see how the cross-checks that good annotations provide can help automated tools find bugs… plus I can see that these annotations can even facilitate maintenance by providing unambiguous documentation for future devs.
Sigh… more typing. Perhaps I need a college-hire to do all my annotations for me 
Peter
OSR
Well first a really good article on annotation would be appreciated. I can
do the simple ones such as __in, __out, ecout, etc. But what about a
pointer to a pointer where the parameter can be null, but if not is must
point to a valid pointer which can be changed by the function being called
and can return NULL?
On PC-Lint I find the spew is pretty easy to clean up, I do a little each
day when I hit a time when I find I am not being real productive.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply
wrote in message news:xxxxx@ntdev…
>
> PC-Lint is a very good tool. Sure, it spews a truckload… but that’s
> what lint is all about. With patience, it catches all sorts of nastiness.
>
> I really wish more driver devs would use PC-Lint. Then again, I really
> wish more driver devs would use driver verifier. So, I s’pose wishing for
> folks to use PC-Lint is nothing but a dream.
>
> As Don mentioned, the current trend at MSFT is towards the use of source
> code annotations to clarify the use of parameters, the constraints on
> functions, and (in general) the intent of your code. Personally, I’m
> conflicted about this. There’s nothing I hate more than spending the
> afternoon adding __ecount’s to code I’ve already written, and SOME of the
> annotations are positively inscrutable. OTOH, I can certainly see how the
> cross-checks that good annotations provide can help automated tools find
> bugs… plus I can see that these annotations can even facilitate
> maintenance by providing unambiguous documentation for future devs.
>
> Sigh… more typing. Perhaps I need a college-hire to do all my
> annotations for me
>
> Peter
> OSR
>
>
One other comment on PREfast clean. I wish Microsoft would make their
samples PREfast clean. It is ridiculous to me that according to the data
Redmond has compiled most of the Windows crashes are 3rd party drivers, but
the samples in the DDK (and now the WDK) do not compile clean with
PREfast!!! Personally, I think they should compile clean with PREfast,
PC-Lint, /W4 and SDV!!!
Worse yet, the current WDK’s WPP tracing generates a lot fo PREfast errors
in the TMH files making it impossible to be PREfast clean with WPP!!!
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply
> ----------
From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of xxxxx@osr.com[SMTP:xxxxx@osr.com]
Reply To: Windows System Software Devs Interest List
Sent: Thursday, September 07, 2006 4:56 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] IS it a must to keep the driver prefast clean?I really wish more driver devs would use PC-Lint. Then again, I really wish more driver devs would use driver verifier. So, I s’pose wishing for folks to use PC-Lint is nothing but a dream.
Unfortunately, it costs money and the first experience with it can be discouraging. I still remember your funny NT Insider article about 7 zillions warnings produced by PC-lint. You changed your mind later but most developers never try it again. I’m unsuccessfully trying to make PC-lint mandatory for our firmware projects for years. Next round will start within few weeks
As Don mentioned, the current trend at MSFT is towards the use of source code annotations to clarify the use of parameters, the constraints on functions, and (in general) the intent of your code. Personally, I’m conflicted about this. There’s nothing I hate more than spending the afternoon adding __ecount’s to code I’ve already written, and SOME of the annotations are positively inscrutable. OTOH, I can certainly see how the cross-checks that good annotations provide can help automated tools find bugs… plus I can see that these annotations can even facilitate maintenance by providing unambiguous documentation for future devs.
But it is the same as making old sources lint ready. Annoying work which pays off many times in the future. Similarly as with traces, comments in the code etc.
Sigh… more typing. Perhaps I need a college-hire to do all my annotations for me
And then spend few years fixing all the incorrect annotations he made
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
> Have they added a way to know that the allocation calls
in the kernel are mapped to equivalent mallocs?
Yes
That was another frustrating one for me since the docs don’t provide
good examples. With tags and some that have sizes in different locations
in the parameter list, this was far more difficult than it should have been.
It still is pretty hairy. Here’s a sampling from a few of my favorites groups of lint 8 customizations every driver should use, and I’ve got lots more. The first says treat the ExFree’s just like the c runtime “free”. The second says treat ExAlloc just like malloc. And you’d want these for lookaside lists and such too.
-function( free, ExFreePool, ExFreePoolWithTag )
-sem( ExAllocatePoolWithTag, @P == malloc(2n) || @P == 0 )
-printf( 1, KdPrint ) // treat kdprint just like printf
-printf_code(wZ, UNICODE_STRING *) // define unicode format string
-sem( PsTerminateSystemThread, r_no ) // does not return
eof