Trouble loading WIA minidriver DLL under Windows 2000

I have a problem related to a WIA minidriver. I'm not
sure which newsgroup is the correct one for this; let me
know if there is a more appropriate group.

I've created a WIA scanner minidriver that loads and
works fine on Windows XP. I also intend for this
minidriver DLL to provide STI functionality in Windows
2000 and Windows 98. My problem is that this WIA/STI DLL
is not getting loaded under Windows 2000 for some reason.

The STI_Trace.log file contains only the following error
line:

e STISVC [stisvc.exe::0x65c] Could not open device
({6BDD1FC6-810F-11D0-BEC7-08002BE2092F}\0001) . Received
from STI: hResult=(80040154). Object not maintained


Win2K does not like my DLL for some reason. My entry
point function never gets called. However, under Windows
XP and Windows 98ME my DLL does get loaded. These are the
only three Windows versions I've tried so far.

I do have two other working minidrivers I can use as
references. One, of course, is the DDK WIA sample scanner
minidriver. The other is an existing scanner product that
currently works under Win2K, although its STI DLL was not
built by me.

I believe that my INF file is correct and the registry
entries all look good to me. Anyway, to rule out those
possibilities, I decided to install the other working
scanner product and then rename and substitute my own WIA
DLL in place of the other DLL. When I did this, my DLL
was still not loaded. But when I substituted the WIA
sample scanner DLL, that DLL is loaded ok---its entry
point gets called. It's only my DLL that will not get
loaded. So there is apparently no problem with the
registry, and the DLL can be found. It just won't get
loaded and get its entry point called for some reason.

I then compared my DLL with the WIA sample minidriver to
see what could be different. I built both using the build
utility and the Windows XP SP1 DDK, build 2600.1106. I
initially had a different entry point than the sample
scanner. I was using _DllMainCRTStartup because my DLL
uses the C runtime library---in fact, it uses STL as
well. So normally I see my DllMain() function get called
by _DllMainCRTStartup . But to make sure this wasn't the
problem, I made my entry point to be "DllEntryPoint" to
match the WIA sample code (remembering to specify
DLLENTRY=DllEntryPoint in the sources file of course).
But this did not help. I checked the exports (using
DUMPBIN) to make sure both DLLs have the same exports.
The only difference is the DliHook export in the sample
minidriver, but that should not matter.

I then compared the "sources" files. Mine is almost the
same as the sample minidriver's. There are only two
differences. Since I'm using STL, I need to set USE_STL=1
and USE_NATIVE_EH=1. Other than that they look the same.

So why does my DLL not get loaded under Win2K??

It should not be a problem with a GUID---the DLL entry
point does not even get called. So Windows doesn't even
know anything about the GUID yet. The only thing I can
imagine is that my entry point looks different in some
way, maybe of because the way it was compiled. But I
cannot see any significant difference between how my DLL
and the sample minidriver are built.

minorguy
Tue Nov 18 00:45:48 CST 2003


Since that last post, I've narrowed down the problem
(sorry if you read through all that :( ). The cause is
STL.

As it turns out, a DLL which consists of just the
following:

BOOL APIENTRY DllMain(HINSTANCE hinst, DWORD dwReason,
LPVOID lpReserved)
{
MessageBox(NULL, "In DllMain", "Title", MB_OK |
MB_SERVICE_NOTIFICATION);

return TRUE;
}

...can get loaded by the Win2K STI service and will
display the message box. However, in the following
example, DllMain will never get called:

BOOL APIENTRY DllMain(HINSTANCE hinst, DWORD dwReason,
LPVOID lpReserved)
{
MessageBox(NULL, "You'll never see me", "Title",
MB_OK | MB_SERVICE_NOTIFICATION);
ofstream outFile;

return TRUE;
}

Presumably, something in the initialization fails
somewhere and it unloads before calling DllMain.

So my questions are:

1. Why does this only happen in Windows 2K?

2. Is there anything I can do to allow STL to work in a
minidriver DLL under Windows 2K?

So far, I use _DllMainCRTStartup as the entry point and I
set USE_STL=1 in the sources file (which causes
MSVPRT.LIB to get linked in). I also set USE_NATIVE_EH=1.

Is there anything I'm missing? Or is it just a fact of
life that STL cannot be used here, in which case I'll
have to go back and rewrite some stuff without STL?

3. If STL cannot be in a DLL that is loaded by the Win2K
STI service, can it be in a DLL that is loaded by a DLL
that is loaded by the Win2K STI service?

Ivan
Tue Nov 18 01:32:16 CST 2003

do you have msvcp60.dll in the W2K box ?
and if yes, does it have all the exports required ?

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


"minorguy" <minorguy@oceancity.com> wrote in message
news:0a0a01c3ad9f$996982e0$a101280a@phx.gbl...
>
> Since that last post, I've narrowed down the problem
> (sorry if you read through all that :( ). The cause is
> STL.
>
> As it turns out, a DLL which consists of just the
> following:
>
> BOOL APIENTRY DllMain(HINSTANCE hinst, DWORD dwReason,
> LPVOID lpReserved)
> {
> MessageBox(NULL, "In DllMain", "Title", MB_OK |
> MB_SERVICE_NOTIFICATION);
>
> return TRUE;
> }
>
> ...can get loaded by the Win2K STI service and will
> display the message box. However, in the following
> example, DllMain will never get called:
>
> BOOL APIENTRY DllMain(HINSTANCE hinst, DWORD dwReason,
> LPVOID lpReserved)
> {
> MessageBox(NULL, "You'll never see me", "Title",
> MB_OK | MB_SERVICE_NOTIFICATION);
> ofstream outFile;
>
> return TRUE;
> }
>
> Presumably, something in the initialization fails
> somewhere and it unloads before calling DllMain.
>
> So my questions are:
>
> 1. Why does this only happen in Windows 2K?
>
> 2. Is there anything I can do to allow STL to work in a
> minidriver DLL under Windows 2K?
>
> So far, I use _DllMainCRTStartup as the entry point and I
> set USE_STL=1 in the sources file (which causes
> MSVPRT.LIB to get linked in). I also set USE_NATIVE_EH=1.
>
> Is there anything I'm missing? Or is it just a fact of
> life that STL cannot be used here, in which case I'll
> have to go back and rewrite some stuff without STL?
>
> 3. If STL cannot be in a DLL that is loaded by the Win2K
> STI service, can it be in a DLL that is loaded by a DLL
> that is loaded by the Win2K STI service?
>
>

anonymous
Tue Nov 18 12:45:25 CST 2003


>-----Original Message-----
>do you have msvcp60.dll in the W2K box ?
>and if yes, does it have all the exports required ?
>

Msvcp60.dll was not on the W2K box. So I got a copy of it
from a WinXP system and put it on the Win2K system under
the system32 directory. But it did not solve the problem.
The DLL with STL still does not load. (msvcrt.dll is on
the Win2K system, by the way)

As to whether it has all the exports required, how could
I know? I presume it does though, since the same WIA
minidriver works fine in the WinXP system I copied the
file from.

I do wonder, if msvcp60.dll is required for STL to work
properly, why it isn't just linked in statically. Or why
it's not documented anywhere (at least not that I could
find) that msvcp60.dll may need to be redistributed.

minorguy
Tue Nov 18 15:24:16 CST 2003


Sorry, the rest of the problem was my fault. Part of the
problem was the missing msvcp60.dll. But I had also built
a combination WIA/STI minidriver that depended on the
wiaservc.dll which obviously is not part of Win2K. When I
copied wiaservc.dll to the Win2K system, the minidriver
DLL finally loads OK. So I'll need to make separate DLLs
for the STI-only and the WIA systems.

Thanks for the help.

And I realize now that msvcp60.dll has to be a DLL
because STL has some static stuff in it, like cerr.

(And that last message was mine but with the wrong return
address)

>-----Original Message-----
>
>Msvcp60.dll was not on the W2K box. So I got a copy of
it
>from a WinXP system and put it on the Win2K system under
>the system32 directory. But it did not solve the
problem.
>The DLL with STL still does not load. (msvcrt.dll is on
>the Win2K system, by the way)
>
>As to whether it has all the exports required, how could
>I know? I presume it does though, since the same WIA
>minidriver works fine in the WinXP system I copied the
>file from.
>
>I do wonder, if msvcp60.dll is required for STL to work
>properly, why it isn't just linked in statically. Or why
>it's not documented anywhere (at least not that I could
>find) that msvcp60.dll may need to be redistributed.
>
>

Kirk
Wed Nov 19 03:07:46 CST 2003

"minorguy" <minorguy@oceancity.com> wrote in message
news:020b01c3ae1a$51cfc720$a301280a@phx.gbl...
>
> Sorry, the rest of the problem was my fault. Part of the
> problem was the missing msvcp60.dll. But I had also built
> a combination WIA/STI minidriver that depended on the
> wiaservc.dll which obviously is not part of Win2K. When I
> copied wiaservc.dll to the Win2K system, the minidriver
> DLL finally loads OK. So I'll need to make separate DLLs
> for the STI-only and the WIA systems.

Next time use depends.exe that comes with VS and SDK to find all missing
DLLs.

-Kirk

Maxim
Wed Nov 19 11:32:18 CST 2003

Also a good idea is to avoid using STL in any system-level components.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com


"Kirk Ferdmann" <kirk_ferdmann@nospam.hotmail.com> wrote in message
news:t42dnWYL2_l_ryaiRVn-uA@comcast.com...
> "minorguy" <minorguy@oceancity.com> wrote in message
> news:020b01c3ae1a$51cfc720$a301280a@phx.gbl...
> >
> > Sorry, the rest of the problem was my fault. Part of the
> > problem was the missing msvcp60.dll. But I had also built
> > a combination WIA/STI minidriver that depended on the
> > wiaservc.dll which obviously is not part of Win2K. When I
> > copied wiaservc.dll to the Win2K system, the minidriver
> > DLL finally loads OK. So I'll need to make separate DLLs
> > for the STI-only and the WIA systems.
>
> Next time use depends.exe that comes with VS and SDK to find all missing
> DLLs.
>
> -Kirk
>
>

minorguy
Wed Nov 19 12:38:32 CST 2003


>-----Original Message-----
> Also a good idea is to avoid using STL in any system-
level components.
>

Why?

WIA minidrivers run in user-mode.

minorguy
Wed Nov 19 12:42:27 CST 2003


>Next time use depends.exe that comes with VS and SDK to
find all missing
>DLLs.
>
>-Kirk


Yes, I know about depends.exe. For some reason it didn't
occur to me that it might be a missing DLL. Seems simple
now though.

Maxim
Thu Nov 20 00:04:26 CST 2003

To get rid of the problems you're having (with extra DLLs).

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com


"minorguy" <minorguy@oceancity.com> wrote in message
news:0a8b01c3aecc$5557ba80$a001280a@phx.gbl...
>
> >-----Original Message-----
> > Also a good idea is to avoid using STL in any system-
> level components.
> >
>
> Why?
>
> WIA minidrivers run in user-mode.
>
>