DDC - updated info for next week

NTDEV
1

Hi everyone,
DDC starts next week so wanted to do some quick updates for anyone
interested.

Registration does end tomorrow, so anyone who is interested please sign up
to come. https://microsoft.crgevents.com/DDC2008/Register/Login/default.aspx

We have added a schedule grid as a download to our Web site and posted
session descriptions and titles that you can add to your Outlook calendar in
order to build your own schedule for what you want to attend.
Grid:
http://download.microsoft.com/download/2/9/e/29edfd7f-2ad8-480f-b06e-7aba65f8b029/DDC_2008_Agenda.xlsx
Descriptions:
http://www.microsoft.com/whdc/491F34B0-E3D0-D1B1-0667-D4065525389C/sessions.aspx

Some highlights for the conference include question and answer sessions from
Steven Sinofsky and Mark Russinovich, a unique opportunity to experience a
two hour insider view of WDF from the product team (“Shared Secrets about
WDF” parts 1 and 2), architecture reviews and insight into how to create new
storage devices (“Enhanced Storage Architecture”), information about updates
in NDIS (“NDIS 6.20 Overview”), guidance about using the Windows Sideshow
driver architecture to create products (“Windows Sideshow: Building Low-Cost
Devices”), enhancements to the USB stack (“USB in Windows 7 and Beyond”) and
some new community-oriented panels where we will listen to what you have to
say about driver development and the logo program for wired USB.

We are planning a couple of evening activities - Monday from 7:00-10:00 pm
we will be enjoying an evening of bowling at Lucky Strike in Bellevue, a
cool new venue.We will have food and drinks there, and an opportunity to
meet people from the product teams and other conference attendees. Shuttle
services will be provided from the conference center and back to both the
conference center and hotel.

Tuesday from 7:00-9:00 we will hold an “Ask the Experts” event at the
conference center. Doors will open at 6:15. We will have over 31 different
feature teams from Microsoft represented at various tables and available for
discussions and questions. Food and drinks will be provided.
More information is on our Agenda Web page at the bottom of this page.
http://www.microsoft.com/whdc/491F34B0-E3D0-D1B1-0667-D4065525389C/agenda.mspx

Although we are planning an “Ask the Experts” event on Tuesday evening, DDC
experts will be available for 1:1 meetings throughout the conference. The
Kernel Korner will be staffed with Microsoft experts in various areas
according to the posted schedule. The DDC Expert Desk will be available to
help you find an expert to answer specific questions you may have, by
someone who may be at the event or may be in the product teams. We will do
our best to find an expert to help you.

We will have some labs as part to the session and have shuttles available
between building 20 and the MSCC.

I think that covers it. I sat in on all the slide reviews and the content
is going to be great! Look forward to seeing you there,
-Laura

2

Laura wrote:

Some highlights for the conference include … guidance about using
the Windows Sideshow driver architecture to create products (“Windows
Sideshow: Building Low-Cost Devices”), …

Is anyone outside of Redmond really building Windows Sideshow devices?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

3

It won’t matter if anyone outside Redmond is building them - you’ll be
inside the reality distortion field, so it will all make perfect sense
once you’re there. :wink:

Tony
OSR

4

Well no, but nor is anyone using SDV, and that seems to be the focus of the event, given that the static tools sessions (all ten of
them or whatever) have no conflicts among themselves, including duplicate sessions. The shame of this, in my opinion, is that
PREFast is such a good tool, and lumping it in with SDV is doing it no service, and perhaps just confuses people who have never used
either.

I believe that in the MSFT distortion field that Mr. Mason spoke of, the reasoning behind this is that, apparently, we just don’t
get it, because if we did, we’d be using ‘X’ right now, for all things, because it is THE answer, so let’s try one more time, and
maybe they will get it this time. Or something like that.

mm

Tim Roberts wrote:

Laura wrote:
> Some highlights for the conference include … guidance about using
> the Windows Sideshow driver architecture to create products (“Windows
> Sideshow: Building Low-Cost Devices”), …

Is anyone outside of Redmond really building Windows Sideshow devices?

5

Sounds like we could do with some “bullshit bingo” cards :slight_smile:

Every time the distortion field grows too strong, the audience hold
up the card and shout what’s on it !!

Of course, could have it printed on the OSR cookies, but we’d eat the
cookies long before extrication from the distortion field.

errr … I’ll go put the strait jacket back on.

Mark

At 11:33 25/09/2008, Martin O’Brien wrote:

Well no, but nor is anyone using SDV, and that seems to be the focus
of the event, given that the static tools sessions (all ten of them
or whatever) have no conflicts among themselves, including duplicate
sessions. The shame of this, in my opinion, is that PREFast is such
a good tool, and lumping it in with SDV is doing it no service, and
perhaps just confuses people who have never used either.

I believe that in the MSFT distortion field that Mr. Mason spoke of,
the reasoning behind this is that, apparently, we just don’t get it,
because if we did, we’d be using ‘X’ right now, for all things,
because it is THE answer, so let’s try one more time, and maybe they
will get it this time. Or something like that.

mm

Tim Roberts wrote:
>Laura wrote:
>>Some highlights for the conference include … guidance about using
>>the Windows Sideshow driver architecture to create products (“Windows
>>Sideshow: Building Low-Cost Devices”), …
>Is anyone outside of Redmond really building Windows Sideshow devices?

6

Martin,

I agree no one is using SDV, but having worked in code optimization
which uses the same base technology this stuff is extremely hard. I do
support the purposes of the tool, and whenever a new version comes out I try
it.

On PreFast I have been a big supporter but to be honest the newest
versions annoy me. A lot of the annoyance is not the PreFast teams fault,
but instead the owners of Microsoft includes that do not make their code
PreFast clean. I find it ironic that ntstrsafe.h has bugs in it that
PreFast finds, when Microsoft says use safe strings! The other annoyance I
find is that the annotations are a pain to use, and that some warnings are
hard to suppress other than #pragma’s around the line.

The reason for the wandering above is I am not against hearing more
from the SDV folks because in the past they were willing to listen to the
problems. As I said this is hard stuff to do, and it will take a lot of
effort from both the developers and the community to get it right. I just
wish that we could fix PreFast annotations so it was easy to use also.

–
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

“Martin O’Brien” wrote in message
news:xxxxx@ntdev…
> Well no, but nor is anyone using SDV, and that seems to be the focus of
> the event, given that the static tools sessions (all ten of them or
> whatever) have no conflicts among themselves, including duplicate
> sessions. The shame of this, in my opinion, is that PREFast is such a
> good tool, and lumping it in with SDV is doing it no service, and perhaps
> just confuses people who have never used either.
>

7

I agree with Mr. O’Brien. The focus of the DDC is clearly static analysis, because if we’re not using it, that’s obviously because we’re dumb out here and slow on the uptake.

The distortion field is clearly alive and well. Sigh!

As usual, Microsoft would be well served by REALLY understanding what we DO out here. They THINK they understand, but they don’t.

As I’ve said before, I like and respect the folks who do SDV and PreFast. I really do. They’re very smart… most of them smarter than me. But they’d just be soooo surprised if they could spend some time, like maybe a solid 3 months, out in the real world trying to USE these tools to do useful work for pay.

PreFast: Amusing, sometimes useful, but annoying. For maximum effectiveness and minimum annoyance have to “buy in” to using it throughout the life-cycle of your driver. You have to believe that SAL notations are a good thing. I am not convinced.

SDV: Complicated, difficult, and VERY annoying. I have never – not once – been able to get SDV to disclose a meaningful error to me. This is true even when I try to create specific errors in my code that the documentation CLEARLY says SDV will detect and report.

I *intellectually* understand who/why/where these tools could be useful. I suspect that it’ll take about another ten years before I find them useful in practical situations, however.

If I were king of the group responsible for these tools, I would redirect their efforts to building clever and comprehensive DYNAMIC analysis and debugging tools that we can use out here in the real world, without significant up-front “adopt it for life or it’s not useful”, requirements.

These dynamic tools are really what the community needs at this point. WAY MORE checks in KMDF Verifier. A LOCKING HIERARCHY VALIDATION scheme (OSR has a patent pending on one, we’ll be happy to license it) for ALL sorts of locks. MORE speculative checking options in Driver Verifier. Resurrect Call Usage Verifier – now discontinued. And… just to show you how easy it is to miss the simple stuff: WHY are things like IoGetNextIrpStackLocation still MACROs?? Why are ANY of the DDK functions macros? When they’re macros, they’re impossible to “hook” with Verifier. At LEAST make them functions, and mark them as “inline” in the free build. There is NO additional overhead to this, and much to be gained. This seems obvious to me (and, in fact, was an actual work item for the DDK back, oh, about a thousand years ago).

If any of the static analysis folks would like to come to OSR to spend a couple of months writing code on real customer projects, and see “how the other half lives”, I’ll be happy to provide the office and project management. I’ll even give them free lunch for the duration of their stay (like every other OSR employee). Maybe they’ll gain some insight. Then again, maybe they’ll convince us that PreFast or SDV will make our drivers or file systems better and I’ll have to write a big long article in The NT Insider about how SDV changed my life.

Peter
OSR

8

+1

I’d add that some complete and accurate WinDbg documentation might be nice, as would the same for the KRM.

mm

xxxxx@osr.com wrote:

I agree with Mr. O’Brien. The focus of the DDC is clearly static analysis, because if we’re not using it, that’s obviously because we’re dumb out here and slow on the uptake.

The distortion field is clearly alive and well. Sigh!

As usual, Microsoft would be well served by REALLY understanding what we DO out here. They THINK they understand, but they don’t.

As I’ve said before, I like and respect the folks who do SDV and PreFast. I really do. They’re very smart… most of them smarter than me. But they’d just be soooo surprised if they could spend some time, like maybe a solid 3 months, out in the real world trying to USE these tools to do useful work for pay.

PreFast: Amusing, sometimes useful, but annoying. For maximum effectiveness and minimum annoyance have to “buy in” to using it throughout the life-cycle of your driver. You have to believe that SAL notations are a good thing. I am not convinced.

SDV: Complicated, difficult, and VERY annoying. I have never – not once – been able to get SDV to disclose a meaningful error to me. This is true even when I try to create specific errors in my code that the documentation CLEARLY says SDV will detect and report.

I *intellectually* understand who/why/where these tools could be useful. I suspect that it’ll take about another ten years before I find them useful in practical situations, however.

If I were king of the group responsible for these tools, I would redirect their efforts to building clever and comprehensive DYNAMIC analysis and debugging tools that we can use out here in the real world, without significant up-front “adopt it for life or it’s not useful”, requirements.

These dynamic tools are really what the community needs at this point. WAY MORE checks in KMDF Verifier. A LOCKING HIERARCHY VALIDATION scheme (OSR has a patent pending on one, we’ll be happy to license it) for ALL sorts of locks. MORE speculative checking options in Driver Verifier. Resurrect Call Usage Verifier – now discontinued. And… just to show you how easy it is to miss the simple stuff: WHY are things like IoGetNextIrpStackLocation still MACROs?? Why are ANY of the DDK functions macros? When they’re macros, they’re impossible to “hook” with Verifier. At LEAST make them functions, and mark them as “inline” in the free build. There is NO additional overhead to this, and much to be gained. This seems obvious to me (and, in fact, was an actual work item for the DDK back, oh, about a thousand years ago).

If any of the static analysis folks would like to come to OSR to spend a couple of months writing code on real customer projects, and see “how the other half lives”, I’ll be happy to provide the office and project management. I’ll even give them free lunch for the duration of their stay (like every other OSR employee). Maybe they’ll gain some insight. Then again, maybe they’ll convince us that PreFast or SDV will make our drivers or file systems better and I’ll have to write a big long article in The NT Insider about how SDV changed my life.

Peter
OSR

9

The number of tools that would be nice out of Microsoft is too large to
post, a few over the years I have suggested to them are:

  1. Code coverage - yes Bullseye is nice, but even with it we need faut
    injection. Note they looked at fault injection and rejected it because
    people would have to modify their code (I guess annotations don’t count as
    modification)

  2. Lock contention measurement - the number of times I have seen people
    propose a gazzilion locks for a driver because they do not want contention.
    A tool that shows how long locks are held (max and average) and how long
    someone waits for locks would probably slow down some of these lets have a
    seperate lock for everything.

  3. Call usage verifier - this was a godd tool, it could have been expanded
    a lot. Come on Redmond either bring it forward, or release it back to OSR
    so they can have the OSR WDK (compared to the OSR DDK that CUV came from).

Perhaps we need an email list for such tools, complete with a legal
agreement that releases any thing people say, so Redmond or others can act
on it.

–
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

“Martin O’Brien” wrote in message
news:xxxxx@ntdev…
> +1
>
> I’d add that some complete and accurate WinDbg documentation might be
> nice, as would the same for the KRM.
>
>
> mm
>
> xxxxx@osr.com wrote:
>> I agree with Mr. O’Brien. The focus of the DDC is clearly static
>> analysis, because if we’re not using it, that’s obviously because we’re
>> dumb out here and slow on the uptake.
>>
>> The distortion field is clearly alive and well. Sigh!
>>
>> As usual, Microsoft would be well served by REALLY understanding what we
>> DO out here. They THINK they understand, but they don’t.
>>
>> As I’ve said before, I like and respect the folks who do SDV and PreFast.
>> I really do. They’re very smart… most of them smarter than me. But
>> they’d just be soooo surprised if they could spend some time, like maybe
>> a solid 3 months, out in the real world trying to USE these tools to do
>> useful work for pay.
>>
>> PreFast: Amusing, sometimes useful, but annoying. For maximum
>> effectiveness and minimum annoyance have to “buy in” to using it
>> throughout the life-cycle of your driver. You have to believe that SAL
>> notations are a good thing. I am not convinced.
>>
>> SDV: Complicated, difficult, and VERY annoying. I have never – not
>> once – been able to get SDV to disclose a meaningful error to me. This
>> is true even when I try to create specific errors in my code that the
>> documentation CLEARLY says SDV will detect and report.
>>
>> I intellectually understand who/why/where these tools could be useful.
>> I suspect that it’ll take about another ten years before I find them
>> useful in practical situations, however.
>>
>> If I were king of the group responsible for these tools, I would redirect
>> their efforts to building clever and comprehensive DYNAMIC analysis and
>> debugging tools that we can use out here in the real world, without
>> significant up-front “adopt it for life or it’s not useful”,
>> requirements.
>>
>> These dynamic tools are really what the community needs at this point.
>> WAY MORE checks in KMDF Verifier. A LOCKING HIERARCHY VALIDATION scheme
>> (OSR has a patent pending on one, we’ll be happy to license it) for ALL
>> sorts of locks. MORE speculative checking options in Driver Verifier.
>> Resurrect Call Usage Verifier – now discontinued. And… just to show
>> you how easy it is to miss the simple stuff: WHY are things like
>> IoGetNextIrpStackLocation still MACROs?? Why are ANY of the DDK
>> functions macros? When they’re macros, they’re impossible to “hook” with
>> Verifier. At LEAST make them functions, and mark them as “inline” in the
>> free build. There is NO additional overhead to this, and much to be
>> gained. This seems obvious to me (and, in fact, was an actual work item
>> for the DDK back, oh, about a thousand years ago).
>>
>> If any of the static analysis folks would like to come to OSR to spend a
>> couple of months writing code on real customer projects, and see “how the
>> other half lives”, I’ll be happy to provide the office and project
>> management. I’ll even give them free lunch for the duration of their
>> stay (like every other OSR employee). Maybe they’ll gain some insight.
>> Then again, maybe they’ll convince us that PreFast or SDV will make our
>> drivers or file systems better and I’ll have to write a big long article
>> in The NT Insider about how SDV changed my life.
>>
>> Peter
>> OSR
>

10



While we’re on the crusade of real world vs. Redmond, I’ll throw this one in:

Please test the debugging tools as they will be used by customers.

Every WinDbg release for the past few releases has successively broken more and more highly useful debugger extensons because they are changed to rely on private symbols.

It would be nice if, and my head’s probably in the clouds a bit here, if for a day, a week, whatever, Microsoft internal had to only use publicly available debugger extensions, the public symbol server, etc.

Maybe that will cause stuff like !address being broken in kernel mode (private symbols missing), wow64 typeinfo being omitted in public symbol drops for ntdll, totally destroyin debuggablity on user mode 32bit processes on 64bit systems (this one in particular happens so often now that it’s not even funny; it seems that about every service pack they get broken until some kind soul at Microsoft who should totally not have to deal with this sort of problem again and again plays the hero and fixes it for the rest of us), etc.

At least Microsoft actually tries, which is a heck of a lot better than most of the companies out there in my experience – but again and again, I get the nagging feeling that so many people are wrapped up in the tools and utilities available in Microsoft internal land that a lot of the real world customer problems just kind of sit and rot until they someone finally says “enough” and happens to complain to the wrong person.

Okay, enough of that rant. I am sure that there are reasonable reasons for the reality distortion field, but it *can* get annoying. And don’t get me started on the excruciating agony that is trying to report a partially-debugged MS code bug from the outside looking in.

  • S

-----Original Message-----
From: Martin O’Brien
Sent: Thursday, September 25, 2008 09:01
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] DDC - updated info for next week

+1

I’d add that some complete and accurate WinDbg documentation might be nice, as would the same for the KRM.

mm

xxxxx@osr.com wrote:
> I agree with Mr. O’Brien. The focus of the DDC is clearly static analysis, because if we’re not using it, that’s obviously because we’re dumb out here and slow on the uptake.
>
> The distortion field is clearly alive and well. Sigh!
>
> As usual, Microsoft would be well served by REALLY understanding what we DO out here. They THINK they understand, but they don’t.
>
> As I’ve said before, I like and respect the folks who do SDV and PreFast. I really do. They’re very smart… most of them smarter than me. But they’d just be soooo surprised if they could spend some time, like maybe a solid 3 months, out in the real world trying to USE these tools to do useful work for pay.
>
> PreFast: Amusing, sometimes useful, but annoying. For maximum effectiveness and minimum annoyance have to “buy in” to using it throughout the life-cycle of your driver. You have to believe that SAL notations are a good thing. I am not convinced.
>
> SDV: Complicated, difficult, and VERY annoying. I have never – not once – been able to get SDV to disclose a meaningful error to me. This is true even when I try to create specific errors in my code that the documentation CLEARLY says SDV will detect and report.
>
> I intellectually understand who/why/where these tools could be useful. I suspect that it’ll take about another ten years before I find them useful in practical situations, however.
>
> If I were king of the group responsible for these tools, I would redirect their efforts to building clever and comprehensive DYNAMIC analysis and debugging tools that we can use out here in the real world, without significant up-front “adopt it for life or it’s not useful”, requirements.
>
> These dynamic tools are really what the community needs at this point. WAY MORE checks in KMDF Verifier. A LOCKING HIERARCHY VALIDATION scheme (OSR has a patent pending on one, we’ll be happy to license it) for ALL sorts of locks. MORE speculative checking options in Driver Verifier. Resurrect Call Usage Verifier – now discontinued. And… just to show you how easy it is to miss the simple stuff: WHY are things like IoGetNextIrpStackLocation still MACROs?? Why are ANY of the DDK functions macros? When they’re macros, they’re impossible to “hook” with Verifier. At LEAST make them functions, and mark them as “inline” in the free build. There is NO additional overhead to this, and much to be gained. This seems obvious to me (and, in fact, was an actual work item for the DDK back, oh, about a thousand years ago).
>
> If any of the static analysis folks would like to come to OSR to spend a couple of months writing code on real customer projects, and see “how the other half lives”, I’ll be happy to provide the office and project management. I’ll even give them free lunch for the duration of their stay (like every other OSR employee). Maybe they’ll gain some insight. Then again, maybe they’ll convince us that PreFast or SDV will make our drivers or file systems better and I’ll have to write a big long article in The NT Insider about how SDV changed my life.
>
> Peter
> OSR
>

—
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

11

+1

While I am it, add (in some cases) !pool, !heap and of course !ptov/!vtop, and that’s most of the memory related extension commands.

Skywing wrote:


>
> While we’re on the crusade of real world vs. Redmond, I’ll throw this one in:
>
> Please test the debugging tools as they will be used by customers.
>
> Every WinDbg release for the past few releases has successively broken more and more highly useful debugger extensons because they are changed to rely on private symbols.
>
> It would be nice if, and my head’s probably in the clouds a bit here, if for a day, a week, whatever, Microsoft internal had to only use publicly available debugger extensions, the public symbol server, etc.
>
> Maybe that will cause stuff like !address being broken in kernel mode (private symbols missing), wow64 typeinfo being omitted in public symbol drops for ntdll, totally destroyin debuggablity on user mode 32bit processes on 64bit systems (this one in particular happens so often now that it’s not even funny; it seems that about every service pack they get broken until some kind soul at Microsoft who should totally not have to deal with this sort of problem again and again plays the hero and fixes it for the rest of us), etc.
>
> At least Microsoft actually tries, which is a heck of a lot better than most of the companies out there in my experience – but again and again, I get the nagging feeling that so many people are wrapped up in the tools and utilities available in Microsoft internal land that a lot of the real world customer problems just kind of sit and rot until they someone finally says “enough” and happens to complain to the wrong person.
>
>

Okay, enough of that rant. I am sure that there are reasonable reasons for the reality distortion field, but it *can* get annoying. And don’t get me started on the excruciating agony that is trying to report a partially-debugged MS code bug from the outside looking in.

  • S

-----Original Message-----
From: Martin O’Brien
> Sent: Thursday, September 25, 2008 09:01
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] DDC - updated info for next week
>
>
> +1
>
> I’d add that some complete and accurate WinDbg documentation might be nice, as would the same for the KRM.
>
>
> mm
>
> xxxxx@osr.com wrote:
>> I agree with Mr. O’Brien. The focus of the DDC is clearly static analysis, because if we’re not using it, that’s obviously because we’re dumb out here and slow on the uptake.
>>
>> The distortion field is clearly alive and well. Sigh!
>>
>> As usual, Microsoft would be well served by REALLY understanding what we DO out here. They THINK they understand, but they don’t.
>>
>> As I’ve said before, I like and respect the folks who do SDV and PreFast. I really do. They’re very smart… most of them smarter than me. But they’d just be soooo surprised if they could spend some time, like maybe a solid 3 months, out in the real world trying to USE these tools to do useful work for pay.
>>
>> PreFast: Amusing, sometimes useful, but annoying. For maximum effectiveness and minimum annoyance have to “buy in” to using it throughout the life-cycle of your driver. You have to believe that SAL notations are a good thing. I am not convinced.
>>
>> SDV: Complicated, difficult, and VERY annoying. I have never – not once – been able to get SDV to disclose a meaningful error to me. This is true even when I try to create specific errors in my code that the documentation CLEARLY says SDV will detect and report.
>>
>> I intellectually understand who/why/where these tools could be useful. I suspect that it’ll take about another ten years before I find them useful in practical situations, however.
>>
>> If I were king of the group responsible for these tools, I would redirect their efforts to building clever and comprehensive DYNAMIC analysis and debugging tools that we can use out here in the real world, without significant up-front “adopt it for life or it’s not useful”, requirements.
>>
>> These dynamic tools are really what the community needs at this point. WAY MORE checks in KMDF Verifier. A LOCKING HIERARCHY VALIDATION scheme (OSR has a patent pending on one, we’ll be happy to license it) for ALL sorts of locks. MORE speculative checking options in Driver Verifier. Resurrect Call Usage Verifier – now discontinued. And… just to show you how easy it is to miss the simple stuff: WHY are things like IoGetNextIrpStackLocation still MACROs?? Why are ANY of the DDK functions macros? When they’re macros, they’re impossible to “hook” with Verifier. At LEAST make them functions, and mark them as “inline” in the free build. There is NO additional overhead to this, and much to be gained. This seems obvious to me (and, in fact, was an actual work item for the DDK back, oh, about a thousand years ago).
>>
>> If any of the static analysis folks would like to come to OSR to spend a couple of months writing code on real customer projects, and see “how the other half lives”, I’ll be happy to provide the office and project management. I’ll even give them free lunch for the duration of their stay (like every other OSR employee). Maybe they’ll gain some insight. Then again, maybe they’ll convince us that PreFast or SDV will make our drivers or file systems better and I’ll have to write a big long article in The NT Insider about how SDV changed my life.
>>
>> Peter
>> OSR
>>
>
> —
> 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
>

12


I’ll even give them free lunch for the duration of their stay (like every
other OSR employee). Maybe they’ll gain some insight.

Or just weight :\

Free lunch, huh? How about those blue cookies for desert. That would
convince most anyone.

-dave

13

Skywing wrote:


>
> While we’re on the crusade of real world vs. Redmond, I’ll throw this one in:
>
> Please test the debugging tools as they will be used by customers.
>
> Every WinDbg release for the past few releases has successively broken more and more highly useful debugger extensons because they are changed to rely on private symbols.
>
> It would be nice if, and my head’s probably in the clouds a bit here, if for a day, a week, whatever, Microsoft internal had to only use publicly available debugger extensions, the public symbol server, etc.
>

Do you really think that would that be enough? Windbg has approximately
two billion commands (OK, that’s a slight exaggeration). Could YOU
concoct a test suite that would exercise most options of all of the
commands? Human testers would never be able to exercise a sufficiently
large subset of the command combinations in real life.

I’ve been debugging Windows for a very long time, getting real work done
in Windbg, and I’ve probably used 5% of its available features.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

14

Not easily, but if they got used to solve problems internally instead of being a maybe-get-to item buried (or even forgotten) on the plate of the minimal QA resources that the DTW team has, I can virtually guarantee that the inability to, for example, do pool searches with !fpsearch, etc., would not keep slipping through.

This is the sort of stuff that is quite apparent if you use the debugger much at all, not to mention the much larger cross section of Microsoft internal that probably knows how to use the debugger.

But these people are using the internal tools & symbols view of things and so this stuff does not get caught until it gets loose in the real world, and then it is likely to be 6+ months before you might see another public DTW drop with fixes in it.

(Obviously, there is a reason to use private symbol if you’ve got 'em, but still… )

  • S

-----Original Message-----
From: Tim Roberts
Sent: Thursday, September 25, 2008 11:59
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] DDC - updated info for next week

Skywing wrote:
>
>
> While we’re on the crusade of real world vs. Redmond, I’ll throw this one in:
>
> Please test the debugging tools as they will be used by customers.
>
> Every WinDbg release for the past few releases has successively broken more and more highly useful debugger extensons because they are changed to rely on private symbols.
>
> It would be nice if, and my head’s probably in the clouds a bit here, if for a day, a week, whatever, Microsoft internal had to only use publicly available debugger extensions, the public symbol server, etc.
>

Do you really think that would that be enough? Windbg has approximately
two billion commands (OK, that’s a slight exaggeration). Could YOU
concoct a test suite that would exercise most options of all of the
commands? Human testers would never be able to exercise a sufficiently
large subset of the command combinations in real life.

I’ve been debugging Windows for a very long time, getting real work done
in Windbg, and I’ve probably used 5% of its available features.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

—
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

15

i would like to think that windbg does pass through some test suite
with public symbols

it is annoying like hell when you see rows and rows of

*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: kernel32!pNlsUserInfo ***
*** ***
*************************************************************************

atleast some thing like
for ( i = (dotcommand && bang command).start; i < (dotcommand && bang
command).end ; i++}
{
doExec(i) | findstr /c:Type referanced >> result.txt
}

parse result.txt -> fix privatesymbol errors or atleast suppress the warning

btw about windbg getting deteriorating with introduction of new drops
yes

dt (display type ) has become more of a unusable command with thier
wildcard tab completion disappearing

application hangs have been becoming more frequent especially when
doing crash dump (may be it is looking for symbols and got hanged
there or whatever but one cant expect to be patient for more than say
10 minutes see an analyze -v down below)

Microsoft (R) Windows Debugger Version 6.9.0003.113 X86
Copyright (c) Microsoft Corporation. All rights reserved.

Loading Dump File [C:\Documents and Settings\Desktop\windbg.exe.hdmp]
User Mini Dump File: Only registers, stack and portions of memory are available

Symbol search path is: SRV*F:\SYMBOLS*HTTP://MSDL.MICROSOFT.COM/DOWNLOAD/SYMBOLS
Executable search path is:
Windows XP Version 2600 (Service Pack 2) UP Free x86 compatible
Product: WinNt, suite: SingleUserTS
Debug session time: Thu Sep 25 20:42:19.000 2008 (GMT+5)
System Uptime: not available
Process Uptime: 0 days 0:05:26.000
…
Loading unloaded module list
…
This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(464.288): Application hang - code cfffffff (first/second chance not available)
eax=00000001 ebx=00000000 ecx=000b7e08 edx=000d7178 esi=022f3d08 edi=00000000
eip=7c90eb94 esp=0006c0dc ebp=0006c164 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
ntdll!KiFastSystemCallRet:
7c90eb94 c3 ret
0:000> !analyze -v
*******************************************************************************
* *
* Exception Analysis *
* *
*******************************************************************************

*** ERROR: Symbol file could not be found. Defaulted to export
symbols for dbgeng.dll -
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: kernel32!pNlsUserInfo ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: kernel32!pNlsUserInfo ***
*** ***
*************************************************************************

FAULTING_IP:
ntdll!KiFastSystemCallRet+0
7c90eb94 c3 ret

EXCEPTION_RECORD: ffffffff – (.exr 0xffffffffffffffff)
ExceptionAddress: 7c90eb94 (ntdll!KiFastSystemCallRet)
ExceptionCode: cfffffff (Application hang)
ExceptionFlags: 00000000
NumberParameters: 0

BUGCHECK_STR: HANG

PROCESS_NAME: windbg.exe

ERROR_CODE: (NTSTATUS) 0xcfffffff -

NTGLOBALFLAG: 0

APPLICATION_VERIFIER_FLAGS: 0

CRITICAL_SECTION: 022f3d08 – (!cs -s 022f3d08)

BLOCKING_THREAD: 00000e00

DERIVED_WAIT_CHAIN:

Dl Eid Cid WaitType
– — ------- --------------------------
0 464.288 Critical Section –>
5 464.e00 Network

WAIT_CHAIN_COMMAND: ~0s;k;;~5s;k;;

DEFAULT_BUCKET_ID: APPLICATION_HANG_BlockedOn_NetworkCall

PRIMARY_PROBLEM_CLASS: APPLICATION_HANG_BlockedOn_NetworkCall

LAST_CONTROL_TRANSFER: from 7c90e9c0 to 7c90eb94

FAULTING_THREAD: 00000005

STACK_TEXT:
00d3d31c 7c90e9c0 71a54033 000003e0 00000001 ntdll!KiFastSystemCallRet
00d3d320 71a54033 000003e0 00000001 00d3d348 ntdll!ZwWaitForSingleObject+0xc
00d3d35c 71a557c9 000003e0 000003d8 00000000
mswsock!SockWaitForSingleObject+0x1a0
00d3d3d4 71ab4379 000003d8 00d3d434 00000001 mswsock!WSPRecv+0x1dd
00d3d410 71ad2ea3 000003d8 00d3d434 00000001 ws2_32!WSARecv+0x77
00d3d43c 771c7bd2 000003d8 00000000 00000e7b wsock32!recv+0x33
00d3d468 771c7b3b 00000000 000a76c8 000ecd10
wininet!ICSocket::Receive_Continue+0x87
00d3d480 771c7adb 000a76c8 00d3d4a4 771bdf08
wininet!ICSocket::Receive_Start+0xbb
00d3d48c 771bdf08 000a76c8 000ecda0 00000000
wininet!CFsm_SocketReceive::RunSM+0x3b
00d3d4a4 771bdeb6 000f9190 00000000 00000000 wininet!CFsm::Run+0x39
00d3d4bc 771c79dd 000a76c8 000e7b18 00d3d82c wininet!DoFsm+0x25
00d3d4cc 771c9dd3 000ecd84 000ecd88 000ecda0 wininet!ICSocket::Receive+0x3e
00d3d82c 771cafaf 771be5bc 00d3d850 771bdf08
wininet!HTTP_REQUEST_HANDLE_OBJECT::ReadData_Fsm+0x234
00d3d838 771bdf08 000ecd10 000e7b18 00000000 wininet!CFsm_ReadData::RunSM+0x2e
00d3d850 771bdeb6 000f9190 00000000 00000000 wininet!CFsm::Run+0x39
00d3d868 771caf2d 000ecd10 000e6248 00d3d8a0 wininet!DoFsm+0x25
00d3d878 771ca9e6 000ecfc8 00001000 000afe08
wininet!HTTP_REQUEST_HANDLE_OBJECT::ReadData+0x38
00d3d8a0 771ca99f 00000000 00d3d8c4 771bdf08
wininet!HTTP_REQUEST_HANDLE_OBJECT::HttpReadData_Fsm+0x43
00d3d8ac 771bdf08 000e6248 00000000 00000000
wininet!CFsm_HttpReadData::RunSM+0x2e
00d3d8c4 771bdeb6 000f9190 00000000 00000000 wininet!CFsm::Run+0x39
00d3d8dc 771ca92e 000e6248 00d3d90c 771ca8a5 wininet!DoFsm+0x25
00d3d8e8 771ca8a5 000e7b18 000ecfc8 00001000 wininet!HttpReadData+0x67
00d3d90c 771ca86f 000afd88 00d3d930 771bdf08 wininet!ReadFile_Fsm+0x2d
00d3d918 771bdf08 000afd88 000f9190 00000000 wininet!CFsm_ReadFile::RunSM+0x2b
00d3d930 771bdeb6 000f9190 00000000 00000000 wininet!CFsm::Run+0x39
00d3d948 771c970d 000afd88 00d3f234 00d3f20c wininet!DoFsm+0x25
00d3d984 01d13b9f 00cc000c 000ecfc8 00001000 wininet!InternetReadFile+0x3ca
00d3d9a0 01d0eb54 00cc000c 000ecfc8 00001000 symsrv!StoreWinInet::readdata+0x1f
00d3dbf8 01d13416 01ca3358 01ca5268 00000001 symsrv!StoreHTTP::readfile+0x184
00d3dc10 01d05c9a 01ca3358 00000001 00000000 symsrv!StoreWinHttp::grab+0xc6
00d3dd04 01d06cf7 00000002 00d3e21c 00d3e26c symsrv!cascade+0x17a
00d3e254 01d06b07 00d3e4a4 01b0063c 00d3e26c symsrv!SymbolServerByIndexW+0x127
00d3e484 0302e42e 00d3e4a4 01b0063c 00d3f160 symsrv!SymbolServerW+0x77
00d3e8c4 0303cb28 0080f688 00d3eb08 01b0063c dbghelp!symsrvGetFile+0x12e
00d3f178 0303ce54 f0f0f0f0 00777258 01b0063c dbghelp!FindFile+0x278
00d3f1b0 0217d407 f0f0f0f0 00777258 01b0063c dbghelp!SymFindFileInPathW+0x44
WARNING: Stack unwind information not available. Following frames may be wrong.
00d3f284 021796a6 00777668 01b0063c 0008c480 dbgeng!DebugCreate+0xacbc7
00d3f2c8 021798d1 01790cdc 00000000 01b00510 dbgeng!DebugCreate+0xa8e66
00d3f2e4 0217d7ec 00000001 00000000 f740c480 dbgeng!DebugCreate+0xa9091
00d3f310 0217e991 00777668 f737e000 ffffffff dbgeng!DebugCreate+0xacfac
00d3f32c 02282952 f737e000 ffffffff 00d3f524 dbgeng!DebugCreate+0xae151
00d3f380 0212197d f737e000 ffffffff 00d3f524 dbgeng!DebugCreate+0x1b2112
00d3f3a4 02115597 00777668 f737e000 ffffffff dbgeng!DebugCreate+0x5113d
00d3f3d0 020b0700 00777668 f737e000 ffffffff dbgeng!DebugCreate+0x44d57
00d3f3fc 020dffca 00777668 f737e000 ffffffff dbgeng+0xb0700
00d3f56c 0223044f 00777668 f737e000 ffffffff dbgeng!DebugCreate+0xf78a
00d3f694 020f3d0c 00777668 01b0063c f737e000 dbgeng!DebugCreate+0x15fc0f
00d3f6c4 020f3b57 0077d5cc 00000036 f737e000 dbgeng!DebugCreate+0x234cc
00d3f7c4 023d0867 0077d5cc 00000036 f737e000 dbgeng!DebugCreate+0x23317
00d3f87c 023d5ab3 00000000 01c98198 00d3f8c4 ext!ModuleParams::Update+0x327
00d3f88c 023d650a 8fb4f0c3 01c98198 01b418b0 ext!ModuleParams::GetImageName+0x13
00d3f8c4 023ed485 0236de98 00d3f8d8 01b418b0 ext!ExtModuleList::Add+0x1aa
00d3f8e8 023ed41c 0236de98 00000002 01b41848 ext!ExtModuleList::AddFlpClass+0x55
00d3f8fc 024045ff 0236de98 00000002 00000000
ext!DebugFailureAnalysis::AddFilterModule+0x1c
00d3fa34 02400ed6 006e0069 0043003b 005c003a
ext!KernelDebugFailureAnalysis::BuildFilterModuleList+0x16f
00d3fb44 02402763 00d3fbc8 01b41848 8fb4f387 ext!BcFillAnalysis+0x176
00d3fb80 024029fc 00d3fbc8 01b41848 8fb4f413 ext!BcAnalyze+0xc3
00d3fc14 023d9aea 00d3fd14 00000001 00000400 ext!AnalyzeBugCheck+0x24c
00d3fc48 02152ce1 0077d5bc 00d3fd14 7d2b5fd3 ext!analyze+0x29a
00d3fcd4 02152f29 0077d5b8 00d3fea8 00d3fe34 dbgeng!DebugCreate+0x824a1
00d3fe64 02152ff2 0077d5b8 00d3fea8 02001a6c dbgeng!DebugCreate+0x826e9
00d3fe80 02195242 0077d5b8 01b20768 00d3fea8 dbgeng!DebugCreate+0x827b2
00d3fef0 0213df7b 0077d5b8 0179bfa8 f0f0f0f0 dbgeng!DebugCreate+0xc4a02
00d3ff40 020d9eae 00000000 00000000 00000000 dbgeng!DebugCreate+0x6d73b
00d3ff80 020da000 0077d5b8 00000000 ffffffff dbgeng!DebugCreate+0x966e
00d3ff98 0102aadf 0077d5c0 00000000 ffffffff dbgeng!DebugCreate+0x97c0
00d3ffb4 7c80b50b 00000000 77d4b2a1 000207be windbg!EngineLoop+0x13f
00d3ffec 00000000 0102a9a0 00000000 00000000 kernel32!BaseThreadStart+0x37

FOLLOWUP_IP:
symsrv!StoreWinInet::readdata+1f
01d13b9f 8be5 mov esp,ebp

SYMBOL_STACK_INDEX: 1b

SYMBOL_NAME: symsrv!StoreWinInet::readdata+1f

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: symsrv

IMAGE_NAME: symsrv.dll

DEBUG_FLR_IMAGE_TIMESTAMP: 47e30f95

STACK_COMMAND: ~5s ; kb

BUCKET_ID: HANG_symsrv!StoreWinInet::readdata+1f

FAILURE_BUCKET_ID:
APPLICATION_HANG_BlockedOn_NetworkCall_cfffffff_symsrv.dll!StoreWinInet::readdata

Followup: MachineOwner
---------

16

+1

Anything that even just got rid of some of the low hanging fruit would be better than whatever is going on right now - strings |
grep, a perl script, whatever. Of course the real problem is then asking whoever wrote the extension to fix it, or getting some
funding to do so.

I know it’s not an exciting task or a grand plan, which makes it hard to get funded, I imagine, but to me, fixing problems like this
and definitely the documentation is a way to improve the quality of drivers that features excellent cost/benefit, and is at least
worth doing (along with the KRM) before anything more extreme that consumes everything in the budget is considered, as well as worth
doing instead of things that just aren’t getting used for whatever reason.

I don’t know how much it would cost to straighten out WinDbg and fix the KRM, but it has to be a lot less than the whatever has
already been spent on SDV, and probably what will get spent on it going forward. As I see it, there is currently no good reason to
think that it will ever be used, short of something miraculous.

mm

raj_r wrote:

i would like to think that windbg does pass through some test suite
with public symbols

it is annoying like hell when you see rows and rows of

*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: kernel32!pNlsUserInfo ***
*** ***
*************************************************************************

atleast some thing like
for ( i = (dotcommand && bang command).start; i < (dotcommand && bang
command).end ; i++}
{
doExec(i) | findstr /c:Type referanced >> result.txt
}

parse result.txt -> fix privatesymbol errors or atleast suppress the warning

btw about windbg getting deteriorating with introduction of new drops
yes

dt (display type ) has become more of a unusable command with thier
wildcard tab completion disappearing

application hangs have been becoming more frequent especially when
doing crash dump (may be it is looking for symbols and got hanged
there or whatever but one cant expect to be patient for more than say
10 minutes see an analyze -v down below)

Microsoft (R) Windows Debugger Version 6.9.0003.113 X86
Copyright (c) Microsoft Corporation. All rights reserved.

Loading Dump File [C:\Documents and Settings\Desktop\windbg.exe.hdmp]
User Mini Dump File: Only registers, stack and portions of memory are available

Symbol search path is: SRV*F:\SYMBOLS*HTTP://MSDL.MICROSOFT.COM/DOWNLOAD/SYMBOLS
Executable search path is:
Windows XP Version 2600 (Service Pack 2) UP Free x86 compatible
Product: WinNt, suite: SingleUserTS
Debug session time: Thu Sep 25 20:42:19.000 2008 (GMT+5)
System Uptime: not available
Process Uptime: 0 days 0:05:26.000
…
Loading unloaded module list
…
This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(464.288): Application hang - code cfffffff (first/second chance not available)
eax=00000001 ebx=00000000 ecx=000b7e08 edx=000d7178 esi=022f3d08 edi=00000000
eip=7c90eb94 esp=0006c0dc ebp=0006c164 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
ntdll!KiFastSystemCallRet:
7c90eb94 c3 ret
0:000> !analyze -v
*******************************************************************************
* *
* Exception Analysis *
* *
*******************************************************************************

*** ERROR: Symbol file could not be found. Defaulted to export
symbols for dbgeng.dll -
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: kernel32!pNlsUserInfo ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: kernel32!pNlsUserInfo ***
*** ***
*************************************************************************

FAULTING_IP:
ntdll!KiFastSystemCallRet+0
7c90eb94 c3 ret

EXCEPTION_RECORD: ffffffff – (.exr 0xffffffffffffffff)
ExceptionAddress: 7c90eb94 (ntdll!KiFastSystemCallRet)
ExceptionCode: cfffffff (Application hang)
ExceptionFlags: 00000000
NumberParameters: 0

BUGCHECK_STR: HANG

PROCESS_NAME: windbg.exe

ERROR_CODE: (NTSTATUS) 0xcfffffff -
>
> NTGLOBALFLAG: 0
>
> APPLICATION_VERIFIER_FLAGS: 0
>
> CRITICAL_SECTION: 022f3d08 – (!cs -s 022f3d08)
>
> BLOCKING_THREAD: 00000e00
>
> DERIVED_WAIT_CHAIN:
>
> Dl Eid Cid WaitType
> – — ------- --------------------------
> 0 464.288 Critical Section –>
> 5 464.e00 Network
>
> WAIT_CHAIN_COMMAND: ~0s;k;;~5s;k;;
>
> DEFAULT_BUCKET_ID: APPLICATION_HANG_BlockedOn_NetworkCall
>
> PRIMARY_PROBLEM_CLASS: APPLICATION_HANG_BlockedOn_NetworkCall
>
> LAST_CONTROL_TRANSFER: from 7c90e9c0 to 7c90eb94
>
> FAULTING_THREAD: 00000005
>
> STACK_TEXT:
> 00d3d31c 7c90e9c0 71a54033 000003e0 00000001 ntdll!KiFastSystemCallRet
> 00d3d320 71a54033 000003e0 00000001 00d3d348 ntdll!ZwWaitForSingleObject+0xc
> 00d3d35c 71a557c9 000003e0 000003d8 00000000
> mswsock!SockWaitForSingleObject+0x1a0
> 00d3d3d4 71ab4379 000003d8 00d3d434 00000001 mswsock!WSPRecv+0x1dd
> 00d3d410 71ad2ea3 000003d8 00d3d434 00000001 ws2_32!WSARecv+0x77
> 00d3d43c 771c7bd2 000003d8 00000000 00000e7b wsock32!recv+0x33
> 00d3d468 771c7b3b 00000000 000a76c8 000ecd10
> wininet!ICSocket::Receive_Continue+0x87
> 00d3d480 771c7adb 000a76c8 00d3d4a4 771bdf08
> wininet!ICSocket::Receive_Start+0xbb
> 00d3d48c 771bdf08 000a76c8 000ecda0 00000000
> wininet!CFsm_SocketReceive::RunSM+0x3b
> 00d3d4a4 771bdeb6 000f9190 00000000 00000000 wininet!CFsm::Run+0x39
> 00d3d4bc 771c79dd 000a76c8 000e7b18 00d3d82c wininet!DoFsm+0x25
> 00d3d4cc 771c9dd3 000ecd84 000ecd88 000ecda0 wininet!ICSocket::Receive+0x3e
> 00d3d82c 771cafaf 771be5bc 00d3d850 771bdf08
> wininet!HTTP_REQUEST_HANDLE_OBJECT::ReadData_Fsm+0x234
> 00d3d838 771bdf08 000ecd10 000e7b18 00000000 wininet!CFsm_ReadData::RunSM+0x2e
> 00d3d850 771bdeb6 000f9190 00000000 00000000 wininet!CFsm::Run+0x39
> 00d3d868 771caf2d 000ecd10 000e6248 00d3d8a0 wininet!DoFsm+0x25
> 00d3d878 771ca9e6 000ecfc8 00001000 000afe08
> wininet!HTTP_REQUEST_HANDLE_OBJECT::ReadData+0x38
> 00d3d8a0 771ca99f 00000000 00d3d8c4 771bdf08
> wininet!HTTP_REQUEST_HANDLE_OBJECT::HttpReadData_Fsm+0x43
> 00d3d8ac 771bdf08 000e6248 00000000 00000000
> wininet!CFsm_HttpReadData::RunSM+0x2e
> 00d3d8c4 771bdeb6 000f9190 00000000 00000000 wininet!CFsm::Run+0x39
> 00d3d8dc 771ca92e 000e6248 00d3d90c 771ca8a5 wininet!DoFsm+0x25
> 00d3d8e8 771ca8a5 000e7b18 000ecfc8 00001000 wininet!HttpReadData+0x67
> 00d3d90c 771ca86f 000afd88 00d3d930 771bdf08 wininet!ReadFile_Fsm+0x2d
> 00d3d918 771bdf08 000afd88 000f9190 00000000 wininet!CFsm_ReadFile::RunSM+0x2b
> 00d3d930 771bdeb6 000f9190 00000000 00000000 wininet!CFsm::Run+0x39
> 00d3d948 771c970d 000afd88 00d3f234 00d3f20c wininet!DoFsm+0x25
> 00d3d984 01d13b9f 00cc000c 000ecfc8 00001000 wininet!InternetReadFile+0x3ca
> 00d3d9a0 01d0eb54 00cc000c 000ecfc8 00001000 symsrv!StoreWinInet::readdata+0x1f
> 00d3dbf8 01d13416 01ca3358 01ca5268 00000001 symsrv!StoreHTTP::readfile+0x184
> 00d3dc10 01d05c9a 01ca3358 00000001 00000000 symsrv!StoreWinHttp::grab+0xc6
> 00d3dd04 01d06cf7 00000002 00d3e21c 00d3e26c symsrv!cascade+0x17a
> 00d3e254 01d06b07 00d3e4a4 01b0063c 00d3e26c symsrv!SymbolServerByIndexW+0x127
> 00d3e484 0302e42e 00d3e4a4 01b0063c 00d3f160 symsrv!SymbolServerW+0x77
> 00d3e8c4 0303cb28 0080f688 00d3eb08 01b0063c dbghelp!symsrvGetFile+0x12e
> 00d3f178 0303ce54 f0f0f0f0 00777258 01b0063c dbghelp!FindFile+0x278
> 00d3f1b0 0217d407 f0f0f0f0 00777258 01b0063c dbghelp!SymFindFileInPathW+0x44
> WARNING: Stack unwind information not available. Following frames may be wrong.
> 00d3f284 021796a6 00777668 01b0063c 0008c480 dbgeng!DebugCreate+0xacbc7
> 00d3f2c8 021798d1 01790cdc 00000000 01b00510 dbgeng!DebugCreate+0xa8e66
> 00d3f2e4 0217d7ec 00000001 00000000 f740c480 dbgeng!DebugCreate+0xa9091
> 00d3f310 0217e991 00777668 f737e000 ffffffff dbgeng!DebugCreate+0xacfac
> 00d3f32c 02282952 f737e000 ffffffff 00d3f524 dbgeng!DebugCreate+0xae151
> 00d3f380 0212197d f737e000 ffffffff 00d3f524 dbgeng!DebugCreate+0x1b2112
> 00d3f3a4 02115597 00777668 f737e000 ffffffff dbgeng!DebugCreate+0x5113d
> 00d3f3d0 020b0700 00777668 f737e000 ffffffff dbgeng!DebugCreate+0x44d57
> 00d3f3fc 020dffca 00777668 f737e000 ffffffff dbgeng+0xb0700
> 00d3f56c 0223044f 00777668 f737e000 ffffffff dbgeng!DebugCreate+0xf78a
> 00d3f694 020f3d0c 00777668 01b0063c f737e000 dbgeng!DebugCreate+0x15fc0f
> 00d3f6c4 020f3b57 0077d5cc 00000036 f737e000 dbgeng!DebugCreate+0x234cc
> 00d3f7c4 023d0867 0077d5cc 00000036 f737e000 dbgeng!DebugCreate+0x23317
> 00d3f87c 023d5ab3 00000000 01c98198 00d3f8c4 ext!ModuleParams::Update+0x327
> 00d3f88c 023d650a 8fb4f0c3 01c98198 01b418b0 ext!ModuleParams::GetImageName+0x13
> 00d3f8c4 023ed485 0236de98 00d3f8d8 01b418b0 ext!ExtModuleList::Add+0x1aa
> 00d3f8e8 023ed41c 0236de98 00000002 01b41848 ext!ExtModuleList::AddFlpClass+0x55
> 00d3f8fc 024045ff 0236de98 00000002 00000000
> ext!DebugFailureAnalysis::AddFilterModule+0x1c
> 00d3fa34 02400ed6 006e0069 0043003b 005c003a
> ext!KernelDebugFailureAnalysis::BuildFilterModuleList+0x16f
> 00d3fb44 02402763 00d3fbc8 01b41848 8fb4f387 ext!BcFillAnalysis+0x176
> 00d3fb80 024029fc 00d3fbc8 01b41848 8fb4f413 ext!BcAnalyze+0xc3
> 00d3fc14 023d9aea 00d3fd14 00000001 00000400 ext!AnalyzeBugCheck+0x24c
> 00d3fc48 02152ce1 0077d5bc 00d3fd14 7d2b5fd3 ext!analyze+0x29a
> 00d3fcd4 02152f29 0077d5b8 00d3fea8 00d3fe34 dbgeng!DebugCreate+0x824a1
> 00d3fe64 02152ff2 0077d5b8 00d3fea8 02001a6c dbgeng!DebugCreate+0x826e9
> 00d3fe80 02195242 0077d5b8 01b20768 00d3fea8 dbgeng!DebugCreate+0x827b2
> 00d3fef0 0213df7b 0077d5b8 0179bfa8 f0f0f0f0 dbgeng!DebugCreate+0xc4a02
> 00d3ff40 020d9eae 00000000 00000000 00000000 dbgeng!DebugCreate+0x6d73b
> 00d3ff80 020da000 0077d5b8 00000000 ffffffff dbgeng!DebugCreate+0x966e
> 00d3ff98 0102aadf 0077d5c0 00000000 ffffffff dbgeng!DebugCreate+0x97c0
> 00d3ffb4 7c80b50b 00000000 77d4b2a1 000207be windbg!EngineLoop+0x13f
> 00d3ffec 00000000 0102a9a0 00000000 00000000 kernel32!BaseThreadStart+0x37
>
>
> FOLLOWUP_IP:
> symsrv!StoreWinInet::readdata+1f
> 01d13b9f 8be5 mov esp,ebp
>
> SYMBOL_STACK_INDEX: 1b
>
> SYMBOL_NAME: symsrv!StoreWinInet::readdata+1f
>
> FOLLOWUP_NAME: MachineOwner
>
> MODULE_NAME: symsrv
>
> IMAGE_NAME: symsrv.dll
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 47e30f95
>
> STACK_COMMAND: ~5s ; kb
>
> BUCKET_ID: HANG_symsrv!StoreWinInet::readdata+1f
>
> FAILURE_BUCKET_ID:
> APPLICATION_HANG_BlockedOn_NetworkCall_cfffffff_symsrv.dll!StoreWinInet::readdata
>
> Followup: MachineOwner
> ---------
>

17

RE: Private symbols and WinDbg.

It’s just like with the WDK build environment, build, makefile.new, etc. We’re only PART of the target audience for WinDbg. In fact, it’s not clear to me we’re more numerous than the internal users of WinDbg who have access to “real” symbols.

I’m not justifying it… but like the “reality distortion field” for other things, the internal WinDbg users are likely to distort the perspective of the WinDbg devs.

Peter
OSR

18

I actually LOVE static analysis tools. I just don’t understand why they
don’t get some real kernel devs on them and tailor them appropriately. I
think PreFast is a beautiful tool! I don’t even bother with the SAL
annotation much (except for the buffer size stuff that is pretty cool) and I
still find it terribly useful. I mean, it just catches stupid errors
mostly, but that is SO much better to catch at build time and you can easily
hook it into the build process to automatically run. The false positives
are a good bit annoying, they could trim that a LOT.

SDV seems like a great idea, but horribly horribly broken. I, like Peter,
have never gotten anything useful out of it. But the idea seems to have a
lot of promise. Just needs some serious and directed effort behind it.

Run time tools are awesome! I will use all I can get my hands on and I do.
But static analysis tools that can be automated into a build are simply
beautiful! I wish I had a better handle on just how broad a spectrum of
errors those tools could find in a reasonable timeframe given sufficiently
sophisticated tools. I really don’t have a good idea where those bounds
are. But, if the potential error catching surface is large…I say poor all
the resources you can into that!

For runtime tools…I would LOVE to see some kind of integration into DTM,
so again, we could automate the running and retrieving of results!!

For that matter, how about fixing and/or finishing the COM interface to DTM
so automating the running of DTM is easier to achieve?

Bill M.

“Don Burn” wrote in message news:xxxxx@ntdev…
> The number of tools that would be nice out of Microsoft is too large to
> post, a few over the years I have suggested to them are:
>
> 1. Code coverage - yes Bullseye is nice, but even with it we need faut
> injection. Note they looked at fault injection and rejected it because
> people would have to modify their code (I guess annotations don’t count as
> modification)
>
> 2. Lock contention measurement - the number of times I have seen people
> propose a gazzilion locks for a driver because they do not want
> contention. A tool that shows how long locks are held (max and average)
> and how long someone waits for locks would probably slow down some of
> these lets have a seperate lock for everything.
>
> 3. Call usage verifier - this was a godd tool, it could have been
> expanded a lot. Come on Redmond either bring it forward, or release it
> back to OSR so they can have the OSR WDK (compared to the OSR DDK that CUV
> came from).
>
> Perhaps we need an email list for such tools, complete with a legal
> agreement that releases any thing people say, so Redmond or others can act
> on it.
>
>
> –
> 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
>
>
>
>
> “Martin O’Brien” wrote in message
> news:xxxxx@ntdev…
>> +1
>>
>> I’d add that some complete and accurate WinDbg documentation might be
>> nice, as would the same for the KRM.
>>
>>
>> mm
>>
>> xxxxx@osr.com wrote:
>>> I agree with Mr. O’Brien. The focus of the DDC is clearly static
>>> analysis, because if we’re not using it, that’s obviously because we’re
>>> dumb out here and slow on the uptake.
>>>
>>> The distortion field is clearly alive and well. Sigh!
>>>
>>> As usual, Microsoft would be well served by REALLY understanding what we
>>> DO out here. They THINK they understand, but they don’t.
>>>
>>> As I’ve said before, I like and respect the folks who do SDV and
>>> PreFast. I really do. They’re very smart… most of them smarter than
>>> me. But they’d just be soooo surprised if they could spend some time,
>>> like maybe a solid 3 months, out in the real world trying to USE these
>>> tools to do useful work for pay.
>>>
>>> PreFast: Amusing, sometimes useful, but annoying. For maximum
>>> effectiveness and minimum annoyance have to “buy in” to using it
>>> throughout the life-cycle of your driver. You have to believe that SAL
>>> notations are a good thing. I am not convinced.
>>>
>>> SDV: Complicated, difficult, and VERY annoying. I have never – not
>>> once – been able to get SDV to disclose a meaningful error to me. This
>>> is true even when I try to create specific errors in my code that the
>>> documentation CLEARLY says SDV will detect and report.
>>>
>>> I intellectually understand who/why/where these tools could be useful.
>>> I suspect that it’ll take about another ten years before I find them
>>> useful in practical situations, however.
>>>
>>> If I were king of the group responsible for these tools, I would
>>> redirect their efforts to building clever and comprehensive DYNAMIC
>>> analysis and debugging tools that we can use out here in the real world,
>>> without significant up-front “adopt it for life or it’s not useful”,
>>> requirements.
>>>
>>> These dynamic tools are really what the community needs at this point.
>>> WAY MORE checks in KMDF Verifier. A LOCKING HIERARCHY VALIDATION scheme
>>> (OSR has a patent pending on one, we’ll be happy to license it) for ALL
>>> sorts of locks. MORE speculative checking options in Driver Verifier.
>>> Resurrect Call Usage Verifier – now discontinued. And… just to show
>>> you how easy it is to miss the simple stuff: WHY are things like
>>> IoGetNextIrpStackLocation still MACROs?? Why are ANY of the DDK
>>> functions macros? When they’re macros, they’re impossible to “hook”
>>> with Verifier. At LEAST make them functions, and mark them as “inline”
>>> in the free build. There is NO additional overhead to this, and much to
>>> be gained. This seems obvious to me (and, in fact, was an actual work
>>> item for the DDK back, oh, about a thousand years ago).
>>>
>>> If any of the static analysis folks would like to come to OSR to spend a
>>> couple of months writing code on real customer projects, and see “how
>>> the other half lives”, I’ll be happy to provide the office and project
>>> management. I’ll even give them free lunch for the duration of their
>>> stay (like every other OSR employee). Maybe they’ll gain some insight.
>>> Then again, maybe they’ll convince us that PreFast or SDV will make our
>>> drivers or file systems better and I’ll have to write a big long article
>>> in The NT Insider about how SDV changed my life.
>>>
>>> Peter
>>> OSR
>>
>
>
>

19

How about scrapping DTM and putting together a real test framework? DTM is
horribly over engineered for anyone other than WHQL, it just gets in the
way. For those of us who are small environments, setting it iup is
horribly complicated.

For firms that have large test environments, it still gets in the way. I
know a major firm that has pools of hundreds of test machines and their own
tools to image and run tests, for years when they had a new driver for
Windows they would use the whole pool to stress test the driver. Now thanks
to DTM being in the way, they have a pool of 30 systems for Windows testing,
and reserve the hundreds for other OS’es that do have the DTM problems.

DTM IMHO has done more to set back the quality of Windows drivers than
anything Microsoft has done.

–
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

“Bill McKenzie” wrote in message
news:xxxxx@ntdev…
>I actually LOVE static analysis tools. I just don’t understand why they
>don’t get some real kernel devs on them and tailor them appropriately. I
>think PreFast is a beautiful tool! I don’t even bother with the SAL
>annotation much (except for the buffer size stuff that is pretty cool) and
>I still find it terribly useful. I mean, it just catches stupid errors
>mostly, but that is SO much better to catch at build time and you can
>easily hook it into the build process to automatically run. The false
>positives are a good bit annoying, they could trim that a LOT.
>
> SDV seems like a great idea, but horribly horribly broken. I, like Peter,
> have never gotten anything useful out of it. But the idea seems to have
> a lot of promise. Just needs some serious and directed effort behind it.
>
> Run time tools are awesome! I will use all I can get my hands on and I
> do. But static analysis tools that can be automated into a build are
> simply beautiful! I wish I had a better handle on just how broad a
> spectrum of errors those tools could find in a reasonable timeframe given
> sufficiently sophisticated tools. I really don’t have a good idea where
> those bounds are. But, if the potential error catching surface is
> large…I say poor all the resources you can into that!
>
> For runtime tools…I would LOVE to see some kind of integration into DTM,
> so again, we could automate the running and retrieving of results!!
>
> For that matter, how about fixing and/or finishing the COM interface to
> DTM so automating the running of DTM is easier to achieve?
>
> Bill M.
>
>
>
> “Don Burn” wrote in message news:xxxxx@ntdev…
>> The number of tools that would be nice out of Microsoft is too large to
>> post, a few over the years I have suggested to them are:
>>
>> 1. Code coverage - yes Bullseye is nice, but even with it we need faut
>> injection. Note they looked at fault injection and rejected it because
>> people would have to modify their code (I guess annotations don’t count
>> as modification)
>>
>> 2. Lock contention measurement - the number of times I have seen people
>> propose a gazzilion locks for a driver because they do not want
>> contention. A tool that shows how long locks are held (max and average)
>> and how long someone waits for locks would probably slow down some of
>> these lets have a seperate lock for everything.
>>
>> 3. Call usage verifier - this was a godd tool, it could have been
>> expanded a lot. Come on Redmond either bring it forward, or release it
>> back to OSR so they can have the OSR WDK (compared to the OSR DDK that
>> CUV came from).
>>
>> Perhaps we need an email list for such tools, complete with a legal
>> agreement that releases any thing people say, so Redmond or others can
>> act on it.
>>
>>
>> –
>> 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
>>
>>
>>
>>
>> “Martin O’Brien” wrote in message
>> news:xxxxx@ntdev…
>>> +1
>>>
>>> I’d add that some complete and accurate WinDbg documentation might be
>>> nice, as would the same for the KRM.
>>>
>>>
>>> mm
>>>
>>> xxxxx@osr.com wrote:
>>>> I agree with Mr. O’Brien. The focus of the DDC is clearly static
>>>> analysis, because if we’re not using it, that’s obviously because we’re
>>>> dumb out here and slow on the uptake.
>>>>
>>>> The distortion field is clearly alive and well. Sigh!
>>>>
>>>> As usual, Microsoft would be well served by REALLY understanding what
>>>> we DO out here. They THINK they understand, but they don’t.
>>>>
>>>> As I’ve said before, I like and respect the folks who do SDV and
>>>> PreFast. I really do. They’re very smart… most of them smarter than
>>>> me. But they’d just be soooo surprised if they could spend some time,
>>>> like maybe a solid 3 months, out in the real world trying to USE these
>>>> tools to do useful work for pay.
>>>>
>>>> PreFast: Amusing, sometimes useful, but annoying. For maximum
>>>> effectiveness and minimum annoyance have to “buy in” to using it
>>>> throughout the life-cycle of your driver. You have to believe that SAL
>>>> notations are a good thing. I am not convinced.
>>>>
>>>> SDV: Complicated, difficult, and VERY annoying. I have never – not
>>>> once – been able to get SDV to disclose a meaningful error to me.
>>>> This is true even when I try to create specific errors in my code that
>>>> the documentation CLEARLY says SDV will detect and report.
>>>>
>>>> I intellectually understand who/why/where these tools could be
>>>> useful. I suspect that it’ll take about another ten years before I find
>>>> them useful in practical situations, however.
>>>>
>>>> If I were king of the group responsible for these tools, I would
>>>> redirect their efforts to building clever and comprehensive DYNAMIC
>>>> analysis and debugging tools that we can use out here in the real
>>>> world, without significant up-front “adopt it for life or it’s not
>>>> useful”, requirements.
>>>>
>>>> These dynamic tools are really what the community needs at this point.
>>>> WAY MORE checks in KMDF Verifier. A LOCKING HIERARCHY VALIDATION scheme
>>>> (OSR has a patent pending on one, we’ll be happy to license it) for ALL
>>>> sorts of locks. MORE speculative checking options in Driver Verifier.
>>>> Resurrect Call Usage Verifier – now discontinued. And… just to show
>>>> you how easy it is to miss the simple stuff: WHY are things like
>>>> IoGetNextIrpStackLocation still MACROs?? Why are ANY of the DDK
>>>> functions macros? When they’re macros, they’re impossible to “hook”
>>>> with Verifier. At LEAST make them functions, and mark them as “inline”
>>>> in the free build. There is NO additional overhead to this, and much
>>>> to be gained. This seems obvious to me (and, in fact, was an actual
>>>> work item for the DDK back, oh, about a thousand years ago).
>>>>
>>>> If any of the static analysis folks would like to come to OSR to spend
>>>> a couple of months writing code on real customer projects, and see “how
>>>> the other half lives”, I’ll be happy to provide the office and project
>>>> management. I’ll even give them free lunch for the duration of their
>>>> stay (like every other OSR employee). Maybe they’ll gain some insight.
>>>> Then again, maybe they’ll convince us that PreFast or SDV will make our
>>>> drivers or file systems better and I’ll have to write a big long
>>>> article in The NT Insider about how SDV changed my life.
>>>>
>>>> Peter
>>>> OSR
>>>
>>
>>
>>
>
>
>

20

Bill McKenzie wrote:

I actually LOVE static analysis tools. I just don’t understand why they
don’t get some real kernel devs on them and tailor them appropriately.

*I* can answer that question: because kernel devs don’t know squat about
making a static analysis tool. It’s the wrong skill set. Remember, SDV
is essentially pass 1 of the Microsoft C++ compiler, with a custom back
end. You need compiler gurus to write SDV, not driver gurus.

I have a compiler background from my days at Control Data. I was
really, really impressed when I heard what SDV was doing. There are
some real eggheads in Microsoft Research. I have no doubt that it will
get better.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.