frustrating kernel mode dll problem + question...

Hi all.
I want to use a kernel-mode dll to be able to share some common code
across several drivers. The dll works great, etc. but there’s one problem
blocking my customer from accepting the kernel-mode dll solution…

The problem is that the loader will bugcheck (0xc000026c) if the
kernel-mode dll binary is not present or is corrupted…

Is there a way to tell the loader “hey, if this fails, don’t die, just
fail to load the driver and move on”?

I searched the archives here, and there was one post with the same
question back in July of 2001, but there were no responses… I’ve tried
mucking with the ErrorControl value in the registry for the associated
drivers, but with no luck…

These are software-only drivers, so they can fail to load and the system
will still be OK… the software that uses the drivers simply won’t
work…

And I would really prefer using a kernel-mode dll rather than statically
compiling the code into all the drivers… it would just make maintenance
alot easier…

Thanks for the help,
sean

have you tried changing the ErrorControl value of your drivers?

-----Original Message-----
From: xxxxx@stg.com [mailto:xxxxx@stg.com]
Sent: Wednesday, August 21, 2002 9:33 AM
To: NT Developers Interest List
Subject: [ntdev] frustrating kernel mode dll problem + question…

Hi all.
I want to use a kernel-mode dll to be able to share some common code
across several drivers. The dll works great, etc. but there’s one
problem blocking my customer from accepting the kernel-mode dll
solution…

The problem is that the loader will bugcheck (0xc000026c) if the
kernel-mode dll binary is not present or is corrupted…

Is there a way to tell the loader “hey, if this fails, don’t die, just
fail to load the driver and move on”?

I searched the archives here, and there was one post with the same
question back in July of 2001, but there were no responses… I’ve tried
mucking with the ErrorControl value in the registry for the associated
drivers, but with no luck…

These are software-only drivers, so they can fail to load and the system
will still be OK… the software that uses the drivers simply won’t
work…

And I would really prefer using a kernel-mode dll rather than statically
compiling the code into all the drivers… it would just make
maintenance alot easier…

Thanks for the help,
sean


You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to %%email.unsub%%

Yep… I modified the value from 1 (SERVICE_ERROR_NORMAL) to 0
(SERVICE_ERROR_IGNORE) and had the same results… I didn’t use the sc.exe
tool to do this, though… i simply toggled the value in
HKLM\CCS\System\Services<mydriver>\ErrorControl

Thanks,
sean

wrote in message news:xxxxx@ntdev…
>
>
> The problem is that the loader will bugcheck (0xc000026c) if the
> kernel-mode dll binary is not present or is corrupted…
>

These drivers start automatically, during system startup? This is on which
operating system… XP?

If you start one of the drivers manually, after system startup, does this
result in a dialog box popping up saying:

xxxxxxxx device driver could not be loaded.
Error Status was 0xC000026C

Assuming so, the bsod is the result of a “hard-error” being raised in a
system thread. The Error Control value doesn’t kick in because your driver
can’t even get loaded; The way I understand it, ErrorControl only takes
affect if your driver is loaded, but DriverEntry returns something other
than _SUCCESS.

You don’t say… do your “software drivers” support PnP or are they legacy
flavored? Again, you don’t specify, but it sounds like you’re “force
loading” the DLL. If your drivers are legacy-type drivers, you might try
fooling with the dependency groups for startup, making your drivers “depend
on” the loading of the DLL (in other words, don’t force load the DLL). If
the DLL isn’t present, it won’t start (duh!), the dependency will not be
established, and your other drivers won’t load.

Peter
OSR

>

These drivers start automatically, during system startup? This is on which
operating system… XP?

I’m currently doing the testing on a 2k box and haven’t tried it on my XP
test box… I’m sharing some error-reporting code between a mirror
driver’s miniport driver and 2 other drivers… and when the mirror
miniport tries to load at startup the bugcheck occurs if the kernel-mode
dll binary is corrupt or missing…

Assuming so, the bsod is the result of a “hard-error” being raised in a
system thread. The Error Control value doesn’t kick in because your driver
can’t even get loaded; The way I understand it, ErrorControl only takes
affect if your driver is loaded, but DriverEntry returns something other
than _SUCCESS.

Ah. Thanks for the info… The ErrorControl values were set to let the
system continue and it was still bugchecking… so this makes sense…

You don’t say… do your “software drivers” support PnP or are they legacy
flavored? Again, you don’t specify, but it sounds like you’re “force
loading” the DLL. If your drivers are legacy-type drivers, you might try
fooling with the dependency groups for startup, making your drivers “depend
on” the loading of the DLL (in other words, don’t force load the DLL). If
the DLL isn’t present, it won’t start (duh!), the dependency will not be
established, and your other drivers won’t load.

This is definitely something I’ll try out… they are both installed as
legacy drivers (the system has to run on NT4, 2K and XP) and this may be a
solution that will work…

Thanks for the help and suggestions!

sean

I did not readed all the thread, but if I understood right, what you should
do in this case is to load, if possible, your DLL dynamically, and not
through import reference. Its easy to do yet there are several aspects to be
observed, such as the fact that NT 4 does not maintai reference counting for
kernel modules. 2k and XP do - best to my knowledge - , but pay attention to
loading and respective unloading DLL methods, a incorect implementation of
those will make your DLL remain laoded in memory even if all references are
gone. When I did this, I exported, save for load -unload methods , a single
API which returned an array of function pointers, my API. I did that to save
myself for 1001 calls to my homemade GetProcessAddress() kernel mode
equivalent.

Im afraid , you cant tell the system to ignore a missing module at import
referencing time,
so you are stuck with dynamic loading.

Ciao, Dan

----- Original Message -----
From:
To: “NT Developers Interest List”
Sent: Wednesday, August 21, 2002 8:35 PM
Subject: [ntdev] Re: frustrating kernel mode dll problem + question…

> >
> > These drivers start automatically, during system startup? This is on
which
> > operating system… XP?
>
> I’m currently doing the testing on a 2k box and haven’t tried it on my XP
> test box… I’m sharing some error-reporting code between a mirror
> driver’s miniport driver and 2 other drivers… and when the mirror
> miniport tries to load at startup the bugcheck occurs if the kernel-mode
> dll binary is corrupt or missing…
>
> > Assuming so, the bsod is the result of a “hard-error” being raised in a
> > system thread. The Error Control value doesn’t kick in because your
driver
> > can’t even get loaded; The way I understand it, ErrorControl only takes
> > affect if your driver is loaded, but DriverEntry returns something other
> > than _SUCCESS.
>
> Ah. Thanks for the info… The ErrorControl values were set to let the
> system continue and it was still bugchecking… so this makes sense…
>
> > You don’t say… do your “software drivers” support PnP or are they
legacy
> > flavored? Again, you don’t specify, but it sounds like you’re “force
> > loading” the DLL. If your drivers are legacy-type drivers, you might
try
> > fooling with the dependency groups for startup, making your drivers
“depend
> > on” the loading of the DLL (in other words, don’t force load the DLL).
If
> > the DLL isn’t present, it won’t start (duh!), the dependency will not be
> > established, and your other drivers won’t load.
>
> This is definitely something I’ll try out… they are both installed as
> legacy drivers (the system has to run on NT4, 2K and XP) and this may be a
> solution that will work…
>
> Thanks for the help and suggestions!
>
> sean
>
> —
> You are currently subscribed to ntdev as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to %%email.unsub%%
>

> I did not readed all the thread, but if I understood right, what you should

do in this case is to load, if possible, your DLL dynamically, and not
through import reference.

Actually you’re right about what I want to do, and this is the way I had
originally intended to do the work. However the guy I’m writing the code
for doesn’t want to use undocumented calls to load the kernel-mode dll…
And the only way I know of to do it is either with ZwSetSystemInformation
or ZwLoadDriver… (or EngLoadImage for a display driver)
I was recently bitten by a change made to ZwSetSystemInformation in XP SP1
(Beta) and .Net Server RC1… they increased a size of a struct by 4 bytes
and presto… my code was broken because I sent the wrong size for the
call I was doing :\

So I guess I’ll have to settle for a compromise… I think I’m stuck
compiling the code into two of the drivers, and then depending on the
platform (2K/XP use the display miniport which loads first, NT4 doesn’t)
I’ll have to get the function pointers from one of those two drivers…

Thanks again everyone for all the help…

sean

I think I have a pretty good idea on what’s happening. This should not
happen on a system that’s XP or greater. The reason you are seeing the
bugcheck is that your driver is failing to load so early on that we don’t
have the harderror infrastructure in user mode yet. So when the kernel
raises a harderror it bugchecks. In XP and later systems, we just queue an
error log event instead of raising a harderror and let the system continue.
The error control stuff applies to this error as well. Its just not for
DriverEntry failurres


Nar Ganapathy
Windows Core OS group
This posting is provided “AS IS” with no warranties, and confers no rights.

“Peter Viscarola” wrote in message news:xxxxx@ntdev…
>
>
> wrote in message news:xxxxx@ntdev…
> >
> >
> > The problem is that the loader will bugcheck (0xc000026c) if the
> > kernel-mode dll binary is not present or is corrupted…
> >
>
> These drivers start automatically, during system startup? This is on
which
> operating system… XP?
>
> If you start one of the drivers manually, after system startup, does this
> result in a dialog box popping up saying:
>
> xxxxxxxx device driver could not be loaded.
> Error Status was 0xC000026C
>
> Assuming so, the bsod is the result of a “hard-error” being raised in a
> system thread. The Error Control value doesn’t kick in because your
driver
> can’t even get loaded; The way I understand it, ErrorControl only takes
> affect if your driver is loaded, but DriverEntry returns something other
> than _SUCCESS.
>
> You don’t say… do your “software drivers” support PnP or are they legacy
> flavored? Again, you don’t specify, but it sounds like you’re “force
> loading” the DLL. If your drivers are legacy-type drivers, you might try
> fooling with the dependency groups for startup, making your drivers
“depend
> on” the loading of the DLL (in other words, don’t force load the DLL). If
> the DLL isn’t present, it won’t start (duh!), the dependency will not be
> established, and your other drivers won’t load.
>
> Peter
> OSR
>
>
>
>
>