In the past I have run PREfast manually by specifying it before the build command:
prefast build -Zc
> prefast view
Recently I tried using the OACR monitor that starts automatically when you open a build command window. The OACR monitor provides very different results from an explicit ‘prefast build’. In both cases I verified the filter was set to show all defects. The OACR monitor listed 7 minor warnings, while the manual prefast command listed 53 warnings most of which were also minor noise. Oddly, the manual prefast command does not list any of the warnings shown by OACR. I am using the latest WDK (7600.16385.1).
In the past I have run PREfast manually by specifying it before the build
command:
prefast build -Zc
> prefast view
Recently I tried using the OACR monitor that starts automatically when you
open a build command window. The OACR monitor provides very different
results from an explicit ‘prefast build’. In both cases I verified the
filter was set to show all defects. The OACR monitor listed 7 minor
warnings, while the manual prefast command listed 53 warnings most of which
were also minor noise. Oddly, the manual prefast command does not list any
of the warnings shown by OACR. I am using the latest WDK (7600.16385.1).
As Martin said they use different configuration files, and OACR can mess
you up pretty badly if you are editing to fix the prefast errors and it
runs. I had a policy of never changing WDK settings since I want to
repro exactly what the customer gets, but OACR has made me break that
rule! I now go in and change the settings so OACR is off by default.
> In the past I have run PREfast manually by specifying it before the build command: > > > prefast build -Zc > > prefast view > > Recently I tried using the OACR monitor that starts automatically when you open a build command window. The OACR monitor provides very different results from an explicit ‘prefast build’. In both cases I verified the filter was set to show all defects. The OACR monitor listed 7 minor warnings, while the manual prefast command listed 53 warnings most of which were also minor noise. Oddly, the manual prefast command does not list any of the warnings shown by OACR. I am using the latest WDK (7600.16385.1). > > Is there some black magic I am missing here? > > Thank you, > > David Schwartz
I asked about the differences between OACR settings and prefast
standalone settings back when OACR was first inflicted on the WDK. The
issue is and was that a developer could get a clean bill of health
from OACR and proceed to check-in a build breaking change set to
repository as the build system, which of course is running a
standalone prefast build as it is an automated build system and not
some developer on a desktop, is not replicating what the developer is
building or vice-versa.
The issue was acknowledged and the follow up was:
Mark Roddy
On Thu, Feb 3, 2011 at 2:36 PM, wrote: > In the past I have run PREfast manually by specifying it before the build command: > > ? ? > prefast build -Zc > ? ? > prefast view > > Recently I tried using the OACR monitor that starts automatically when you open a build command window. The OACR monitor provides very different results from an explicit ‘prefast build’. In both cases I verified the filter was set to show all defects. The OACR monitor listed 7 minor warnings, while the manual prefast command listed 53 warnings most of which were also minor noise. Oddly, the manual prefast command does not list any of the warnings shown by OACR. I am using the latest WDK (7600.16385.1). > > Is there some black magic I am missing here? > > Thank you, > > David Schwartz > > > — > NTDEV is sponsored by OSR > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer >
Thanks for the quick replies. I am going back to running Prefast manually.
I thought the whole point of the WDK command windows starting the OACR monitor automatically was to make this easier for driver developers. Of course I had to change our daily build process to pass the no_oacr argument to the WDK setenv.bat file. Now I will do the same for my private build files.
The whole point of OACR was that a lot of dev’s in Microsoft would not
use PreFast. Remember OACR stands for Office Automated Code Review.
The same reluctance to PreFast resulted in the dumbed down settings for
warnings, it was interesting that at the last DDC the WDF team said they
were changing to all warnings on for their group.
> Thanks for the quick replies. I am going back to running Prefast manually. > > I thought the whole point of the WDK command windows starting the OACR monitor automatically was to make this easier for driver developers. Of course I had to change our daily build process to pass the no_oacr argument to the WDK setenv.bat file. Now I will do the same for my private build files. > > David Schwartz
Actually, the lower filter settings were originally there to indicate the MINIMUM level of tests you needed to pass clean before you could check code in. Think about it: You start by checking out a big module, you make a tiny change, you go to build it before you check it back in… you find you’ve got eight zillion Prefast warnings and errors you need to fix. The lower setting was intended to help folks slowly their code Prefast clean, without having to fix every little thing right off the bat.
I enable /W4 in my SOURCES files (the WDK default is W3) as part of the normal development cycle, and this catches a lot of issues up front. Of course you need to use pragmas to turn off all the warnings from the WDK header files.
Actually the latest WDK’s do /W4 pretty well. Of course they did that
after a lot of us started asking for /Wall which has more checks than
/W4, but trying to get it to work with the headers is a pain. The big
problem with the way Microsoft handles /W4 is that they turn off a
number of checks and leave them off. What would be nice is if they
fixed the code so the warnings did not appear, or if need be use the #pragma’s but around the construct in question, not just put the #pragma
in the start of the includes and leave things off.
> I enable /W4 in my SOURCES files (the WDK default is W3) as part of the normal development cycle, and this catches a lot of issues up front. Of course you need to use pragmas to turn off all the warnings from the WDK header files. > > David Schwartz
we are trying to get better with the pragmas and using push/pop to isolate the suppressions. as always, we are not perfect :), so i am sure there will be mistakes that leak though.