driver annotations

i am using build 6000 ddk on windows XP and trying to add driver annotations to my driver is failing always. normal annotations like __in / __out are working , where as annotations like __drv_maxIRQL(PASSIVE_LEVEL) or any annotation begining with __drv is not working even though i included Driverspecs.h . should i include any other header file ?

There seems to be no working sample with these annotations, or how should this be done. any help on how this should be done would be very helpful , thanks in advance.

rtshiva

Most of those annotations require the 6001 WDK.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

wrote in message news:xxxxx@ntdev…
> i am using build 6000 ddk on windows XP and trying to add driver
> annotations to my driver is failing always. normal annotations like in
> /
out are working , where as annotations like
> __drv_maxIRQL(PASSIVE_LEVEL) or any annotation begining with__drv is not
> working even though i included Driverspecs.h . should i include any other
> header file ?
>
> There seems to be no working sample with these annotations, or how should
> this be done. any help on how this should be done would be very helpful ,
> thanks in advance.
>
> rtshiva
>

It’s also fairly easy to get the wrong version of DriverSpecs.h included
because your path is not exactly what it should be.

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Tuesday, September 04, 2007 10:03
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] driver annotations

Most of those annotations require the 6001 WDK.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

wrote in message news:xxxxx@ntdev…
> i am using build 6000 ddk on windows XP and trying to add driver
> annotations to my driver is failing always. normal annotations like
in
> /
out are working , where as annotations like
> __drv_maxIRQL(PASSIVE_LEVEL) or any annotation begining with__drv is
not
> working even though i included Driverspecs.h . should i include any
other
> header file ?
>
> There seems to be no working sample with these annotations, or how
should
> this be done. any help on how this should be done would be very
helpful ,
> thanks in advance.
>
> rtshiva
>


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

And by the time you have finished mangling your perfectly readable C
code what exactly have you accomplished?

The ‘advanced’ SAL, in my opinion of course, renders well written code
unreadable, is poorly documented, and doesn’t appear to work correctly
in some cases.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Martin O’Brien
Sent: Tuesday, September 04, 2007 10:19 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] driver annotations

It’s also fairly easy to get the wrong version of DriverSpecs.h included
because your path is not exactly what it should be.

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Tuesday, September 04, 2007 10:03
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] driver annotations

Most of those annotations require the 6001 WDK.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

wrote in message news:xxxxx@ntdev…
> i am using build 6000 ddk on windows XP and trying to add driver
> annotations to my driver is failing always. normal annotations like
in
> /
out are working , where as annotations like
> __drv_maxIRQL(PASSIVE_LEVEL) or any annotation begining with__drv is
not
> working even though i included Driverspecs.h . should i include any
other
> header file ?
>
> There seems to be no working sample with these annotations, or how
should
> this be done. any help on how this should be done would be very
helpful ,
> thanks in advance.
>
> rtshiva
>


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


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

What? You don’t think that rendering code completely unreadable by a
lot of - ahem - macros is a good idea? I think you’re being very
narrow, Mark. Personally, I have always found that nothing brings
clarity to code like profligate use of macros.

Couldn’t possibly agree more.

This one falls on my personal list of things that consume Microsoft
resources that surely could be better reallocated to improving WinDbg
documentation, even though they have nothing to do with each other,
except the same generic goal, more or less.

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Roddy, Mark
Sent: Tuesday, September 04, 2007 10:35
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] driver annotations

And by the time you have finished mangling your perfectly readable C
code what exactly have you accomplished?

The ‘advanced’ SAL, in my opinion of course, renders well written code
unreadable, is poorly documented, and doesn’t appear to work correctly
in some cases.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Martin O’Brien
Sent: Tuesday, September 04, 2007 10:19 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] driver annotations

It’s also fairly easy to get the wrong version of DriverSpecs.h included
because your path is not exactly what it should be.

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Tuesday, September 04, 2007 10:03
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] driver annotations

Most of those annotations require the 6001 WDK.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

wrote in message news:xxxxx@ntdev…
> i am using build 6000 ddk on windows XP and trying to add driver
> annotations to my driver is failing always. normal annotations like
in
> /
out are working , where as annotations like
> __drv_maxIRQL(PASSIVE_LEVEL) or any annotation begining with__drv is
not
> working even though i included Driverspecs.h . should i include any
other
> header file ?
>
> There seems to be no working sample with these annotations, or how
should
> this be done. any help on how this should be done would be very
helpful ,
> thanks in advance.
>
> rtshiva
>


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


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


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

Sorry, I have to put in a dissenting voice here. I have found PreFast to
be an outstanding tool, if I have a problem with Microsoft’s efforts here
it is that their own samples are in many cases are not PreFast clean (and
in some cases these are really bugs).

With the new annotations, I have been conservative and do not go wild on
them. But I have found uses for almost all the annotations.

It is interesting to note, that the Linux guys are making a big thing of
using static analysis tools and the US goverment is paying to have the
analysis done. If you check out the tools that Linux is using you find
they catch a subset of what PreFast does.

On WinDBG I would like to see it fixed so it worked reliably (especially
the UI). But, I much prefer to find a fix bugs by having a tool tell me
“Hey you could be getting into trouble here”, than by sitting hunched over
WinDBG to find out that oops there is a path through the code that could
produce an error.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

Mark, did you read the chapter on annotations in the WDF book? I was a
reviewer for the chapter and really pushed for it to be clear and to use
samples rather than being technical and WDK-like. If you have feedback
on how the chapter could be improved, please let us know

Thx
d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Tuesday, September 04, 2007 8:17 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] driver annotations

Sorry, I have to put in a dissenting voice here. I have found PreFast
to
be an outstanding tool, if I have a problem with Microsoft’s efforts
here
it is that their own samples are in many cases are not PreFast clean
(and
in some cases these are really bugs).

With the new annotations, I have been conservative and do not go wild on

them. But I have found uses for almost all the annotations.

It is interesting to note, that the Linux guys are making a big thing of

using static analysis tools and the US goverment is paying to have the
analysis done. If you check out the tools that Linux is using you find
they catch a subset of what PreFast does.

On WinDBG I would like to see it fixed so it worked reliably (especially

the UI). But, I much prefer to find a fix bugs by having a tool tell me

“Hey you could be getting into trouble here”, than by sitting hunched
over
WinDBG to find out that oops there is a path through the code that could

produce an error.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply


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

Er, um (a bit embarrassed) no.

I’ll read 'em and see what I think. Fully applied they still render
function headers looking like some sort of C########## nightmare of
meta-gook.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Tuesday, September 04, 2007 12:51 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] driver annotations

Mark, did you read the chapter on annotations in the WDF book? I was a
reviewer for the chapter and really pushed for it to be clear and to use
samples rather than being technical and WDK-like. If you have feedback
on how the chapter could be improved, please let us know

Thx
d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Tuesday, September 04, 2007 8:17 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] driver annotations

Sorry, I have to put in a dissenting voice here. I have found PreFast
to
be an outstanding tool, if I have a problem with Microsoft’s efforts
here
it is that their own samples are in many cases are not PreFast clean
(and
in some cases these are really bugs).

With the new annotations, I have been conservative and do not go wild on

them. But I have found uses for almost all the annotations.

It is interesting to note, that the Linux guys are making a big thing of

using static analysis tools and the US goverment is paying to have the
analysis done. If you check out the tools that Linux is using you find
they catch a subset of what PreFast does.

On WinDBG I would like to see it fixed so it worked reliably (especially

the UI). But, I much prefer to find a fix bugs by having a tool tell me

“Hey you could be getting into trouble here”, than by sitting hunched
over
WinDBG to find out that oops there is a path through the code that could

produce an error.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply


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


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

Oh and to be clear: I really like and even more to the point USE prefast
as part of our regular build process. I have no problem with prefast
other than the following:

  1. it really slows down large builds, regardless of documentation that
    says it doesn’t.

  2. you cannot convince prefast to generate individual component log
    files rather than one big log files. So if your one large build produces
    N drivers that need N signatures each of which needs its own
    DTM-mandated prefast log, you can either provide the one large build
    prefast log for all of your drivers and lean on the fact that right now
    DTM is stupid about prefast logs, or run N individual diver builds in
    addition to your one large build to get prefast to run on ALL of your
    components (some of which are not drivers) and EACH of your drivers.
    Ugh. See (1).

  3. the SAL, fully applied, makes function prototypes look like some meta
    language nightmare invented by the folks over in the C###############xml
    world of burly programming. (And this from an advocate of C++ in the
    kernel.)

  4. the documentation for SAL when you find it, Doron’s pointers still
    unread, is not good.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Tuesday, September 04, 2007 12:51 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] driver annotations

Mark, did you read the chapter on annotations in the WDF book? I was a
reviewer for the chapter and really pushed for it to be clear and to use
samples rather than being technical and WDK-like. If you have feedback
on how the chapter could be improved, please let us know

Thx
d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Tuesday, September 04, 2007 8:17 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] driver annotations

Sorry, I have to put in a dissenting voice here. I have found PreFast
to
be an outstanding tool, if I have a problem with Microsoft’s efforts
here
it is that their own samples are in many cases are not PreFast clean
(and
in some cases these are really bugs).

With the new annotations, I have been conservative and do not go wild on

them. But I have found uses for almost all the annotations.

It is interesting to note, that the Linux guys are making a big thing of

using static analysis tools and the US goverment is paying to have the
analysis done. If you check out the tools that Linux is using you find
they catch a subset of what PreFast does.

On WinDBG I would like to see it fixed so it worked reliably (especially

the UI). But, I much prefer to find a fix bugs by having a tool tell me

“Hey you could be getting into trouble here”, than by sitting hunched
over
WinDBG to find out that oops there is a path through the code that could

produce an error.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply


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


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

Have you tried the /log option to put the xml and txt in a different
location? Run each driver build in a different instance of cmd.exe and put
the logs in there. I have not tried lately, but it should work. I hope the
next DTM will use the txt file instead of the stripped xml. That will force
the builds to create the prefast logs at the same time as the real build is
run since the txt contains a hash of the output driver. Now, you can submit
any xml file from any build of any product to get it accepted. The strip
script removes all file names, and the specific error and warnings from the
xml file.


David J. Craig
Engineer, Sr. Staff Software Systems
Broadcom Corporation

“Roddy, Mark” wrote in message news:xxxxx@ntdev…
Oh and to be clear: I really like and even more to the point USE prefast
as part of our regular build process. I have no problem with prefast
other than the following:

1) it really slows down large builds, regardless of documentation that
says it doesn’t.

2) you cannot convince prefast to generate individual component log
files rather than one big log files. So if your one large build produces
N drivers that need N signatures each of which needs its own
DTM-mandated prefast log, you can either provide the one large build
prefast log for all of your drivers and lean on the fact that right now
DTM is stupid about prefast logs, or run N individual diver builds in
addition to your one large build to get prefast to run on ALL of your
components (some of which are not drivers) and EACH of your drivers.
Ugh. See (1).

3) the SAL, fully applied, makes function prototypes look like some meta
language nightmare invented by the folks over in the C###############xml
world of burly programming. (And this from an advocate of C++ in the
kernel.)

4) the documentation for SAL when you find it, Doron’s pointers still
unread, is not good.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Tuesday, September 04, 2007 12:51 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] driver annotations

Mark, did you read the chapter on annotations in the WDF book? I was a
reviewer for the chapter and really pushed for it to be clear and to use
samples rather than being technical and WDK-like. If you have feedback
on how the chapter could be improved, please let us know

Thx
d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Tuesday, September 04, 2007 8:17 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] driver annotations

Sorry, I have to put in a dissenting voice here. I have found PreFast
to
be an outstanding tool, if I have a problem with Microsoft’s efforts
here
it is that their own samples are in many cases are not PreFast clean
(and
in some cases these are really bugs).

With the new annotations, I have been conservative and do not go wild on

them. But I have found uses for almost all the annotations.

It is interesting to note, that the Linux guys are making a big thing of

using static analysis tools and the US goverment is paying to have the
analysis done. If you check out the tools that Linux is using you find
they catch a subset of what PreFast does.

On WinDBG I would like to see it fixed so it worked reliably (especially

the UI). But, I much prefer to find a fix bugs by having a tool tell me

“Hey you could be getting into trouble here”, than by sitting hunched
over
WinDBG to find out that oops there is a path through the code that could

produce an error.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply


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


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

This is my issue with it as well; it’s just renders reading source code,
especially if it is not your own, extremely painful. I basically like
PreFAST, assuming that it has been run from the beginning on the source,
but in order to compile clean, in my opinion, one has to make additional
changes to source, most of which are legitimate improvement, but there
are still many that just aren’t important, and a fair number that are
irrelevant and get pragma’d, which further reduces readability. While
the tool overall does a really nice job of finding some errors that
would indeed be harder to find at runtime, fundamentally, I just don’t
see seriously impacting the appearance of source code for a tool, really
any tool, but especially one that is tedious to use (pretty much
unavoidably with any tool of this type), and for errors that certainly
can be found by other means. Given that there is basically no choice in
fundamental tools it the case of kernel work, annotations mess with what
I consider cardinal - my habits and pecadillos, good, bad or otherwise.

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Roddy, Mark
Sent: Tuesday, September 04, 2007 16:19
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] driver annotations

Er, um (a bit embarrassed) no.

I’ll read 'em and see what I think. Fully applied they still render
function headers looking like some sort of C########## nightmare of
meta-gook.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Tuesday, September 04, 2007 12:51 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] driver annotations

Mark, did you read the chapter on annotations in the WDF book? I was a
reviewer for the chapter and really pushed for it to be clear and to use
samples rather than being technical and WDK-like. If you have feedback
on how the chapter could be improved, please let us know

Thx
d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Tuesday, September 04, 2007 8:17 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] driver annotations

Sorry, I have to put in a dissenting voice here. I have found PreFast
to
be an outstanding tool, if I have a problem with Microsoft’s efforts
here
it is that their own samples are in many cases are not PreFast clean
(and
in some cases these are really bugs).

With the new annotations, I have been conservative and do not go wild on

them. But I have found uses for almost all the annotations.

It is interesting to note, that the Linux guys are making a big thing of

using static analysis tools and the US goverment is paying to have the
analysis done. If you check out the tools that Linux is using you find
they catch a subset of what PreFast does.

On WinDBG I would like to see it fixed so it worked reliably (especially

the UI). But, I much prefer to find a fix bugs by having a tool tell me

“Hey you could be getting into trouble here”, than by sitting hunched
over
WinDBG to find out that oops there is a path through the code that could

produce an error.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply


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


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


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

I think if done correctly it can be manageable. I like the KMDF style
where the annotation is on its own line so you can easily skip every
other line if you are scanning for parameters. For instance

__drv_maxIRQL(DISPATCH_LEVEL)
VOID
FORCEINLINE
WdfDeviceInitSetPnpPowerEventCallbacks(
__in
PWDFDEVICE_INIT DeviceInit,
__in
PWDF_PNPPOWER_EVENT_CALLBACKS PnpPowerEventCallbacks
);

Of course we are now delving into a style discussion which means that
every one has 3 opinions and it could explode uncontrollably :wink:

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Roddy, Mark
Sent: Tuesday, September 04, 2007 1:19 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] driver annotations

Er, um (a bit embarrassed) no.

I’ll read 'em and see what I think. Fully applied they still render
function headers looking like some sort of C########## nightmare of
meta-gook.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Tuesday, September 04, 2007 12:51 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] driver annotations

Mark, did you read the chapter on annotations in the WDF book? I was a
reviewer for the chapter and really pushed for it to be clear and to use
samples rather than being technical and WDK-like. If you have feedback
on how the chapter could be improved, please let us know

Thx
d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Tuesday, September 04, 2007 8:17 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] driver annotations

Sorry, I have to put in a dissenting voice here. I have found PreFast
to
be an outstanding tool, if I have a problem with Microsoft’s efforts
here
it is that their own samples are in many cases are not PreFast clean
(and
in some cases these are really bugs).

With the new annotations, I have been conservative and do not go wild on

them. But I have found uses for almost all the annotations.

It is interesting to note, that the Linux guys are making a big thing of

using static analysis tools and the US goverment is paying to have the
analysis done. If you check out the tools that Linux is using you find
they catch a subset of what PreFast does.

On WinDBG I would like to see it fixed so it worked reliably (especially

the UI). But, I much prefer to find a fix bugs by having a tool tell me

“Hey you could be getting into trouble here”, than by sitting hunched
over
WinDBG to find out that oops there is a path through the code that could

produce an error.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply


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


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


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

So to be clear about this issue:

Suppose you have a large number of components that include signable drivers
and libraries. You use a single makefile driven automated build process that
rebuilds components nightly. Your intention is to 1) run prefast on all
components in order to enforce prefast clean builds; 2) generate separate
log files for each signable driver.

The only way I have found to do both (1) and (2) is to run a prefast build
over all components and then run separate individual prefast builds for each
signable driver. That means that my overnight build pays both the
considerable time overhead for the full build of all components and the
additional overhead of N separate signable driver builds. As far as I know,
there is no way around this.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-299360-
xxxxx@lists.osr.com] On Behalf Of David J. Craig
Sent: Tuesday, September 04, 2007 4:45 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] driver annotations

Have you tried the /log option to put the xml and txt in a different
location? Run each driver build in a different instance of cmd.exe and
put
the logs in there. I have not tried lately, but it should work. I
hope the
next DTM will use the txt file instead of the stripped xml. That will
force
the builds to create the prefast logs at the same time as the real
build is
run since the txt contains a hash of the output driver. Now, you can
submit
any xml file from any build of any product to get it accepted. The
strip
script removes all file names, and the specific error and warnings from
the
xml file.


David J. Craig
Engineer, Sr. Staff Software Systems
Broadcom Corporation

“Roddy, Mark” wrote in message
> news:xxxxx@ntdev…
> Oh and to be clear: I really like and even more to the point USE
> prefast
> as part of our regular build process. I have no problem with prefast
> other than the following:
>
> 1) it really slows down large builds, regardless of documentation that
> says it doesn’t.
>
> 2) you cannot convince prefast to generate individual component log
> files rather than one big log files. So if your one large build
> produces
> N drivers that need N signatures each of which needs its own
> DTM-mandated prefast log, you can either provide the one large build
> prefast log for all of your drivers and lean on the fact that right now
> DTM is stupid about prefast logs, or run N individual diver builds in
> addition to your one large build to get prefast to run on ALL of your
> components (some of which are not drivers) and EACH of your drivers.
> Ugh. See (1).
>
> 3) the SAL, fully applied, makes function prototypes look like some
> meta
> language nightmare invented by the folks over in the
> C###############xml
> world of burly programming. (And this from an advocate of C++ in the
> kernel.)
>
> 4) the documentation for SAL when you find it, Doron’s pointers still
> unread, is not good.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
> Sent: Tuesday, September 04, 2007 12:51 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] driver annotations
>
> Mark, did you read the chapter on annotations in the WDF book? I was a
> reviewer for the chapter and really pushed for it to be clear and to
> use
> samples rather than being technical and WDK-like. If you have feedback
> on how the chapter could be improved, please let us know
>
> Thx
> d
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
> Sent: Tuesday, September 04, 2007 8:17 AM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] driver annotations
>
> Sorry, I have to put in a dissenting voice here. I have found PreFast
> to
> be an outstanding tool, if I have a problem with Microsoft’s efforts
> here
> it is that their own samples are in many cases are not PreFast clean
> (and
> in some cases these are really bugs).
>
> With the new annotations, I have been conservative and do not go wild
> on
>
> them. But I have found uses for almost all the annotations.
>
> It is interesting to note, that the Linux guys are making a big thing
> of
>
> using static analysis tools and the US goverment is paying to have the
> analysis done. If you check out the tools that Linux is using you find
> they catch a subset of what PreFast does.
>
> On WinDBG I would like to see it fixed so it worked reliably
> (especially
>
> the UI). But, I much prefer to find a fix bugs by having a tool tell
> me
>
> “Hey you could be getting into trouble here”, than by sitting hunched
> over
> WinDBG to find out that oops there is a path through the code that
> could
>
> produce an error.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
> Remove StopSpam to reply
>
>
>
> —
> 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
>
> —
> 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
>
>
>
> —
> 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

well not to intrude on the hot discussion guys :slight_smile: but other than Don’s comment none of the other replys seem to be for me.
does driver annotaions work on wdk build 6000 ?
and regarding the documentation for this why does white paper on “prefast annotations” available at http://www.microsoft.com/whdc/DevTools/tools/annotations.mspx , which is a word for word copy of chapter 23 on wdf book does not say anything about the requirement of wdk ? or has any complete sample ?

The _drv* annotations will work in the next WDK after the 6000 WDK.
The 6000 WDK does not contain the definitions you need.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Tuesday, September 04, 2007 8:40 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] driver annotations

well not to intrude on the hot discussion guys :slight_smile: but other than Don’s
comment none of the other replys seem to be for me.
does driver annotaions work on wdk build 6000 ?
and regarding the documentation for this why does white paper on
“prefast annotations” available at
http://www.microsoft.com/whdc/DevTools/tools/annotations.mspx , which is
a word for word copy of chapter 23 on wdf book does not say anything
about the requirement of wdk ? or has any complete sample ?


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 info Doron :slight_smile:

If I understand correctly, (1) means to run one “prefast build” command to build everything at once. In this case you’re probably right. It is a consequence of incorrectly structured build process when prefast calls recursive build tool. I don’t understand why prefast isn’t just a tool called instead of a compiler (or along with it) from main WDK makefile and controlled by an option or build.exe command line switch.

There is a way around, of course. Create own build engine as we did. In this case WDK builder is just one possibility and is invoked per node by build process which traverses the tree. WDK builder finally calls build or prefast depending on options. With prefast there is one log per node named according to binary. The results of build is set of binaries and optional data as symbols, BSC databases, prefast logs etc.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]


From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Mark Roddy[SMTP:xxxxx@hollistech.com]
Reply To: Windows System Software Devs Interest List
Sent: Wednesday, September 05, 2007 3:54 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] driver annotations

So to be clear about this issue:

Suppose you have a large number of components that include signable drivers
and libraries. You use a single makefile driven automated build process that
rebuilds components nightly. Your intention is to 1) run prefast on all
components in order to enforce prefast clean builds; 2) generate separate
log files for each signable driver.

The only way I have found to do both (1) and (2) is to run a prefast build
over all components and then run separate individual prefast builds for each
signable driver. That means that my overnight build pays both the
considerable time overhead for the full build of all components and the
additional overhead of N separate signable driver builds. As far as I know,
there is no way around this.

> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:bounce-299360-
> xxxxx@lists.osr.com] On Behalf Of David J. Craig
> Sent: Tuesday, September 04, 2007 4:45 PM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] driver annotations
>
> Have you tried the /log option to put the xml and txt in a different
> location? Run each driver build in a different instance of cmd.exe and
> put
> the logs in there. I have not tried lately, but it should work. I
> hope the
> next DTM will use the txt file instead of the stripped xml. That will
> force
> the builds to create the prefast logs at the same time as the real
> build is
> run since the txt contains a hash of the output driver. Now, you can
> submit
> any xml file from any build of any product to get it accepted. The
> strip
> script removes all file names, and the specific error and warnings from
> the
> xml file.
>
> –
> David J. Craig
> Engineer, Sr. Staff Software Systems
> Broadcom Corporation
>
>
> “Roddy, Mark” wrote in message
> > news:xxxxx@ntdev…
> > Oh and to be clear: I really like and even more to the point USE
> > prefast
> > as part of our regular build process. I have no problem with prefast
> > other than the following:
> >
> > 1) it really slows down large builds, regardless of documentation that
> > says it doesn’t.
> >
> > 2) you cannot convince prefast to generate individual component log
> > files rather than one big log files. So if your one large build
> > produces
> > N drivers that need N signatures each of which needs its own
> > DTM-mandated prefast log, you can either provide the one large build
> > prefast log for all of your drivers and lean on the fact that right now
> > DTM is stupid about prefast logs, or run N individual diver builds in>
> > addition to your one large build to get prefast to run on ALL of your
> > components (some of which are not drivers) and EACH of your drivers.
> > Ugh. See (1).
> >
> > 3) the SAL, fully applied, makes function prototypes look like some
> > meta
> > language nightmare invented by the folks over in the
> > C###############xml
> > world of burly programming. (And this from an advocate of C++ in the
> > kernel.)
> >
> > 4) the documentation for SAL when you find it, Doron’s pointers still
> > unread, is not good.
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
> > Sent: Tuesday, September 04, 2007 12:51 PM
> > To: Windows System Software Devs Interest List
> > Subject: RE: [ntdev] driver annotations
> >
> > Mark, did you read the chapter on annotations in the WDF book? I was a
> > reviewer for the chapter and really pushed for it to be clear and to
> > use
> > samples rather than being technical and WDK-like. If you have feedback
> > on how the chapter could be improved, please let us know
> >
> > Thx
> > d
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
> > Sent: Tuesday, September 04, 2007 8:17 AM
> > To: Windows System Software Devs Interest List
> > Subject: Re:[ntdev] driver annotations
> >
> > Sorry, I have to put in a dissenting voice here. I have found PreFast
> > to
> > be an outstanding tool, if I have a problem with Microsoft’s efforts
> > here
> > it is that their own samples are in many cases are not PreFast clean
> > (and
> > in some cases these are really bugs).
> >
> > With the new annotations, I have been conservative and do not go wild
> > on
> >
> > them. But I have found uses for almost all the annotations.
> >
> > It is interesting to note, that the Linux guys are making a big thing
> > of
> >
> > using static analysis tools and the US goverment is paying to have the
> > analysis done. If you check out the tools that Linux is using you find
> > they catch a subset of what PreFast does.
> >
> > On WinDBG I would like to see it fixed so it worked reliably
> > (especially
> >
> > the UI). But, I much prefer to find a fix bugs by having a tool tell
> > me
> >
> > “Hey you could be getting into trouble here”, than by sitting hunched
> > over
> > WinDBG to find out that oops there is a path through the code that
> > could
> >
> > produce an error.
> >
> >
> > –
> > Don Burn (MVP, Windows DDK)
> > Windows 2k/XP/2k3 Filesystem and Driver Consulting
> > Website: http://www.windrvr.com
> > Blog: http://msmvps.com/blogs/WinDrvr
> > Remove StopSpam to reply
> >
> >
> >
> > —
> > 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
> >
> > —
> > 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
> >
> >
> >
> > —
> > 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
>
>
>
> —
> 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
>

I forwarded the issue on to the PFD folks. This is more of a tool issue
then the drivers addition to the tool, but we are looking into it.
While not a fantastic solution, this might be a stopgap for you. The
PFD results are stored in an XML file, it should be rather easy to break
apart the XML file into separate results files (esp in a managed
environment like C#) with a few hours of effort.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Tuesday, September 04, 2007 6:55 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] driver annotations

So to be clear about this issue:

Suppose you have a large number of components that include signable
drivers
and libraries. You use a single makefile driven automated build process
that
rebuilds components nightly. Your intention is to 1) run prefast on all
components in order to enforce prefast clean builds; 2) generate
separate
log files for each signable driver.

The only way I have found to do both (1) and (2) is to run a prefast
build
over all components and then run separate individual prefast builds for
each
signable driver. That means that my overnight build pays both the
considerable time overhead for the full build of all components and the
additional overhead of N separate signable driver builds. As far as I
know,
there is no way around this.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-299360-
xxxxx@lists.osr.com] On Behalf Of David J. Craig
Sent: Tuesday, September 04, 2007 4:45 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] driver annotations

Have you tried the /log option to put the xml and txt in a different
location? Run each driver build in a different instance of cmd.exe
and
put
the logs in there. I have not tried lately, but it should work. I
hope the
next DTM will use the txt file instead of the stripped xml. That will
force
the builds to create the prefast logs at the same time as the real
build is
run since the txt contains a hash of the output driver. Now, you can
submit
any xml file from any build of any product to get it accepted. The
strip
script removes all file names, and the specific error and warnings
from
the
xml file.


David J. Craig
Engineer, Sr. Staff Software Systems
Broadcom Corporation

“Roddy, Mark” wrote in message
> news:xxxxx@ntdev…
> Oh and to be clear: I really like and even more to the point USE
> prefast
> as part of our regular build process. I have no problem with prefast
> other than the following:
>
> 1) it really slows down large builds, regardless of documentation that
> says it doesn’t.
>
> 2) you cannot convince prefast to generate individual component log
> files rather than one big log files. So if your one large build
> produces
> N drivers that need N signatures each of which needs its own
> DTM-mandated prefast log, you can either provide the one large build
> prefast log for all of your drivers and lean on the fact that right
now
> DTM is stupid about prefast logs, or run N individual diver builds in
> addition to your one large build to get prefast to run on ALL of your
> components (some of which are not drivers) and EACH of your drivers.
> Ugh. See (1).
>
> 3) the SAL, fully applied, makes function prototypes look like some
> meta
> language nightmare invented by the folks over in the
> C###############xml
> world of burly programming. (And this from an advocate of C++ in the
> kernel.)
>
> 4) the documentation for SAL when you find it, Doron’s pointers still
> unread, is not good.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
> Sent: Tuesday, September 04, 2007 12:51 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] driver annotations
>
> Mark, did you read the chapter on annotations in the WDF book? I was
a
> reviewer for the chapter and really pushed for it to be clear and to
> use
> samples rather than being technical and WDK-like. If you have
feedback
> on how the chapter could be improved, please let us know
>
> Thx
> d
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
> Sent: Tuesday, September 04, 2007 8:17 AM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] driver annotations
>
> Sorry, I have to put in a dissenting voice here. I have found PreFast
> to
> be an outstanding tool, if I have a problem with Microsoft’s efforts
> here
> it is that their own samples are in many cases are not PreFast clean
> (and
> in some cases these are really bugs).
>
> With the new annotations, I have been conservative and do not go wild
> on
>
> them. But I have found uses for almost all the annotations.
>
> It is interesting to note, that the Linux guys are making a big thing
> of
>
> using static analysis tools and the US goverment is paying to have the
> analysis done. If you check out the tools that Linux is using you
find
> they catch a subset of what PreFast does.
>
> On WinDBG I would like to see it fixed so it worked reliably
> (especially
>
> the UI). But, I much prefer to find a fix bugs by having a tool tell
> me
>
> “Hey you could be getting into trouble here”, than by sitting hunched
> over
> WinDBG to find out that oops there is a path through the code that
> could
>
> produce an error.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
> Remove StopSpam to reply
>
>
>
> —
> 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
>
> —
> 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
>
>
>
> —
> 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


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