Porting KMD from XP under Driverworks to WDM Win7/8/10

[Jeff_Long]

Hi all,

My first post here. We have an existing Kernel Mode Driver that works great under XP. It was written with NuMega’s Driverworks years ago under 2000 originally to simplify driver writing. We now want to make this driver work under Windows 7/8/10 (at minimum Win7 for Standard Embedded). It uses IOCTL calls only and does not share memory with Usermode outside of this. Most of it works under one ISR from a hardware generated interrupt at DIRQL.

I have two questions:

1. Generally speaking, how hard is it to convert a DriverWorks project to straight MS kernel calls, if someone happens to know? I’m assuming it’s required to move to Win7 and up.

2. Our driver (out of necessity) is attached to one specific hardware card, but the driver ALSO enumerates the buss and finds all the other cards in the system, and those other cards we talk to directly in hardware. Device Mangler shows the one card with our driver, but the other cards show a bang ! with no driver. The code all works fine…under 2000 and XP. However, I am told that enumerating the buss in this way is (or was!) being deprecated, and I’m concerned that we won’t be able to have access to all the cards in the system like we currently have. It’s ok if the method changes, we just need to have access to all the cards like we do now.

Despite having written a good chunk of this driver (years ago) I would consider myself a novice. I have only written this one driver, so if you answer with “Well, why don’t you just write these three filter drivers that do this or that and talk together” I’m not likely to understand what you’re talking about, although I’m very happy to RTFM and get down to business if pointed in the right direction. The reason the one driver has to have access to all the cards is because I need to be able to talk to them EXACTLY at the time of the DIRQL interrupt, not later with a DPC etc. microseconds count…

Thanks SO MUCH for anyone who takes the time to read this, let alone respond.

Cheers,
Jeff

[Don_Burn]

First don’t try to do a WDM driver, use KMDF instead, it is much easier and
safer. Second all the cards will be enumerated you can create an
environment where they are shared, just be aware that they can be disabled
so your design much account for this.

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

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@graniteprecision.com
Sent: Wednesday, December 16, 2015 7:30 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Porting KMD from XP under Driverworks to WDM Win7/8/10

Hi all,

My first post here. We have an existing Kernel Mode Driver that works great
under XP. It was written with NuMega’s Driverworks years ago under 2000
originally to simplify driver writing. We now want to make this driver work
under Windows 7/8/10 (at minimum Win7 for Standard Embedded). It uses IOCTL
calls only and does not share memory with Usermode outside of this. Most of
it works under one ISR from a hardware generated interrupt at DIRQL.

I have two questions:

1. Generally speaking, how hard is it to convert a DriverWorks project to
   straight MS kernel calls, if someone happens to know? I’m assuming it’s
   required to move to Win7 and up.

2. Our driver (out of necessity) is attached to one specific hardware card,
   but the driver ALSO enumerates the buss and finds all the other cards in the
   system, and those other cards we talk to directly in hardware. Device
   Mangler shows the one card with our driver, but the other cards show a bang
   ! with no driver. The code all works fine…under 2000 and XP. However, I
   am told that enumerating the buss in this way is (or was!) being deprecated,
   and I’m concerned that we won’t be able to have access to all the cards in
   the system like we currently have. It’s ok if the method changes, we just
   need to have access to all the cards like we do now.

Despite having written a good chunk of this driver (years ago) I would
consider myself a novice. I have only written this one driver, so if you
answer with “Well, why don’t you just write these three filter drivers that
do this or that and talk together” I’m not likely to understand what you’re
talking about, although I’m very happy to RTFM and get down to business if
pointed in the right direction. The reason the one driver has to have
access to all the cards is because I need to be able to talk to them EXACTLY
at the time of the DIRQL interrupt, not later with a DPC etc. microseconds
count…

Thanks SO MUCH for anyone who takes the time to read this, let alone
respond.

Cheers,
Jeff

---

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:>

[Mark_Roddy]

On Wed, Dec 16, 2015 at 7:29 PM, wrote:

> 2) Our driver (out of necessity) is attached to one specific hardware
> card, but the driver ALSO enumerates the buss and finds all the other cards
> in the system, and those other cards we talk to directly in hardware.
> Device Mangler shows the one card with our driver, but the other cards show
> a bang ! with no driver. The code all works fine…under 2000 and XP.
> However, I am told that enumerating the buss in this way is (or was!) being
> deprecated, and I’m concerned that we won’t be able to have access to all
> the cards in the system like we currently have. It’s ok if the method
> changes, we just need to have access to all the cards like we do now.

Yeah so that is not going to fly.Instead you need to have one device object
for each hardware device, all of which can be controlled by one KMDF
driver. You can present a single user visible symbolic link for your gang
of devices. A bit more work on your part, but the ugly bangs go away.

Mark Roddy

[Jeff_Long]

Hi Don and Mark,

You both say it’s best to write a KMDF. Ok. It also seems you are both saying that within the one KMDF driver, I can have multiple device objects, and I can access all of those objects from within it.

I assume this means I should be able to access all the objects at DIRQL within one ISR. It should, if I understand correctly, because a device object is just an object (class/struct), rather than being in a separate driver or other abstracted layer of code.

Correct?

No-one is answering about DriverWorks, but I guess the idea is it will need to be entirely re-written as a KMDF driver, so it’s irrelevant how/with what it was written before. Got it.

Thanks!
Jeff

[Don_Burn]

I was going to avoid speaking of DriverWorks, but since you really asked. I
have had two clients who bought the source and asked for a full review to
“improve it to current standards”, in both cases I found over 2000 major
(i.e. you are going to crash) errors, and so many other problems it was not
even worth considering.

On the KMDF driver, yes you can access all the device objects, you will need
to do some effort to keep locking correct, and you are going to need to be
aware that with N device objects you need to be careful ensure that they all
are present (i.e. something is not stopped or disabled).

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

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@graniteprecision.com
Sent: Thursday, December 17, 2015 11:41 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Porting KMD from XP under Driverworks to WDM Win7/8/10

Hi Don and Mark,

You both say it’s best to write a KMDF. Ok. It also seems you are both
saying that within the one KMDF driver, I can have multiple device objects,
and I can access all of those objects from within it.

I assume this means I should be able to access all the objects at DIRQL
within one ISR. It should, if I understand correctly, because a device
object is just an object (class/struct), rather than being in a separate
driver or other abstracted layer of code.

Correct?

No-one is answering about DriverWorks, but I guess the idea is it will need
to be entirely re-written as a KMDF driver, so it’s irrelevant how/with what
it was written before. Got it.

Thanks!
Jeff

---

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:>

[Maxim_S_Shatskih]

> No-one is answering about DriverWorks, but I guess the idea is it will need to be entirely re-written

as a KMDF driver

Yes, the framework part yes.

The real part which deals with your HW - not necessary.

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

[anton_bassov]

I was going to avoid speaking of DriverWorks, but since you really asked. I have had two clients who bought the source and asked for a full review to “improve it to current standards”, in both cases I found over 2000 major (i.e. you are going to crash) errors, and so many other problems it was not even worth considering.

OK, let’s accept the above statement at its face value for the time being.

Now let me try myself as a “bestseller writer”, and to write a short parody of any of Agatha Christie’s stories. The plot of the story stands as following. There is a thread where an OP says the following in his original post:

Then our client gets us to hire a driver expert consultant, who proceeds to tell them that DriverWorks is very very bugy, poorly supported, and not fit to write a driver for a toaster!

Someone on that thread replies to it the following way

Ilya, I don’t think it is buggy, in fact there is an outstanding developer by the name of Bill McKenzie. And if you are trying to write some classes of drivers, for ME/98 as well as NT/Win2k/XP this is definitely the way to go.

The question that Hercule Poirot has to find an answer to is “Who may have made the above reply?”

After having done some investigations that are of zero relevance to us, Hercule Poirot had finally concluded that the answer to his question could be found in NTDEV archives. Certainly, as it usually happens in Agatha Christie’s stories, this answer happens to lie somewhere that one would least expect it to be.

http://www.osronline.com/showThread.cfm?link=55241

Please check the post N6 on that thread. No, I am not making it up, guys…

Anton Bassov

[Don_Burn]

Anton,

Over 1000 of the bugs were identified by PreFast and Lint. This
included over 500 places where a NULL pointer was never set to another value
and then dereferenced. It also included 200+ places where totally invalid
parameters were passed to kernel API’s. I know Bill and I doubt it was
like that when he was there, in fact in a lot of cases the code had comments
from people who were there after Bill.

I can’t comment on specific DriverWorks versions, but the later
versions were garbage.

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

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Thursday, December 17, 2015 1:35 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Porting KMD from XP under Driverworks to WDM Win7/8/10

I was going to avoid speaking of DriverWorks, but since you really asked. I
have had two clients who bought the source and asked for a full review to
“improve it to current standards”, in both cases I found over 2000 major
(i.e. you are going to crash) errors, and so many other problems it was not
even worth considering.

OK, let’s accept the above statement at its face value for the time being.

Now let me try myself as a “bestseller writer”, and to write a short parody
of any of Agatha Christie’s stories. The plot of the story stands as
following. There is a thread where an OP says the following in his original
post:

Then our client gets us to hire a driver expert consultant, who proceeds to
tell them that DriverWorks is very very bugy, poorly supported, and not fit
to write a driver for a toaster!

Someone on that thread replies to it the following way

Ilya, I don’t think it is buggy, in fact there is an outstanding developer
by the name of Bill McKenzie. And if you are trying to write some classes of
drivers, for ME/98 as well as NT/Win2k/XP this is definitely the way to go.

The question that Hercule Poirot has to find an answer to is “Who may have
made the above reply?”

After having done some investigations that are of zero relevance to us,
Hercule Poirot had finally concluded that the answer to his question could
be found in NTDEV archives. Certainly, as it usually happens in Agatha
Christie’s stories, this answer happens to lie somewhere that one would
least expect it to be.

http://www.osronline.com/showThread.cfm?link=55241

Please check the post N6 on that thread. No, I am not making it up,
guys…

Anton Bassov

---

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:>

[anton_bassov]

Over 1000 of the bugs were identified by PreFast and Lint. This included over 500 places where a NULL pointer was never set to another value and then dereferenced. It also included 200+ places where totally invalid parameters were passed to kernel API’s. I know Bill and I doubt it was like that when he was there, in fact in a lot of cases the code had comments from people who were there after Bill. I can’t comment on specific DriverWorks versions, but the later versions were garbage.

How pathetic, Don - to be honest, I was expecting something more plausible and/or less absurd from you…

Anton Bassov

[Don_Burn]

Anton,

Quit trolling.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Thursday, December 17, 2015 1:58 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Porting KMD from XP under Driverworks to WDM Win7/8/10

Over 1000 of the bugs were identified by PreFast and Lint. This included
over 500 places where a NULL pointer was never set to another value and then
dereferenced. It also included 200+ places where totally invalid parameters
were passed to kernel API’s. I know Bill and I doubt it was like that when
he was there, in fact in a lot of cases the code had comments from people
who were there after Bill. I can’t comment on specific DriverWorks versions,
but the later versions were garbage.

How pathetic, Don - to be honest, I was expecting something more plausible
and/or less absurd from you…

Anton Bassov

---

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:>

[anton_bassov]

> Quit trolling.

Well, I am not trolling - I am just asking you to start telling us some lies that are less obvious and absured compared to the ones in your latest post…

Anton Bassov

[Peter_Viscarola_OSR]

Stop it, both of you.

I’m “pretty familiar” with driver works having headed a team that did a detailed review of it at the source code level “back in the day.” 15 years ago, it was a reasonably good product that proved that the framework concept could work for kernel mode driver development. The pre-PnP version was far better than the version where they (often poorly) grafted on PnP support. But that’s really no fault of the Driver Works people. In 2000, NOBODY understood how to do PnP right.

In any case, Driver Work certainly does not stand up under scrutiny when examined for what we consider Best Practices in 2015.

I don’t think any one of us would like to be judged by the standards of the code they work 15 years ago. In any case, I know for sure that I wouldn’t.

Peter
OSR
@OSRDrivers

[anton_bassov]

>Stop it, both of you.

I know that it was kind of pointless from the very beginning, but I just could not resist a “temptation”.

Sorry, Peter …

Anton Bassov

[anton_bassov]

Peter,

I don’t think any one of us would like to be judged by the standards of the code they work
15 years ago.

Well, certainly some new bugs are almost inevitable in a code that has been maintaned for
15 years - who would even argue about it. Be sure if we were speaking about,say, all in all 20 bugs here I would not say a word. However, we are speaking about 2000+(!!!) critical bugs that result in immediate BSOD whenever any one of them gets encountered , with all of them having been introduced in the last 12 years to previously perfect and immaculate code.

I don’t know about you, but encountering something as obvious and grotesque as that
switches me into the “trolling mode” straight away - after all, it seems to be an insult to the intelligence of the entire NTDEV…

Anton Bassov

[Maxim_S_Shatskih]

>the Driver Works people. In 2000, NOBODY understood how to do PnP right.

…including the DDK samples of the day who were sometimes violating some “best practices” stuff which was later (not in 2000) documented as requirement in MSDN.

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

[Peter_Viscarola_OSR]

Correct.

Further, witness the Oney book. Not exactly what I would call good advice on PnP/Power management,

Peter
OSR
@OSRDrivers

[anton_bassov]

> Further, witness the Oney book. Not exactly what I would call good advice

on PnP/Power management,

Something tells me this thread still has a potential for turning “exciting” - although my attempt to provoke “ALL_CAPS_ON frenzy” has failed in so far, I think the abovementioned author’s reaction to the above statement may, probably, save the day. Let’s see if you are more lucky than me…

Anton Bassov

[Peter_Viscarola_OSR]

I think the abovementioned author’s reaction to the above
statement may, probably, save the day.

No chance of that, old sport.

Mr. Oney is happily retired and living the good life, away from the drudgeries of Windows driver development.

The fact that Mr. Oney’s book does not contain “the latest and greatest” guidance on power management wasn’t meant to be inflammatory, or even that interesting. It’s a long-recognized fact… meant, in this context, to reinforce our discussion of “best practices change over time, and what we did back in 2000 isn’t necessarily anything we’re proud of today.”

Peter
OSR
@OSRDrivers

[Jeff_Long]

Hi all,

I thought I should comment at this point since I’m the original poster.

C??? ??? ?nton. ? ??? ??? ?? ??? ??? ?? ???. ??? ??? ???. ? ??? ???.

I understand that we should make a KMDF driver. I understand that it makes sense to do that from scratch, copying our specific, non-framework, code in where we can from the original project, but not attempting to port the DriverWorks code directly. After 15 years, that makes sense. I am still on the fence as to whether or not I’ve heard here if it’s definitive that, *for sure* we can have the driver attach to one card in the system, and still have all the other cards as driver objects in the same driver, and access all the objects at DIRQL. None of the other cards needs it’s own ISR or servicing, they will all be accessed only from this driver, and the other access outside the one ISR is for one card that gets a DMA interrupt to keep filling a buffer (an audio card), but other than that, polling the cards or writing to them when the main card’s ISR happens is just fine and what we do now.

On the issue of DriverWorks, when I read that there were 2000 bugs in it, I was skeptical, and suspected that it might be a ploy for work, however, I harbored no ill-will against such an effort. At some point I may indeed ask for help with the project… but I was interested to read the prior thread on the same subject… Moving past that now, I can say that I need to avoid distractions from understanding what’s the *actual* best thing for our project and remain professional. We are a small company, and have too little money to spend it unwisely or un-frugally.

We purchased DW with full source, and had to override two DW functions to get our code to work, but ultimately it felt easy to use and I know it works well because we have machines running the code for FIVE years PLUS WITHOUT having been turned off or otherwise touched. Most of our product’s code lives in the ISR of our KM driver, with some user code primarily for tcp/ip comms, and it just works and works and works. I do not know if we followed best practices ™, but I do know we mapped global variables and chunks of memory and almost nothing is malloc’d and freed to prevent garbage collection issues. We defined everything statically on the heap or on the stack in some cases, and that’s it, and I think that helps it run for years without having the unit being turned off. This seems to work on with XP, but not sure about newer OSs.

So I am happy having used DriverWorks. If the company existed today I’d be looking to continue with them… but they don’t and times have changed and we need to move on.

Thank you EVERYONE for your input and time spent on our behalf!

[Jeff_Long]

I should have guessed the forum would have trouble with Cyrillic.