Microsoft WDM Cancel Logic Document

I had to update a WDM driver recently and in doing so decided to review all the code.
(Yes it should be ported to WDF, but that’s a task for another day…)

In reviewing the code, I found that the cancellation logic and cancel routine were improperly implemented.

The following document from Microsoft was very useful to me.
The section “Cancel Logic with a Driver-Supplied Lock” was most helpful.
It helped me better understand the possible race conditions that can happen and the proper way to deal with them.
download.microsoft.com/download/5/7/7/577a5684-8a83-43ae-9272-ff260a9c20e2/cancel_logic.doc

I expect most people are probably using WDF and may not have to deal with this, but I thought I would share it with the community just in case.

Erik_Dabrowsky wrote:

In reviewing the code, I found that the cancellation logic and cancel routine were improperly implemented.

I’m not sure there are ANY WDM drivers to which that sentence does not
apply.

15 year old paper, at least. It’s so old I can’t even remember who wrote it.

The primary thing it’s missing is what cancel means… and when you need to cancel it. But in terms of telling yuppi how to write your code, it seems fine.

Peter

In reviewing the code, I found that the cancellation logic and cancel routine were improperly implemented.

I’m not sure there are ANY WDM drivers to which that sentence does not apply.

Well, this is most definitely an overstatement and a gross exaggeration, and I am pretty sure you know it yourself. Just think of numerous in-box drivers that had been written in WDM quite a while ago.

You know, when one starts blowing things, no matter how reasonable they may be, out of proportion,they generally tend to turn into something nonsensical and absurd…

Anton Bassov

Actually, the statement was not necessarily an exaggeration. When Microsoft started presenting their efforts on KMDF at first it was to a limited group under NDA. During those sessions Redmond indicated they went through every driver they had looking at the code, and found none that dealt with PnP/Power or cancelation correctly.

Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com

During those sessions Redmond indicated they went through every driver they had looking at the code, and found none
that dealt with PnP/Power or cancelation correctly.

Well, I guess it depends on what the word “correctly” may mean in the particular context…

If you introduce some new requirements there is, indeed, always a good chance that none of your existing drivers yet conforms to them. Otherwise, the above statement is very obviously ridiculous. Just think about the whole thing carefully, and you are hopefully) going to realise it within a split-second - we are speaking about the system with overall installation base expressed in terms of at least 9-10-digit numbers at the moment, and, once in a sudden, it turns out that, out of few dozens of its in-box drivers,
NOT A SINGLE ONE works correctly by the design…

Anton Bassov

Basically, yes. All of the many, many various race conditions and timing around cancel were not understood for years after NT

found none that dealt with PnP/Power or cancelation correctly

PnP/Power was always much harder than cancel… but for a very long time problems in canel was one of the top two causes of driver crashes.

All praise WDF, for making these problems largely a thing of the past (though, cancel in WDF could definitely be easier than it is now).

Peter