Jan/Feb Issue of The NT Insider is Released

NTDEV
1

The latest issue of The NT Insider (Jan/Feb 2017) is now available:

http:

There are a couple of articles that should be of interest to many of the members here. One is on naming and protecting Device Objects in WDF drivers. The other is about testing complex driver code in user mode. Both are based on our experience with real projects here at OSR.

Enjoy,

Peter
OSR
@OSRDrivers</http:>

2

Seems like S3 is having problems… JUST as we released The NT Insider.

Alternate link to the Jan/Feb 2017 issue via OneDrive:

https://1drv.ms/b/s!ABsJrwUBDGqBu3A

Peter
OSR
@OSRDrivers

3

I found myself giving your table of contents a code review. I’ve never given a code review to a table of contents before.

Regarding the test-in-usermode discussion on Page 8. I’ll +1 to that – we regularly test new NDIS.SYS code inside a usermode process first. It smokes out all the stupid bugs. Over time, we’ve accumulated a set of kernel/user wrappers, much like the “#define ExAllocatePoolWithTag malloc” example you give.

I wonder if we were to toss a dumb little header file on github with all these stupid little wrappers, would other people find it useful? Contribute back? Or would it devolve into a stylistic argument about using goto vs early return?

4

On the table of contents code review point, assuming that the out parameters of a function retain (or attain) a particular value if the function fails is generally to be avoided.

Some APIs do provide that behavior, some don’t, and it’s seldom documented (and in the worst case subject to change without notice, particularly if it just “happened that way like accident” and some future maintainer innocently adjusted the way the code works). You wouldn’t want to have a pool corruption bug spring up if someone started using *TokenInformation for scratch in failure cases, after all. Best to be conservative and assume nothing about the state of out parameters on failure unless the API is explicitly documented as guaranteeing a particular disposition there.

Now, I wouldn’t expect someone to willfully go around and start tossing in garbage in out parameters with glee just to break existing code for the fun of it, but it’s certainly not a hard and fast rule throughout the system that the out parameters are always left alone in failure cases, and you can easily get burned if you get into the habit of assuming that, only to find that some APIs don’t (or worse, don’t only under certain circumstances).

  • S (Msft)

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Jeffrey Tippet
Sent: Tuesday, February 28, 2017 11:51 AM
To: Windows System Software Devs Interest List
Subject: RE: RE:[ntdev] Jan/Feb Issue of The NT Insider is Released

I found myself giving your table of contents a code review. I’ve never given a code review to a table of contents before.

Regarding the test-in-usermode discussion on Page 8. I’ll +1 to that – we regularly test new NDIS.SYS code inside a usermode process first. It smokes out all the stupid bugs. Over time, we’ve accumulated a set of kernel/user wrappers, much like the “#define ExAllocatePoolWithTag malloc” example you give.

I wonder if we were to toss a dumb little header file on github with all these stupid little wrappers, would other people find it useful? Contribute back? Or would it devolve into a stylistic argument about using goto vs early return?

—
NTDEV is sponsored by OSR

Visit the list online at: http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:>

5

Well, all those.

People would find it useful, and you would never hear about it. Almost nobody would contribute back. And it provide some folks the ability to espouse the One True Religion about the moral equivalence of ExAllocatePool and malloc vs VirtualAlloc.

BUT… it would still be an excellent contribution to the community. We would *love* to see it. Better yet, if you slap it up there, we’ll even commit to trying it out and writing something about it in The NT Insider.

Thanks Jeffrey!

Peter
OSR
@OSRDrivers

6

I admit to making that assumption a lot in “real life” (and not just in the Table of Contents).

Good point, though. Thanks for making us think,

Peter
OSR
@OSRDrivers

7

The NT Insider Breaks the Internet:

http:</http:>

(with alternative links to the PDF of the latest issue)

Peter
OSR
@OSRDrivers

8

If you have the appropriate SAL on your functions Code Analysis is usually
pretty good about whining at you in these cases. Had we followed best
journalistic practices and run CA on the table of contents maybe we would
have caught this.

-scott
OSR
@OSRDrivers

wrote in message news:xxxxx@ntdev…

I admit to making that assumption a lot in “real life” (and not just in the
Table of Contents).

Good point, though. Thanks for making us think,

Peter
OSR
@OSRDrivers