Trouble Ahead- Trouble Behind

New WDF debugging videos on WHDC

BobKjelgaard — Tue, 22 Sep 2009 16:41:32 GMT

Several for KMDF here, and several more for UMDF here.

Thus endeth today’s PR blitzen. Have fun!

Time Doth Flee

BobKjelgaard — Tue, 15 Sep 2009 16:12:00 GMT

Just realized I’ve now been blogging on MSDN for a bit over two years- that covers two OS releases [Windows Server 2008 and Windows 7] and WDF releases [1.7 and 1.9]. To bow to the Dead again- a long, strange trip it has been. I started out wanting to write troubleshooting stories (something like Mark Russinovich often does). But unfortunately, I found many of my best efforts turned up bugs in products that haven’t been shipped yet, and their owners typically don’t want such things disclosed or discussed in a public forum. So I’ve wandered a bit all over the map, intellectually and topically speaking, since then.

I’ve got more important things to write, though, so I’m tempted to leave this post at its current state. It’s been over two years, now. But I ain’t done- not yet!

Why I Work (part of it, anyway)

So for a moment, I’m going back to my “life at Microsoft” series…

The bulletin board in my office is quite a bit of narcissism- one photo of my daughter, and the Halo3 calendar someone from Bungie gave me- opened to a picture of the Master Chief and the Arbiter, of course, since it’s for last year. Also the outside cover of an InuYasha CD full of Kanji and an old poster for the Steve Pope band [which I played in when I was a Caltech undergrad]. The rest is all pictures of myself- from Caltech, from my years at IBM, from the Laundromat. One is of very unique construction, and forms a nice background for the rest of today’s story.

It’s a very high-tech etching, basically- constructed as follows:

I’m contacted by a Wall Street Journal reporter who had written a book about Windows NT and had mentioned me in it [because I left Microsoft to run a Laundromat, and it seemed to be an interesting burnout story]. I’d mentioned what a disaster the laundry was for me, and he wants to do “a cautionary tale” about it.
As part of that process, along with the interviews, he takes a few pictures, including one of myself (short hair, glasses, and just a moustache) and one of the Laundromat.
An artist then combines those two photos and produces a detailed pencil sketch of them.
When the article is published, the sketch accompanies it.
My brother John scans this artwork, and uses it to create a “glass master” [how he got permission, I’m not sure I want to know]…
He then gets permission to use that to produce several printed circuit boards with this image on an IBM manufacturing line in Endicott, NY [again, he said he had permission- they must have really liked him!].

So yes, (a) I was the subject of a Wall Street Journal story (but not the kind most people would want) and (b) I’ve got an IBM printed circuit board with my picture on it- several of them, actually [one I keep at home actually also has the engraved signatures of almost everyone in my immediate family].

I keep them partially for the memories [and their uniqueness, of course], but also to remind me of the costs of some choices. That venture bankrupted me in all but legal state [I could file, but I did not]. On the heels of that, I got divorced, and then hit a series of short-term jobs punctuated by periods of unemployment. I was debt-free, but had a lot of future obligations (child support and so on). Unemployment didn’t pay enough to cover child support [I could ask to have it reduced in such cases, but I wanted to take care of my daughter]. So I was counting the months and weeks I could get through with negative income before I was truly homeless, and not liking how small those numbers were.

That was the state of affairs when I came to Microsoft. So I’ll be frank about it- there are a lot of reasons I work here, but a paycheck is most certainly one of them. And the pay is good.

I’ll skip the details, here- but I’ve come a long way financially, since then. I’ve still got some very old computers that should be replaced, and some furniture in even worse state- and I still try to live pretty frugally [that was part of the reason I originally began not eating during the workday, over a decade ago]. But I’ve replaced some items already, I’ve got a decent savings cushion put together, my only debt is a mortgage which will be paid off well ahead of schedule, and I skip meals because it’s become an occasionally useful habit, instead of a necessity.

My present is definitely tolerable, and my future becomes ever more secure. That matters to me,and because I can remember when both were much more uncertain, I recognize Microsoft’s role in that.

I suppose one key for me here is that this isn’t really a case of trading pay for some other intangible or tangible inducement. The environment is good, the work is challenging and exciting- and relevant and meaningful.

So for the moment, I’ll celebrate not just having a job [which I realize is a problem in and of itself for some people today], but having a good one- in spite of all my past mistakes and current shortcomings.

Next time, I’ll get back to something more technical, because I do realize this sort of article wastes most readers’ precious time…

I’ll see if this publishes this time around (I wrote it quite a while ago, but occasionally things don’t work very well around here)- if it does, I should note I can also celebrate a birthday tomorrow…

Yet another WDF Blogger

BobKjelgaard — Wed, 02 Sep 2009 17:44:03 GMT

But that is a good thing. With a post yesterday, Neslihan has made her MSDN blogs debut. As I said long ago, you can expect great things to come from her. She is already our resident expert on all things WLK and particularly with respect to WHQL for WDF devices. I’ve already added her to my list of colleagues here, so adieu for now…

Driver Packages and Drivers- Shall We Disambiguate?

BobKjelgaard — Sat, 22 Aug 2009 22:50:00 GMT

So you want to know how to sign your driver, eh? Let us step aside and improve our thinking for a moment, so we can be smarter about what we are asking for- because I don’t think it’s the driver you actually want to sign…

What is a Driver Package?

At a minimum. it is ALL of the files that should be present to make sure your device’s driver and all associated support software installs, begins working, and continues to work when it is plugged in:

The driver binaries, including any coinstallers, or other support binaries.
The INF file, which tells the OS how to install the “driver” and hook all those things together properly.

You may want more than that in the package- perhaps you have useful value-added utilities to install that you also want on the disk. That can be done, and Microsoft encourages you to do so.

How do I know what needs to be in the package?

The simplest answer is the best, here- every file listed in the INF as something that needs to be copied is a part of your package, as is the INF and any catalog file (about time I mentioned that) listed in the header. Telling us you need those files copied means they are a part of the software supporting your hardware.

Why even mention that? Well, to make things easy for our joint customer- the person who bought your software [and usually your hardware, as well]- we will copy all of those files to a “driver store” on their machine. Then, if installation needs to happen again (or happens later, as can be the case with a “software first” installation), they won’t need to find your media a second time- everything is already there, and the installation can be very silent [this is a bit of a simplification- if you provide coinstallers, you have options for UI and all kinds of other mayhem that exceed my intended scope- may I suggest perusing some of the WinHec or DDC content?].

Well, as long as we’re looking there- consider getting your driver package on Windows Update, and having it “just work” when the user connects it to their computer… Look at the presentation before you make assumptions- we may well be willing to let you do a lot more than you think we will…

Could You Get To The Point?

Sure: You probably don’t want to [or at least don’t really need to] sign your driver. You want to sign the package.

Why? Because signing protects your customer (and by reflection, you) from tampering and corruption of the entire thing which is signed. You don’t want someone replacing your coinstaller with one that also installs a keylogger, do you? Or hiding that logger inside one of your support DLLs? Or simply modifying your INF to install their malware for them when your driver is installed? A lot of good it is going to do our customer to have a single driver binary safe and secure when everything else is open to attack.

OK- So How Do I Do This?

A quick summary:

You create a “catalog”, which lists all of the files in your package (except for the catalog itself, of course).
This catalog also has reasonably secure checksums for all of the files at the time they were cataloged.
You then digitally sign the catalog, putting yourself on the line for everything within it, and knowing that if ANY of it gets changed, the change will be noticed.
Now anyone that trusts you can trust your entire package. Wouldn’t you rather have that than one binary?

This process is often called “catalog signing” as a distinction from “driver signing”- my rant here is that this is a focus on mechanism rather than intent. Yes, you sign the catalog- but your intent is to vouch for the integrity of the entire package you present.

If you want instructions, you can check here. But for my testing friends, I’ll promise to show how we roll in WDFQA (that’d be Windows Driver Frameworks Quality Assurance), because signing driver packages is a hurdle you have to clear for agile and reliable test automation when multitudes of drivers are involved.

When do I sign the binary?

The focus here is 64-bit systems. Of course to me, those are the only ones worth having anymore…

If your driver is needed to make the system boot, then you should also sign the binary itself.
If your driver is not a WDM driver (yes I happen to have a few of these myself)- or in KMDF parlance- a non-PnP driver, then you may not have an INF. So again, you should sign the binary.
Of course, if you are inclined to sign it anyway, go ahead. Knock yourself out. No harm done. Your driver will load somewhat faster on a 64-bit system if you do, so there’s even reasonable benefit to be claimed. But it isn’t a necessity.

Why I wrote this? Let’s just say I’ve seen a few too many competent people run afoul of the terminology here and do something less than optimal as a result. You hear “sign the driver”, so you do, and then you still get all the popups, and have to ask for help you wouldn’t have needed if someone had just given you the right information or asked you to do the right task in the first place.

The Case of the Unexpected Overload

BobKjelgaard — Mon, 03 Aug 2009 17:31:44 GMT

So are you using C++ in a KMDF driver and scratching your head over some unexpectedly unresolved references?

I recently engaged in a somewhat prolonged conversation with Doron and a dev I won’t name [since I didn’t ask for permission] about C++ in KMDF driver. This dev (a very good dev, by the way) had hit a stumbling point converting a driver from C to C++ and was wondering if we had ever tried this in QA.

Yes, I know that means he/she doesn’t read this blog, since I’ve mentioned doing just that on more than one occasion. But that’s OK, not many people do- and since I’ve got a tendency to write about whatever strikes my fancy at any moment, and I’m not the most dazzlingly brilliant human on the face of the planet, that’s not much of a surprise to me. You are of course free to believe what you like about that statement.

But in an attempt to be useful today- the problem was one of those that I guess I’ve hit so many times I don’t give it much thought. But it gave our dev a bit of trouble, and not much gives this person that kind of trouble. So perhaps a word to the wise will give the three or four of you still reading this a leg up the next time you use C++ in a KMDF driver.

The Lesson for Today Is…

It was just a simple conversion of a driver from C to C++ (to gauge my familiarity with the process, I did that with a half dozen or more drivers last week, and it was far from the only thing I did that week- in fact the big job was actually that I also made them W4 and PFD clean along with quite a few more drivers I’d already converted to C++- almost two dozen drivers total), but it ran afoul of this little bit of goodness:

typedef
__drv_functionClass(EVT_WDF_OBJECT_CONTEXT_CLEANUP)
__drv_sameIRQL
__drv_maxIRQL(DISPATCH_LEVEL)
VOID
EVT_WDF_OBJECT_CONTEXT_CLEANUP(
    __in
    WDFOBJECT Object
    );

typedef EVT_WDF_OBJECT_CONTEXT_CLEANUP *PFN_WDF_OBJECT_CONTEXT_CLEANUP;

That’s the “role typedef” for any WDF object’s context cleanup routine. The SDV tool can use role typedefs to do a better job of statically verifying your driver code, so some special cleanup typedefs are defined to make it a better tool, and you can see them in this (by the way, everything I’m posting is from the WDK- no deep dark secrets here).

typedef EVT_WDF_OBJECT_CONTEXT_CLEANUP EVT_WDF_DEVICE_CONTEXT_CLEANUP;
typedef EVT_WDF_OBJECT_CONTEXT_DESTROY EVT_WDF_DEVICE_CONTEXT_DESTROY;
typedef EVT_WDF_OBJECT_CONTEXT_CLEANUP EVT_WDF_IO_QUEUE_CONTEXT_CLEANUP_CALLBACK;
typedef EVT_WDF_OBJECT_CONTEXT_DESTROY EVT_WDF_IO_QUEUE_CONTEXT_DESTROY_CALLBACK;
typedef EVT_WDF_OBJECT_CONTEXT_CLEANUP EVT_WDF_FILE_CONTEXT_CLEANUP_CALLBACK;
typedef EVT_WDF_OBJECT_CONTEXT_DESTROY EVT_WDF_FILE_CONTEXT_DESTROY_CALLBACK;

So, what the original driver, being a good sample [because SDV suitability also matters], had was something like this (not exactly like this- nobody with my twisted sense of humor writes sample code, because humor never works globally- someone always takes offense- I’m just not inclined to care about that anymore, because I’m a callous old bastard with less than a dozen years to retirement age and not much “career” left to lose):

// In the header file:

EVT_WDF_DEVICE_CONTEXT_CLEANUP HideTheBodies;

// In the implementation
VOID
HideTheBodies(
    __in WDFDEVICE MortTheMortuaryTechnicianIsOnTheJob
    )
{
...

Of course, in C, that sort of works- but in C++, that says you have two overloaded versions of HideTheBodies- one takes a WDFOBJECT as input, and isn’t defined, because nobody wrote it that way. The one that is defined takes a WDFDEVICE as input. More annoying, of course, is that from the typedef name, you’d expect it would take a WDFDEVICE as input, so it isn’t an error that’s glaringly obvious.

As is- the code will compile fine, and PFD will be happy, too [they’re not the same function, remember]. But when you link it, you get an unresolved reference for HideTheBodies- decorated to indicate it has a WDFOBJECT parameter. Now, unless you really look closely at such decorations (something my fine history of mistyping the simplest of code has taught me to do), you’re looking at a mystery. It took my colleague digging through preprocessor output and object files and such to finally hit upon the error- a reasonably annoying circumstance!

Another thing you can do (and this is what I usually do) is tie the callbacks to the context itself (with the context a class) as static member functions, as I described earlier (effectively you do the cleanup by calling the context’s “delete” operator). PFD currently doesn’t match the roletype if you do this, so I suppress those warnings (and there is no SDV for C++)- I think we’re trying to get that fixed… But the compiler will catch the parameter type mismatch- a bit earlier than the linker.

But I’ve hosed this both ways- so, until something on the subject gets posted by a recognized authority, this post can at least be found by the diligent searcher…

Having trouble with WTT Logger from your WDTF script?

BobKjelgaard — Thu, 30 Jul 2009 14:42:00 GMT

Just a quick note, since someone asked about this recently on one of the WDTF support aliases and for a change, I actually knew the answer without looking it up.

The sample scripts will try to create a COM automation object from the ProgId WTTLogger.Logger.

The file you are looking for is named WTTLogCM.Dll, and all you need to do is register it:

Open a command prompt (administrative, I believe).
Regsvr32 <path to WTTLogCM.DLL>
Popup should say DllRegisterServer succeeded.

That’s it! You can unregister it later with regsvr32 /u.

You can find the file in the WDK- in the server 2008 WDK (6001.18002) it lives in tools\wdtf\<arch>\redist\Extras. If you look through the WDK tree, you may also find a wttlog.dll- wrong one! For the curious, that’s got a direct call interface for native code apps- but that’s not suitable for scripting.

Happens I’ve been developing a couple of COM automation in-process servers of the same type for some of my own test tools, and I live and die by WTT, anyway- so for a change, the answer was a no-brainer…

2008 DDC slides now available to all!

BobKjelgaard — Wed, 22 Jul 2009 14:24:33 GMT

Got an email late last week stating that the material I and others presented at the 2008 Driver Developers Conference (which Dieter and James want renamed to Driver Development and Test Conference- more power to that idea!) is now available here.

The sessions I participated in are a description of several WDF test technologies and some hand waving about troubleshooting WDF installation problems.

If you are a tester, you might also want to take a look at James and Dieter’s presentation on concurrency testing, and who wouldn’t want to know about the new Driver Verifier features for Win7 (ably presented by Daniel Mihai)? I also recommend the presentation on DSF, because in many ways I live and die by DSF.

That would be “Device Simulation Framework” if the acronym is unknown to you. Sooner or later, having an easily reproduced software simulator for a device trumps going to EBay to buy some long out-of-production hardware your test driver must have… That’s just one reason I like it, but that’s all I have time for now…

There’s more- but that’s why it’s called a “browser”, eh? By all means, browse!

As for why it took so long to make public- remember this conference occurred under non-disclosure agreements. Takes some time to unravel things and get all the requisite hoops jumped through.

He’s Gone

BobKjelgaard — Fri, 26 Jun 2009 05:15:16 GMT

It has been a tough week, and a busy one. I’m getting ready to leave on a vacation, and trying to get all those last-minute things done.

While my last post discussed the genesis of what I call the Configuration Agent and the WDF QA Universal Setup Job, this week’s focus has been entirely on another of my oddball notions- it started as a desire to build a more precise fault injection engine for testing the KMDF loader. With that California background, the project name was easy- Fault? Why, San Andreas, of course!

At a high level it was a programming model built around IAT filtering of calls from a driver into the kernel. I wanted precision, so I could specify behavior by thread and IRQL, program each DDI independently, allow a driver to do its own filtering [i.e. get a callback with context for a DDI call under given conditions]- and with enough flexibility and locking behavior that the behavior could be reprogrammed within such a callback. For instance, in one working application of mine a filter on calls to IoCallDriver from the KMDF runtime were routed on specific threads to a callback in the test driver which then turned off all call logging, as it meant the call was leaving it’s stack location- I was using the logs from calls to various resource allocation DDI to make sure the framework did not allocate resources under conditions in which we contractually would not fail- so I wanted to stop logging before I called IoCallDriver and to restart it after it returned [I knew the driver handling it was synchronous- otherwise I would have to hook the completion side of things, of course].

So the concept went well beyond fault injection, but it’s always been a side-line. My initial tests wound up being very white box, and a refactoring of the loader code meant a similar rewrite of the test was necessary, but there was no time to do that… But with Windows 7 winding up [since we’ve announced dates, that can’t qualify as a secret anymore], I have time to go back and try to at least do a few new things beyond mere maintenance. Such time is rare and fleeting, so I’ve been busily making the most of it.

So today was busy- I worked a bit of overtime on a COM automation server (in process) exposing a scriptable interface to my engine for some of the other team members to use, and got it at least working well enough to demo. Still have my packing to do, and dinner to make and so forth, so home I headed.

Then I turned on the television, and immediately heard the news about Michael Jackson. Whoa…

On those old tapes I’ve been scraping for my archives I’ve got many covers of his material from the time I was playing in bar bands: Billie Jean, Thriller, Beat It- and more. I’ve not posted them because frankly I never thought I did any of them justice- a lot of my material from those days has rough edges [anyone who listens to what I have posted can hear that], but these were just not good enough. But add me to the billions of fans, then and since, sure…

The other thought that came early on was that in my previous post I mentioned having learned to keep some of my more controversial opinions to myself- one of those was intense skepticism about the molestation accusations. I knew I wasn’t likely to sway anyone there- so why bother?

He’s gone, and he was younger than I am- scary stuff. Life is fleeting, and it was an unexpected reminder of that.

But, it’s time to pack my CDs and games and controllers, write those last few checks for bills coming due during the vacation. eat that dinner, and get ready for a night’s rest prior to that final day of work, so another slapdash post, and back to work…

There was some offsetting good news today- besides finding out I really do still remember enough about COM to roll out an in-process automation server on the QT- without using ATL of course, where would the challenge be in that [answer: in learning something new for a change- you old dog!]? But of course it falls into that semi-confidential area where I’ll just have to sit on it for a while [not that it’s likely to shatter the world if revealed anyway, but circumspection is worthy of practice even for an old blowhard like myself].

I’ll try to do something more substantial someday- these days I’ve just not got the time to really write anything too terribly technical. My apologies to those diehards who still try to read this awful stuff I’m churning out of late…

Crazy is as crazy does

BobKjelgaard — Thu, 18 Jun 2009 23:57:00 GMT

When I was an undergraduate at CalTech, my student residence- Ricketts House- had a tradition where we relieved some of the tedium and stress of the annual election for house officers [President, Vice-President, Social Vice-President, Secretary and Treasurer was the lineup if memory serves me well] by nominating and electing people to “Minor Offices”. [Looking at the Wikipedia link, I see I probably fit the Scurve profile more than I had realized- I’ve had many problems since with holding controversial and unpopular opinions- now that I’m old I just keep them to myself more than I used to].

This process was largely temporized on the spot, and usually fueled with socializing, various recreational substances and a great deal of levity. Some offices had “duties”- for instance, the RLPL (Resident Lecturer on Pornographic Literature) was in charge of the acquired collection of said “literature”- and in self-defense I’ll add that this had been an all-male school until a year or two before I arrived. Others (such as the “House Christian”) were largely symbolic- often made up and discarded as seemed appropriate to the assembled wits at the time. [To put the RLPL in context, I remember utilizing the service to read a Playboy interview from the mid-60’s, of Jerry Garcia, so it wasn’t always the porn that was the draw].

My purpose for the aside and the title of this post combine. During my tenure, while I never held an elected office, I was elected several times to one particular office- “House Crazy <a word I cannot use on MSDN, or email, or say on public broadcast- I suppose “F-bomb” comes close enough>”.

I’ve always had a quirky sense of humor, and I displayed it a lot during those years, so I suppose I deserved the title- things like taking a philistine swipe at some of the campus art being acquired by building a “sculpture garden” that included discarded urinals I dragged up from the basements [I swear you could find anything down there, if you looked long enough], stacks of chairs, umbrellas, discarded lumber- all tastefully arranged for display of course- and I really liked building things off-the-cuff with precarious and eccentric balance to them, so there was some “art” involved, in at least one sense of the word. The darbs sort of liked it- I doubt the Master of Student Housing liked it, since we titled the display with his name. Never can tell, though- some people actually can take a joke [I usually try to]…

Another factor was being a pyromaniac- I can remember holding a drinking glass with some burning gasoline in it [not a lot- maybe a few millimeters, before it ignited] at one point [only because I had to find a place to toss it, to avoid injury to myself- with a bunch of people crowded around it took a while to find one- even at that somebody insisted I was throwing it at them- not the case- at that distance I wouldn’t have missed…], and at another being asked to detonate an explosive mixture someone had painted on an exterior window and then decided they didn’t feel safe either leaving or igniting- in normal form, I used a long rolled up piece of newspaper, ignited one end, set the other against the frame, and then ran, barefoot as always, across the roof tiles, which were often littered with shards of gritty nasty stuff, but my feet were long since tougher than that [of course this wasn’t on the ground floor] to get out of range. But it was a bit of a letdown, that time- not sure it even shattered the window- where’s the fun in that?

I suppose I did earn the title [and I believe I paid for most of the damages, as well, but that would be even more off-topic stories]…

So today I find other outlets, and wanting to write something before I go on vacation without having posted anything in almost two months, I’ll pick one at random and see if it’s worth talking about.

Endless Dogfood

“Dog Food” is what we refer to new and unreleased software as, here at Microsoft. Using it means you are helping those who are developing the software as an adjunct tester, and being a helpful sort [as are most of the other ‘softies I know], I participate when I can. But it brings its issues, particularly if you are using it for real work- and if you’re not using it for real work, then just how is it you are helping?

To test KMDF and UMDF, we use a lot of tools- many of which you know. But to maximize the potential return of our test effort, I want to “dog food” as much of it as possible. That’s not as simple as it sounds- these are just a few of the issues experience has shown me:

most products under development are built frequently, with multiple versions shared out from their “release shares”.
The form in which those shares are presented [in terms of paths to specific processor architectures, for instance] has some variations.
Sometimes when a product goes bad, you have to get it from somewhere else, such as a private build.
Or you may have to stick with a previous fixed version for a while.
But most of the time you want to get as much as possible from the same place, because some people won’t even talk to you if they see you doing much mixing and matching.
If that mixing and matching includes things that go into driver packages [and it does for us], then cataloging and signing becomes an issue.
Worse yet, since we do our own servicing, we sometimes have to run signed content used to test our older products whose signatures have expired and are no longer valid.

We used to make horrid ad-hoc changes to handle these things- breaking paths down into “parameters” banged together in explicit paths to form a full path, for instance. Done differently for each automated test, of course. To get a test run by someone else, you had to communicate a complicated list of these “parameters” to whomever was running it, and they had to get all of them right.

One day I decided I’d had enough, and out of that was born one of those custom designed solutions that is probably as quirky as the problem it solves. Not the global sort of solution Microsoft sells to people, but the kind of stuff a lot of people in IT or support roles have to build just to survive.

In the amalgam that is my work life, this became part and parcel of a task I was doing at the same time, which was to bring some commonality to all of our test setups, so it was easier to look at a machine on which a problem had been reported and know what you were actually looking at.

Simple Mind, Simple solution

So I started with some basic rules:

One setup job goes out, finds all the tools we use, copies them to the test machine, and sets them up.
Individual tests never go to the network for anything- if someone needs something, we add procurement of that to the setup job.
The setup job will own making sure that everything is signed.
The setup job is going to be very smart- no more complicated instructions. Our most common test requirements should be its defaults, and if we need something run outside our group, all that should be needed is one reasonably mnemonic string value, used as a parameter, to identify the machine configuration we are testing.
The setup job is going to log where everything that is pulled off the network came from in easily accessible form, including a history of such locations from previous runs of that same job if it gets run more than once after a new OS is installed.
It will be easy to tell it to get the most recent version of anything we use- but it will also be possible to tell it to get a specific version. Our team will own making sure that knowledge is there in a fashion that we can meet bullet #4 above. Bet you thought I’d forgotten I’d mentioned dog food earlier, didn’t you?
Everything we use is to come from a supported source- not some file someone stuck on a share somewhere that had no clear ownership [or symbol files, usually…].
Experience says there will always be some need for temporary exceptions to that last one- so put all those eggs in one basket and watch that basket closely.

Well, WTT does provide some facilities aiding in what we wanted, but it was not at all close to everything we needed. So it was time to invent.

First, I broke the job into phases:

An Analysis phase where it takes that single parameter, along with some database of recorded setup knowledge, and determines for itself [by checking the appropriate shares] if all the pieces needed are available, and if they are, which specific places to get them from. The results of this phase are “cast in concrete”, and the subsequent phases will use this information and only this information- not go looking again [which causes problems when things change between the analysis and when they get around to looking, for instance].
A “staging” phase where anything that isn’t already on the machine is copied to the machine. The places copied from are determined by the preceding analysis. If it starts out on the network, and you need it on two places on the machine- this phase has to copy it to the machine first, and then from one place on the machine to the other. It is also not a problem if later jobs also do such copying- as long as they never go to the network again.
Finally, a “configuration” phase where tools are installed [from MSI or such already copied in the staging process], registries tweaked, and the machine is made ready for testing. At this point, any of our jobs should be able to be run in any order [and one benefit here was we can now test either KMDF or UMDF where we had previously been one or the other].

That done, it was time to make it a reality…

Maybe not so simple, after all

First of all I needed that way to record values so they were usable both by WTT and by scripts and command line apps and whatever else without too much intervention. Some research and experience aforethought turned up the answer, and it was almost as old as I am- the machine’s global environment is accessible to all of them, it can be updated with simple registry operations, and you can even make the changes immediately recognizable to all the pieces that really count by broadcasting a Windows message when you finish the updating [Wei indirectly clued me in on the last part- he observed that if he used the control panel the changes were immediate, even on open command prompts, but not after using one of the early versions of this code].

Then there perhaps would have been the signing issue, except that we had been working on that one- we had found that we could catalog and self-sign everything and that seemed to cover everything [eventually this has had some holes, on pre-Vista OS, but I’m working on them when I can]. But we were using a copy from some WDK stuck on a share- see rule #7 above!

So, I now needed some way to encode directions about where to find things how those directions changed under various circumstances, and how they differed under certain test requirements, and something that would take that information and create those environment variables. It also had to meet my logging and reporting requirements.

I wound up with another ancient solution- Windows private profiles [aka INI files]. As I’ve already taken up too much time composing this, I’ll have to continue the story at a later date…

Not all of them

BobKjelgaard — Thu, 07 May 2009 20:44:33 GMT

Alas, all that stuff I mentioned in my last post won’t make it into the Windows 7 WDK.

As we get close to the final days of the product cycle, it gets harder to justify code changes. In this case, my own choices in handling odd cases were my undoing.

In a nutshell, if I can’t identify the KMDF client driver version, I treat it as if it is the same as the runtime. Since the only version I can’t identify is KMDF 1.9, and a 1.9 driver won’t even load unless the runtime is 1.9 or higher and there is nothing higher, I can’t really claim something is broken besides some text that says what the real version is. All the rest of the relevant UI function will be correct, as de facto, it will be treated as a 1.9 driver, and that is what it is.

Well, they say there will be service packs for the WDK, perhaps this will make one. If not, at least I had my fun, and the tool does work pretty much as it should.

I just designed it too well- yeah, that’s the excuse du jour…

Exceptions rule!

BobKjelgaard — Sat, 18 Apr 2009 19:24:55 GMT

I’ve decided to revert to storytelling mode today. So sit right back and you’ll hear a tale, a tale of my fateful trip (or click something useful- you’re the one deciding, and I’m the one typing to satisfy whatever inner demon has driven me to do this today)…

It began when someone found a bug in the static version of KMDF- the one almost nobody gets to use and which we have been trying to discontinue any support. But people were still using it, and we had no clear migration path, and there was a bug. So we decided to begin testing it. Poor Neslihan got that task (well at least it wasn’t me, this time). Soon we had added a static KMDF driver to our list of test drivers used in our daily automated testing.

Then, of course, we got the bugcheck. As often happens, I played “Johnny-on-the-spot” and (virtually speaking) leapt onto the remote debug session accompanying the report. Buffer overflow? In FxDriverEntry? But only on Itanium (I checked the other architectures that ran the same test, of course- no problems)? What in blazes is this about?

Well, the method is well documented, and not all that hard to understand- a “cookie" gets initialized, it gets stored to the local stack frame in such a way that code overflowing buffers in the stack frame will overwrite the stored copy. On exit, code gets called that checks that value to see if that happened. It’s a little more complicated than that, and I’m not going to be precise, because part of that complication is related to securing the method against the sort of people who like to exploit buffer overflows [so I’m not going to make the method clear for them- they can do their own research without my assistance]. The bugcheck analysis will even tell you the two values- expected and actual, making it easy for people who really think overflows are a bad idea to make a quick guess as to where the overflow came from.

But the circumstances seemed suspicious, so I went and read the source code- H’mm- there’s a default value the cookie is initialized to… Interesting- that’s the value we have- but it doesn’t match the expected value.

At which time, something I’ve known for years hit me like the proverbial sledgehammer- our entry code calls GsDriverEntry (which supports the stack probes inserted by the GS compiler switch, hence its name) when it finishes. GsDriverEntry initializes the cookie, which means that that was why the values didn’t match. Like the sword of Damocles, this had been hanging over our heads for years- the first time the compiler decided to do stack probes in our entry code, everything would break. Ouch…

I’ll leave a bunch of story out here- things got “interesting” at that point, but the problem eventually got solved, both for us and for other people facing similar issues, as well. Short answer is that everyone now initializes the cookie right at the start, just as should happen…

But a while back I had occasion to tweak the build process for the WdfVerifier WDK applet, and afterwards I ran it briefly to make sure I didn’t break anything in the process. Oh, joy of joys- NONE of the 1.9 client drivers are being properly identified. They are all identified as “Inbox”, which is what I do when the client identification method I described last year fails on me.

Already beginning to panic, I think- did someone change FxDriverEntry, and I didn’t even notice it? So I go to our source control system, and look at the change history. The most recent change is the fix for the problem with the stack probes (yes it occurred on static, but what scared me then was it could have happened to any version, because were weren't doing things properly). But that just calls library routines to initialize said cookie… Oh, blazes, those routines must be calling an import I wasn’t accounting for!!! Why??? Because I NULL the IAT to force access violations, and I handle the exception by giving up on getting the true version, and fall back to calling it “Inbox”- which is, after all, exactly what I am seeing. Oh, well- so much for my having thoroughly considered all the test and product consequences of that change when it was made…

Well, easy enough to find out what that import might be. One nice trick Ilias showed me is that you can open any binary in WinDbg as a crash dump, and happily resolve symbols and disassemble code. So I pick a random driver on my dev box, and do so.

What, no imports? But, but--- hmm- it uses a fixed address (load of a 64-bit immediate value into RAX, since my dev box is an X64, thank you- you x86 dinosaurs can keep your wimpy processors). What’s with this?

The answer lies in wdm.h, of course- KeQueryTickCount turns out to always be a macro- on x86 and IA64, it accesses KeTickCount [which is an import, and if you followed my earlier tale, it’s clear adding an import to my existing hack-o-matic mechanism is a trivial task]- but on X64, it accesses an essentially hardcoded address in a “SharedUserData” area. This snippet is from wdm.h, so you can see for yourself…

#define KI_USER_SHARED_DATA 0xFFFFF78000000000UI64

#define SharedUserData ((KUSER_SHARED_DATA * const)KI_USER_SHARED_DATA)

#define SharedInterruptTime (KI_USER_SHARED_DATA + 0x8)
#define SharedSystemTime (KI_USER_SHARED_DATA + 0x14)
#define SharedTickCount (KI_USER_SHARED_DATA + 0x320)

#define KeQueryInterruptTime() *((volatile ULONG64 *)(SharedInterruptTime))

#define KeQuerySystemTime(CurrentCount)                                     \
    *((PULONG64)(CurrentCount)) = *((volatile ULONG64 *)(SharedSystemTime))

#define KeQueryTickCount(CurrentCount)                                      \
    *((PULONG64)(CurrentCount)) = *((volatile ULONG64 *)(SharedTickCount))

My. my. my- this is a problem- no import I can just tweak to point into my code. For a plus, at least the value can’t change (if it did, existing drivers would, after all, cease to work)- well, at least not easily, so I’ll save any remaining paranoia about that for another time. But I’m going to access violate trying to access that address in user mode (not to mention the reams of experimental evidence I had just accumulated by noticing the problem in the first place)…

So in reading about exception handling, a phrase happens to catch my eye- putting it in my words, it says that when continuing an exception, you can alter the context record supplied to you with the exception (and I know this process well, but that’s perhaps a story for a different time). Whoa- that must mean I can change the contents of the registers programmatically, and then tell it to repeat the failed instruction! Now, I can’t find that illustrated in any of the samples the material I’m reading points me to [nor could I find it an an internet search, although the latter was by no means exhaustive]. But that HAS to be what it means, right?

So I start coding- first the half dozen or so lines needed to handle the KeTickCount import. Then an exception filter [only for AMD64, of course]. The logic is my usual bit of precise work: If it is an access violation, and if it is a read, and it is a read of that exact address, and one of the integer registers in the context record has that same address, then change that register’s entry in the context record to the address of the proxy I’ve decided to keep in WdfVerifier, and tell the OS to repeat the failed instruction. I began with RAX, because after all, that’s what I had seen in my investigation, and it seemed the most likely place for a while, but I added the whole set since under the circumstances, it seemed unlikely to do any harm. Anything that didn’t match that exact pattern, and I gave up- just execute the handler, which does nothing. The attempt to run the driver entry code to extract the client version will fail, but WdfVerifier keeps running, and the machine itself is still quite safe from my hackery.

Worked the first time, it did (not counting my usual compiles to get rid of typos). Problem solved. Total work time from start to finish- something like 5 or 6 hours- good enough- after all, I did have to do some research… Of course, there’s always somebody who can do it better, faster, and quicker- and they usually jump out of the woodwork if I start talking about things in that fashion, but it’s my story, so I’ll brag now and regret it later…

Exceptions do indeed rule! I love it when a plan comes together…

A glimpse now at handling the new import…

    //  The descriptors are an array of entries per module, each terminated with an all-0 entry.
    //  Each entry has an RVA for the module image name, and a second for a 0-terminated list of RVAs to the structures used for
    //  resolving names of exported entries from the module (in loading these get resolved to real addresses and are plugged into
    //  the loaded image's import address table in the same order).  So we now know how to write an image loader if we need to...

    //  First, find the descriptor for the KMDF loader, and quit if it isn't there.
    DWORD   StringCopy = (DWORD) -1, WdfBind = (DWORD) -1, InitEvent = (DWORD) -1, TickCount = (DWORD) -1; 

    //  Then look for the Bind and Unbind entry points.  Case counts!

    enum {OutdatedTechnology, HasBind, HasUnbind, OneCoolDriver};
    
    BYTE        TargetIdentification = OutdatedTechnology;

....

            else if  (IsKernel)
            {
                if  (0 == strcmp("RtlCopyUnicodeString", (PSTR) NameDescriptor.Name))
                    StringCopy = ImportsIndex;
                else if  (0 == strcmp("KeInitializeEvent", (PSTR) NameDescriptor.Name))
                    InitEvent = ImportsIndex;
                else if  (0 == strcmp("KeTickCount", (PSTR) NameDescriptor.Name))
                    TickCount = ImportsIndex;
                
                ImportsIndex++;
            }
.....


        DWORD       IATSize, RelocationsSize;
        LONGLONG    OurFakeTickCount = 0x8badf00ddeadbeefI64;   //  ersatz Tick count         
        PVOID*  ImportAddresses = (PVOID*) 
            ImageDirectoryEntryToDataEx(DriverImage, TRUE, IMAGE_DIRECTORY_ENTRY_IAT, &IATSize, &Unused);
        
        PIMAGE_BASE_RELOCATION  Relocations = (PIMAGE_BASE_RELOCATION)
            ImageDirectoryEntryToDataEx(DriverImage, TRUE, IMAGE_DIRECTORY_ENTRY_BASERELOC, &RelocationsSize, &Unused);

        if  (NULL == ImportAddresses)
        {
            FreeLibrary((HMODULE) DriverImage);
            return  true;
        }

        //  Plug them in here, and we are good to go!

        DWORD   OldProtect;

        if  (!VirtualProtect(ImportAddresses, IATSize, PAGE_READWRITE, &OldProtect))
        {
            FreeLibrary((HMODULE) DriverImage);
            return  true;
        }

        memset(ImportAddresses, 0, IATSize);

        ImportAddresses[StringCopy] = FakeOutStringCopy;
        ImportAddresses[WdfBind] = CollectVersion;
        if  (InitEvent != (DWORD) -1)
            ImportAddresses[InitEvent] = FakeEventInit;
        if  (TickCount != (DWORD) -1)
            ImportAddresses[TickCount] = &OurFakeTickCount;

        VirtualProtect(ImportAddresses, IATSize, OldProtect, &OldProtect);

So for some other glimpses, this is one part of the other hackery (complete with my elementary-level annotations):

class AllKMDFDrivers
{
    MachineKey&             Owner;
    KMDFDriverList&         InstalledKMDFDrivers;
    LoadedDrivers&          CurrentlyLoadedDrivers;
    LoaderDiagnosticsFlag   LoaderFlag;
    String                  RuntimeVersion;
    DWORD                   Major, Minor, Build;

    bool            ServiceUsesKMDFLoader(__in PCWSTR ServiceName, __in RegistryKey& Service, __out MyBindInfoAlias& Binding);
    static void     FakeOutStringCopy(__in PVOID, __in PVOID);  //  Fake RtlCopyUnicodeString entry
    static void     FakeEventInit(__in PVOID, __in ULONG, __in ULONG);  //  Fake KeInitializeEvent entry
    static ULONG    CollectVersion(__out MyBindInfoAlias& BindingOut, __in PVOID, __in MyBindInfoAlias& BindingIn, __in PVOID);
#if defined(_AMD64_)
    static LONG     Filterx64Exception(__in EXCEPTION_POINTERS* ExceptionInfo, __in LONGLONG& FakeTickCount);
#endif

While the rest of it looks like this (and again, this is partial)- yes, feel free to hate my stylistic indifference to the herd- perhaps I’ll get fired for this, and all can breathe a vast sigh of relief…

First, the code that calls the filter

        MangledDriverEntry  CrashAndBurn = (MangledDriverEntry) ((PBYTE) DriverImage + EntryRva);

        __try
        {
            CrashAndBurn(Binding, &Binding);
        }
#if !defined(_AMD64_)
        __except(EXCEPTION_EXECUTE_HANDLER)
#else     
        __except(Filterx64Exception(GetExceptionInformation(), OurFakeTickCount))
#endif
        {
        }

and now our filter:

#if defined(_AMD64_)
/**********************************************************************************************************************************

LONG    AllKMDFDrivers::Filterx64Exception(__in EXCEPTION_POINTERS* ExceptionInfo, __in LONGLONG& FakeTickCount)

Ahh, the joys of low-level intervention by the truly incorrigible!  On AMD64, we will get an exception when the code tries to get
the tick count.  This value resides at a known address (which cannot change because if it did, all existing drivers would then fail
to work- although I suppose someone could resort to what I am about to do- bring it on, I'll see if I can keep up with the absurd
arms race).

So, first, verify from the exception record that we are getting an access violation of some sort reading that known address.  Then
see if one of the integer registers has that address (start with RAX, since that's where it currently is, and I bet it doesn't
change much).  If it does, change it to point to the value given to this function (which resides in WdfVerifier, since I made it
a reference, and will let the compiler play enforcer), and then continue execution.

In all other cases, execute the handler, which will do nothing (meaning the version will continue to be unknown).

**********************************************************************************************************************************/

LONG    AllKMDFDrivers::Filterx64Exception(__in EXCEPTION_POINTERS* ExceptionInfo, __in LONGLONG& FakeTickCount)
{

    //  cf definition of SharedTickCount in wdm.h
    static const DWORD64    KnownTickCountAddress = 0xFFFFF78000000320UI64;

    if  (NULL == ExceptionInfo || NULL == ExceptionInfo->ExceptionRecord || NULL == ExceptionInfo->ContextRecord)
        return  EXCEPTION_EXECUTE_HANDLER;

    switch  (ExceptionInfo->ExceptionRecord->ExceptionCode)
    {
    case    EXCEPTION_ACCESS_VIOLATION:
    case    EXCEPTION_IN_PAGE_ERROR:    //  Unlikely, but what the heck...
        if  (2 > ExceptionInfo->ExceptionRecord->NumberParameters)
            return  EXCEPTION_EXECUTE_HANDLER;
        break;

    default:
        return  EXCEPTION_EXECUTE_HANDLER;
    }

    if  (EXCEPTION_NONCONTINUABLE == ExceptionInfo->ExceptionRecord->ExceptionFlags)
        return  EXCEPTION_EXECUTE_HANDLER;

    if  (EXCEPTION_READ_FAULT != ExceptionInfo->ExceptionRecord->ExceptionInformation[0] ||
        KnownTickCountAddress != ExceptionInfo->ExceptionRecord->ExceptionInformation[1])
        return  EXCEPTION_EXECUTE_HANDLER;

    if  (KnownTickCountAddress == ExceptionInfo->ContextRecord->Rax)
    {
        ExceptionInfo->ContextRecord->Rax = (DWORD64) &FakeTickCount;
            return  EXCEPTION_CONTINUE_EXECUTION;
    }
    else if  (KnownTickCountAddress == ExceptionInfo->ContextRecord->Rbx)

The rest I leave as an exercise to the reader, having already put all 0.378 of you through the treadmill today…

Progress

BobKjelgaard — Fri, 13 Mar 2009 16:22:13 GMT

When I first got the idea of digging up my old tapes and digitizing them before I lost them for good, I was chatting with another ‘softie (I believe it may have been Craig Ziegler, who manages the test team for the WDK) at the big party during WinHEC 2008 (so I did do something there besides play Halo 3). At about that time, the music being played switched to the Donna Summer classic “(She works) Hard For The Money”. That was one of the tunes I wanted to see if I could capture one of my “covers” of.

Perhaps in part because of that Grateful Dead influence, I was always a very improvisational player- that song was a part of my bands’ repertoire through much of the 80’s, both when I played the bass, and later after i switched to the guitar. I always liked it, and my approach to it was always laden with drama- lots of energy, catchy motifs [well, I though they were catchy], strong attacks on key parts- perhaps overly bombastic- but hey, that’s how I thought it should be played and I was the one with the instrument. While I was aware of the underlying theme the song had, I always treated it more as an anthem for women in the workforce. In part because my career included an era where things were a lot tougher than they are now. “She works hard for her money, and you better treat her right”.

I’ve managed to find two instances that I play in my office (and in my car, and on my xBox, thanks to that fine SanDisk USB thumb drive I got as a WinHEC freebie)- one where I play the bass in a live performance [and I thought it captured the nuance of that night well]- the other with guitar- but it was at a practice, and fairly early one- so the leads aren’t very inspired, there are presentational inconsistencies [more than usual], and I make a few more flubs than usual. I know I had at least one solid live performance on guitar, but I may have lost that tape. Ahh well, now that I’m practicing again, maybe I can recreate those lost glories- not that anyone but me actually cares, but one ought to have some purpose in life, right?

At any rate, while listening to the two of them back-to-back last week, the basic idea of this article came to me. So perhaps this will be less half-baked than others have been…

I’ve been fortunate enough to have had several women as managers or coworkers [I also employed quite a few at the Laundromat, had more sisters than brothers, and my mother was herself a strong influence on me]. I owe most of them some debt of gratitude.

My first long-term job after graduating from Caltech was at IBM in Owego, NY. The interviews there were interesting to me- I had two in their Electronic Design Automation group, and it was one of those experiences where you just light up and enjoy it. I’d been working as an electronics technician on and off since graduation (one of the things I had acquired and needed to rid myself of during my college years was a distaste for computer programming, which had been one of my first loves prior to that- I had decided I’d rather work toward being a EE, instead), and had been thinking about application of computers to digital circuit design and testing. I’d discussed some of them with coworkers and had the “not possible- way too hard- you’re crazy to think like that” kind of response- but here I was interviewing with a group that was doing exactly that- and it was working quite well. Since I’d already been thinking along those lines, I could ask intelligent questions, etc. The interviews went well.

But I did terrible things at Caltech- things like skipping exams because I knew I would get a passing grade without taking them [not a good grade, just a passing one]- so I had a rather poor GPA. Low enough I did not meet the corporate hiring guidelines. The hiring manager seemed to consider me a bit of a nerd, and he also judged a lot on those numbers. His manager was a woman- she had attended grade school near Caltech, and I had also interviewed with her. She intervened, and I was hired in spite of some resistance. So I definitely owe a woman my first good start in the high-tech industry.

But the things I used to hear! That she had to agree not to have a family life in order to have the management job, for instance. Or later, assertions of tokenism. In those days, I was pretty naive- so it was hard to judge how much was true, how much was cattiness, how much was just plain made up out of spite and jealousy. So I may have accepted more of it as truthful than I should have. But it didn’t seem fair. So as she progressed (at least as far as a divisional vice president, last I knew) I gave a few silent cheers, and didn’t contribute to or spread all the gossipy stuff.

The working environment certainly wasn’t friendly- that much was true. One incident I recall later in my tenure there was my mentioning pointedly in an employee poll the plight I observed of one of my fellow engineers. The men hired at about the same time as she was had been given desirable assignments and good career paths- high-profile design and engineering tasks. Her assignment was to track equipment being checked in and out of the equipment closet. When she agitated for something a bit more technical, she was given a project that was clearly doomed to spectacular failure (budget had already been spent, technical approach was flawed in the opinion of most of the experienced engineers on the team, etc). I had a distinct sense that this was deliberate and retributive and found it reprehensible. Such opinions of course had to be written, and my writing style is distinct enough it was clear who raised the issue- only deliberate obfuscation of submitted material could have hid it, and no place I’ve ever been that conducts such surveys resorts to that. So I shouldn’t have been surprised that the next project that came along that I had a strong interest in was given to her. But that was probably a good choice, as it turned out- I pushed way beyond my limits in those days- she was a bit more sensible.

Now I don’t think what I was seeing matched the desires of the top management of the company, even then [and I’m equally certain it would not be regarded positively now]. I’m merely discussing perceived changes from my viewpoint. Cultural changes- both societal and within other aggregations such as a corporation, take time. Personal change as well, [and there’s been a bit of that, fortunately] for that matter.

After coming to Microsoft, I experienced what at the time I would have termed a more “liberal” working environment. Family leaves, etc. While women were rare, there wasn’t quite the same sense of class difference. I tried to take some of those lessons to heart when I was the boss [the Laundromat again]. I tried to provide flexible arrangements, allowed employees to bring children to work when there were day care problems, etc. The pay was terrible (as I’ve noted elsewhere, the venture bankrupted me in all but the legal sense of seeking the protection), but I wouldn’t have paid a man more. I always paid more than minimum wage- but not much more. So I suppose in that sense my employment of them could be deemed exploitation- but that certainly wasn’t my intent.

I’ll skip over a few bits of reminiscence- don’t need them. Today I find myself working for a woman again [and one could even argue she was promoted to the spot over my head- it happens I don’t have a problem with that, though].

Now I could go on about how well I think that turned out [she’s a good leader, I’ve said it before, and I still believe it, and try to do what I can to help], but that’s not what I intend. It’s the difference in environments across that span of time, and the direction of the progress as I see it. Sometimes she works from home- sometimes she has to drop things to attend to family and child care issues. Nobody sees anything wrong with that, as far as I can tell. It doesn’t affect her being an effective leader or manager. The organization supports it, and we as her team support it.

After mentally composing much of that, I found we have new board member- again a woman, and computer science professor…

With a daughter of my own soon to enter the work force- it’s good to consider these things. There has been progress- the journey may not be over, perhaps many are not satisfied with the pace- but at least it’s the right direction. I consider myself fortunate to work for the company I work for- that it values these things, and makes these efforts- to produce a more inclusive and diverse workforce. One that respects these things and its employees.

Now Playing: Troy- Ghost in the Shell: Stand-Alone Complex Soundtrack- Monochrome

Using C++ in a KMDF driver part 1- a pattern for using contexts as objects

BobKjelgaard — Thu, 12 Mar 2009 16:36:59 GMT

This is an article I’ve started probably close to a dozen times since I started this blog, but never published. In part because of all the heat the topic of using C++ in the kernel generates, and the rest perhaps because of my reaction to that heat.

So I’ll get one thing off my chest at the start and perhaps that will be enough to let me proceed.

I’ve been writing drivers with C++ in the kernel (or the Win 3.1/9x/ME VMM) pretty much since I began using the language (in the very early 90’s). I routinely use paged code (paged data not so much- I’ve never had designs where there seemed to be any benefit to it). That spans more than a decade- in fact, its close to two decades now.

I’ve NEVER had a problem with the issues raised in the paper. I’m not even going to link to it. If you want to find it- it isn’t hard to find. On top of that, in a determined effort to find people who had, I didn’t find many- and the one clear case I did find was cured with a #pragma that would have made sense if you were a C programmer and had a basic understanding of where VTABLES and such get emitted to. So I personally have a sense of mismatch between my own experience and the strongly worded severity there.

I’ve been told that if I persist, I’ll deserve all the paging problems I get [and that nobody will help me with them]. Well, I do get them (always have), and I’ve been developing long enough in this environment that I don’t really need anybody’s help to find the root cause of a bug like that. The causes are always the ones I remember- acquiring a spin lock in pagable code- making a routine pagable that can be called at elevated IRQL- all the usual ways to screw up in that other language that is the hallmark of a true first-class kernel developer. But none of them had anything to do with my choice of programming language. Not once. Not saying that it never happened across all those years, because in the early ones, the ability to catch a bug like that was severely limited- there was no Driver Verifier, no static analysis tools. So it may not have been noticed early on. But now that I have them, it’s still not happening…

Now there can be plenty of reasons for that- but I look at what people take away from the paper, and I do a lot of the things they think aren’t safe. I use polymorphism and inheritance freely. I don’t use multiple inheritance a lot, but I have used it and have not observed problems arising from its use. On the other hand, there are common features that I don’t use as a matter of personal preference or style that may bear on this. I don’t expose the implementation of functions in header files (meaning the compiler is not going to start out by inlining them and then give up later, dumping them in some unintended segment) with the exception of trivial accessor functions. I don’t use templates (I’m not sure they were a language feature when I started, but at any rate, during my learning curve I never needed them, so while I can handle code with templates, I don’t use them myself). I almost always code my own constructors, destructors, copy constructors and assignment operators (I usually have to- I prefer references to pointers and if you have reference members, the compiler can’t generate default code for most of those routines).

So now that its clear I’m not going to walk the company line on that topic [the opinions I expressed ought obviously to be clearly my own], I’ll proceed to something more useful…

Leveraging the KMDF Object Model

KMDF provides a nice object model, with managed lifetimes and one of the most delightful observations I had in my first KMDF driver was that it was easy for me to blend this with my usual coding patterns.

As an aside, I’ll note that I never use sample code to learn anything. I take the reference materials and code to them. If there are samples, I treat them as the last resort- and I will deliberately change as much as I can of them [in part to see what knowledge of things that can go wrong wasn’t explicitly represented in the sample]. I judge the quality of the reference material by how rarely I have to look at a sample to figure something out [yes, I don’t find much reference material i would call “good”].

So my first KMDF driver was a software bus driver, and I didn’t go near toaster in writing it. In fact it was one of those “ActiveX” (OLE automation) test drivers I mentioned in our DDC presentation. Now we had some samples for them, too- and not surprisingly, virtually no reference material. The samples were fastidious about one thing- all the COM parts were in C++ (not a lot of choice there)- but all the parts using KMDF were in C- precisely because of said paper. I might add that this was even though no attempt was made to mark any of the code or data pagable in those samples. Well, I’m a stubborn <expletive of your choice here>, so I decided then and there I was going to write the whole driver in C++ in spite of the objections I received. I was still in my “trial period” so they could always fire me if they wanted to, but the job market was good enough at that time that I was pretty sure I could find something…

Back to the proper topic- one fine thing is that most of the KMDF macros are agnostic enough they can handle at least straightforward C++. That was one of the happiest discoveries of that time.

So the basic pattern as I use it:

Declare a static function in your class that takes a WDFOBJECT as input and returns a pointer to an object of your class.
Declare a class-specific placement form new operator that takes as its additional input the type of handle you expect your object to live in the context of (that is, it can be more precise than the preceding function can and you can benefit from stronger typing in C++)
Declare a class-specific delete operator that basically does nothing if you need to have your destructor invoked.
If you have such a delete operator, also declare a static member with a void return that takes a WDFOBJECT as input.
Use the WDF_DECLARE_CONTEXT_TYPE_WITH_NAME macro to get the compiler to write that first function for you.
Have your new operator implementation use the first function to return the address of the underlying context (you basically ignore or validate the size parameter) from the passed-in handle.
When creating the context, and you need your destructor called, use a WDF_OBJECT_ATTRIBUTES structure with the EvtCleanupCallback set to the routine in item 4.
Code that routine to use the routine in item 1 to get the context address out of the object handle- and delete that pointer. This causes your destructor to be called at cleanup time (which is much more sensible than destroy time) and your do-nothing delete operator will also be invoked (or inlined out of existence if your compiler is any good).

There- you “create” your object when the KMDF object is created (or via a WdfObjectAllocateContext call if you add your object later), and “delete” it when the object dies. But KMDF manages the memory and most of the object lifetime for you. Sure works for me (a lot).

The following snippet is from that first driver (I’ve since dropped the usage of “C” on class definitions in my general drive toward anarchic style). This is slightly convoluted because I have logic allowing only one instance of a device with this driver- so I’ve deliberately intermingled driver-level and device-level usages (always pushing those boundaries- but I think that’s a good way for an SDET to think). I’ll admit this is slightly doctored (I removed some things related to the COM technology as that I can’t disclose, plus I tried to include support for the standard bus interface and that just complicates things without illustrating this method), but it should show I practiced what I am preaching…

class CTargetTestBus
{
    static WDFDEVICE                Owner;              //  WDF device that "owns" this bus object

    static void*    operator new(size_t size, WDFDEVICE OwningDevice);
    CTargetTestBus(WDFDEVICE OwningDevice);
    ~CTargetTestBus() {}

    //  Private callbacks (ie, accessed from within this class' code)
    static EVT_WDF_IO_QUEUE_IO_DEFAULT      OnIoDispatchDefault;

    static void operator delete(void*) {}
public:

    NTSTATUS    NewChild(LPCWSTR Name, int InstanceID);
    NTSTATUS    RemoveChild(LPCWSTR Name, int InstanceID);
    void        DoneWithBus();

    static CTargetTestBus*  GetThisTargetTestBus(__in WDFOBJECT Object);    //  WDF macro writes this code
    static CTargetTestBus&  GetTheBus(bool& BusPresent);
    
    //  Driver callbacks (public, because used in DriverEntry)
    static EVT_WDF_DRIVER_DEVICE_ADD        OnDriverDeviceAdd;
    static void             OnDriverUnload(IN WDFDRIVER Driver);

    //  This one is accessed from a member in CChildInfo
    static EVT_WDF_CHILD_LIST_CREATE_DEVICE OnAddNewChild;
};


// Macros to get the context
WDF_DECLARE_CONTEXT_TYPE_WITH_NAME(CTargetTestBus, CTargetTestBus::GetThisTargetTestBus);

Now playing: Me (that old recording of Johnny B Goode again)!

Automated Jobs and Library Jobs

BobKjelgaard — Thu, 12 Mar 2009 14:30:00 GMT

I received an IM late yesterday evening (my time) from “James” (via the Web) asking what the difference is between an automated job and a library job. Unfortunately, I wasn’t around to answer it (I started work about 2 AM PDT today, and the IM was from about 9:30 PM PDT yesterday), but it’s rare I get asked something I can flip an answer to off the top of my head, so…

I’m assuming this is in the context of the Device Test Manager (DTM) in the Windows Logo Kit (WLK). That is a derivative of a larger internal-use product we call WTT (Windows Test Technologies), so I’ll assume the same answer applies to both, because I’m sure it does (and if I’m wrong, feel free to correct me).

If you’re a programmer, the fastest rough analogy is that an Automated Job is like a C / C++ “main” while the Library job is like a “function” in the runtime library (or some DLL, etc). The important difference here being that a job can “call” a library job and pass it parameters, while you cannot “call” an automated job- you can schedule it (and give it parameters) just like you can invoke a program (and give it parameters) from a command shell- but we don’t have analogs like piping and redirection of I/O etc in this execution environment.

They are a lot alike- both can be scheduled and given run-time parameters, and possess fairly similar capabilities.

So why not make all Automated jobs Library Jobs? One strong reason is that Automated Jobs can be constrained [have a set of circumstances spelled out to detail the requirements for running the job- one common one in device testing is the presence of a particular kind of hardware, for instance] while library jobs cannot. Another one I use occasionally perhaps ventures into the realm of the political- making a job an automated job so that it doesn’t wind up being called as a library job if you expect such a usage to have untoward consequences.

The best practice, especially initially, is to make most jobs library jobs- this gives you the most flexibility as you combine them later. You can work on them in pieces and then combine the pieces fairly easily.

Well, James- if you’re still searching for that answer, perhaps this will help. If not, maybe it will help someone else later.

Motivation

BobKjelgaard — Tue, 10 Feb 2009 10:14:07 GMT

What makes a person do what they do? One thing we try to be at Microsoft (and another good attribute to have) is self-critical- to be able to objectively [to the best of our innate abilities,as it is hard to avoid some subjectivity in this domain] analyze our actions, our strengths, our weaknesses- in many aspects of our work.

Two other key parts of the Microsoft culture that bear upon this article, and which is in some sense motivated by a nexus of all of these: the intrinsic value of open and honest communication, and a sense of respect to others with whom we deal that tries to assume the best interpretation when multiple alternatives present themselves.

The final element in today's mix is some of my own motivators- to blog, to work on WDF, and to work for Microsoft. I'll start with the final one.

Microsoft is an amazing place to work. The Core Operating Systems Division- the heart and soul of a platform literally used on a global basis. I was a part of it years ago [and it was a thrill to be there then, when it was the Systems Division, and Steve Ballmer was just the president of the division], and to be back there again- at a place close to the kernel, which is a place I'd always hoped to be but doubted I'd ever achieve. Those bottom-most layers, where hardware meets software- the foundation that holds up the entire software building. I should pinch myself to make sure it's really true.

But its much much more than just the raw technology. I am surrounded by people of great skill and intellect, united in one form or another with a common purpose- the broad purpose of "improving human lives through the application of technology" is one way it could be stated at the company level. But where I sit, it's focused a bit more on the hardware, the people who make that hardware and see having it work on Windows as a means for them to achieve their personal goals [financial, professional, and so on]. We want drivers to work on Windows. We want to make them easier to use. We want that whole end-user experience to be better, safer, and more trustworthy. We want the people who make that hardware and build those drivers find their jobs getting easier and the process more efficient and effective for all. We think about it and talk about it in some form practically every day. Historically, I think a lot of progress has been made, and we aren't resting upon that- we're pressing forward. We strive to improve and achieve some form of excellence.

Better yet to me, though, is that these are people I can trust- those values of honesty and integrity and ethical behavior aren't shams. I see that as well in interactions throughout my day. And I see that respect for diverse and differing viewpoints- it isn't always easy, and in none of this am I trying to say everything is perfect. But it's a good place to work and good people to be working with, and we're in a reasonable sense making our living trying to do good things. In a way, it is living a dream [sometimes the technology turns it into a nightmare, but that's the nature of human frailty- we push our limits, sometimes we have to fall back].

So I'm passionate about my job and about Microsoft. I blog because of this. When I was trying to solve that installation problem in my initial set of articles, I tried to live up the corporate standards in my treatment of both sets of customers [the engineer at the company using our technology and the end users who were experiencing this issue]- the fact that they closely align with my own beliefs certainly helps- but that alignment is what helps drive me. It leads me to take hours out of my day at times investigating other issues, or doing other tasks.

In the first article I wrote over the weekend, this is some background to further explain myself: I spent at least a couple of hours reading megabytes of logs to determine what had happened on an end user machine for another support engineer at a hardware company. It was an experience I'd mentioned before- the problem wasn't just affecting his driver, it had affected others. Somewhere out there what was probably a perfectly good piece of hardware got discarded as useless- it's manufacturer derided as producing garbage. This person's company was in danger of the same thing. The first conclusion was unfair, and the second would have been. That offends a basic sense of justice and fairness I find myself afflicted with...

So I got upset, and I vented. In response, I got this reply. It is capable of ambiguous interpretation, whether deliberately or just through a lack of finesse in English [some of the constructions hint at someone for whom it is a second language- although I am capable of that and worse at times, particularly when tired]. So at first, I opted for the less confrontational interpretation, and simply replied with what was on my mind already, anyway. I'm never at my best when angry, and I try not to let it happen [and to let it pass when it does]. I still need to take some of those more curative steps, but I will get them done.

But at the moment, my inner priorities have me blogging again- in part because of that second interpretation. My deepest and sincerest apologies up front if I have misjudged and was closer to the truth with my first estimation, by all means. But the ambiguity exists, the fire is in my heart, and I shall answer:

Registration on MSDN provides access to useful features- my registration, for instance, let' me update my blog from anywhere. If we intended it as a deterrent, it would be a lot harder than it was. Sites where I've seen this particular bad advice [just delete KMDF] weren't hard to find [and I really don't remember seeing many registration barriers]- but the threads were old, and in my own view, there were better uses of my time than trying to challenge each utterance individually. Of course, all that happened BEFORE I saw those logs and some of the real effects of that advice. Perhaps I should have tried that. But I can't unwind the clock, and the genie is out of the bottle.

As for the quality of my own posts- I know I'm not perfect. People that actually take the time to know me know that about me. But I do know what happens when you remove the KMDF service or delete the binaries, or even stop making it boot start [all of this specifically referring to Vista and above]. I've done all those things in testing it- repeatedly. On multiple machines. My parents have a Vista machine, and I wouldn't do it to them. And I would be every bit as angry at someone who gave them the same advice I was ranting about.

Marketing? I have seen my blog featured for brief periods on the WinHEC and WHDC sites [and in both cases, I found it a bit disconcerting- I'm sure I shall always pale in comparison to Doron, or to Mark Russinovich, and I can easily rattle off many more names- I take it as a rotation of sorts meant to give me some success as a blogger, but how well that chance works out is up to me]. I suppose it's a form of marketing, so point taken. But I can't see yet what's wrong with it- I'm no star, and I doubt I ever shall be.

Sycophants? Doubt I've met any- one can agree with something, even enthusiastically, and not be a sycophant. Contrarian- same thing only flipped around. Both agreement and disagreement have value in a conversation meant to go somewhere and achieve a goal- I see that in my job every day, as well. With all due respect, that seems to be an unfair and dismissive characterization (whether directed toward me or not). Real people do these things- they innately deserve more than being dismissed as stereotypes.

Hiding all Microsoft content from the Internet? Or just MSDN? Or just my own blog? If it's the latter, there are times I'd be inclined to agree- I often denigrate my own work- I can be one of my harshest critics. But perhaps the thought that since its in those indices (that's the proper plural for index, by the way), anybody can see for themselves what a blowhard I am can be a form of consolation. If my incompetence rises to the level of termination, perhaps those indices will save a future potential employer from a grave error. On the other hand, if it was one of those earlier two- that's just totalitarian. If you don't care about the walled garden, don't look. Why be bothered that others do? If the underlying claim is that the content is harmful, I'll just not agree- I used that content at times when I wasn't an employee and didn't particularly like the company or think it was a good thing it held its market position. It may not have been perfect, but it wasn't deliberately harmful [and yes, claims like that are indeed something that upset me- I just don't see a point in wasting time dealing with them- not unless there's something concrete and not just endless assertion, which is all I was presented with here].

But to go back to thinking the best, I can take this again as a criticism of the ineffective nature of my choices in how to blog. It's too hard to separate the good stuff from the rest of my verbage. That is something that I am aware of, and occasionally try to correct. But it's hard for me to not be me, especially when blogging- the act of composition drives itself in these directions.

As my final afterthought I'll go back a bit further- my responses on NTDEV a couple of weeks back were fueled by what seemed to me to be an endless stream of negative criticism, shallow, caricatured stereotypes and unfair, unwarranted assumptions about who and what I and my colleagues are. Calvin Guan was in some ways an innocent- his comment was just the verbal straw that broke the Bob camel's back. I've worked with him briefly and he's not a bad sort at all. But my tone may not have been respectful enough... I did want to counter those opinions though, I felt they delivered a skewed picture [and hence that subsequent post].

So, I'll leave this missive in those indices, and let things fall out as they may. Tomorrow I'll go to work and try in my own way to make the world a better place. I'm lucky to have a place where I can do that, and luckier still to have some people about who really accept that as being part of my motivation [yes, I also like having a place to sleep that's warm, and food, and so forth, too- those are additional motivators]... Beyond that, I'm not sure how concerned I should need to be.