Implementing DLL in UMDF

NTDEV
21

On a 64 bit OS, there are only 64 bit UMDF processes.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Joseph M. Newcomer
Sent: Tuesday, August 02, 2011 2:43 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Implementing DLL in UMDF

While it is true that a 64-bit process can only load 64-bit DLLs, do we know whether the OP is using a 32-bit process or a 64-bit process? All I’ve seen is that the DLL is a 32-bit DLL, but nothing about the context in which it is used.
joe

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Tuesday, August 02, 2011 3:25 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Implementing DLL in UMDF

xxxxx@gmail.com wrote:

Hi friends

I’m having the same problem.

What problem?

I tried to include de lib in SOUCES but it doesnt work.

It doesn’t BUILD or it doesn’t LOAD?

I generated my DLL using Visual C++ 2010, 32bits. But, I’m using Win7
64bits.

A 64-bit process can only load 64-bit DLLs.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

22

Of course, you DID determine what the error was:

if(hinstLib == NULL)
{
DWORD error = GetLastError();
. suitable means of displaying the error number (TRACE, printf,
MessageBox, DebugPrint, etc.)
. don’t forget FormatMessage!
. deal with failure
}

Surprisingly, I do not see any code in the example that determines either
failure or reports the reason for the failure.

And, as previously mentioned, no discussion as to whether the code shown is
running in the context of a 32-bit or 64-bit process.

Why do you think Windows is on the C: drive? In a multiboot environment, it
might be on D:, E:, or some other drive. So hardwiring the string as shown
is erroneous programming. It only works in a restricted set of assumptions
which may not be valid in the real world.

Of course, I would not EXPECT that GetProcAddress would work correctly,
because you failed to RTFM. Did you read the documentation about
LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE? Did you see that it works like
LOAD_LIBRARY_AS_DATAFILE, which very explicitly says

“Therefore, you cannot call functions like GetModuleHandle or GetProcAddress
with this DLL”

So the issue is not that GetProcAddress does not work; you explicitly SAID
you didn’t want it to work when you used the flag
LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE. So why should its failure to work come
as a surprise? In fact, why do you want to use this flag?

joe

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Silvio Silva
Sent: Tuesday, August 02, 2011 3:33 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Implementing DLL in UMDF

Hi Tim

It doesnt load.

See code below:

typedef double (*importFunction)();
.
.
.

HINSTANCE hinstLib =
LoadLibraryEx(TEXT(“C:\Windows\System32\GerarDLL.dll”),NULL,LOAD_LIBRARY_
AS_DATAFILE_EXCLUSIVE);
.
.
.

importFunction addNumbers;
addNumbers = (importFunction)GetProcAddress(hinstLib, MyFunction");

//////////////////////////////////

With I try to use LoadLibrary(), hinstlib is NULL. If I try to use
LoadLibraryEx, hinstlib has a value, though addNumber is null.

Which means, I believe that I can load the dll, but cant load the methods.

Regards,

Silvio S Silva

On Tue, Aug 2, 2011 at 3:24 PM, Tim Roberts wrote:
xxxxx@gmail.com wrote:
> Hi friends
>
> I’m having the same problem.
What problem?

> I tried to include de lib in SOUCES but it doesnt work.
It doesn’t BUILD or it doesn’t LOAD?

> I generated my DLL using Visual C++ 2010, 32bits. But, I’m using Win7
64bits.
A 64-bit process can only load 64-bit DLLs.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the
List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

23

Note that the “magic mapping” will work correctly. I missed the fact that a
32-bit DLL might have been copied to the %SYSTEMROOT%\System32 directory,
good catch. But if a 32-bit app tries to load something from
%SYSTEMROOT%\System32, it will be magically redirected to
%SYSTEMROOT%\SysWow64 (isn’t it intuitively obvious that the 32-bit DLLs go
in the directory that has “64” in its name and the 64-bit DLLs go in the
directory that has “32” in its name? I often have fun with this anomaly in
my Advanced Windows System Programming class)
joe

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Tuesday, August 02, 2011 3:53 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Implementing DLL in UMDF

Silvio Silva wrote:

It doesnt load.

See code below:

typedef double (*importFunction)();
…
HINSTANCE hinstLib =

LoadLibraryEx(TEXT(“C:\Windows\System32\GerarDLL.dll”),NULL,LOAD_LIBRARY_
AS_DATAFILE_EXCLUSIVE);

…
importFunction addNumbers;
addNumbers = (importFunction)GetProcAddress(hinstLib, MyFunction");
//////////////////////////////////

With I try to use LoadLibrary(), hinstlib is NULL. If I try to use
LoadLibraryEx, hinstlib has a value, though addNumber is null.

Which means, I believe that I can load the dll, but cant load the methods.

Well, not really. It means you can read the DLL as a file.
LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE just copies the bits into memory. It
doesn’t actually “load” the DLL, and you cannot call GetProcAddress on a
DLL loaded that way.

The reason you can’t load it is exactly what I said. A 64-bit process
cannot load a 32-bit DLL. You will have to build a 64-bit version of
your DLL.

By the way, never copy 32-bit DLLs into the System32 directory on a
64-bit system. 32-bit DLLs go in \Windows\SysWOW64. 64-bit DLLs go in
\Windows\System32.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

24

LoadLibrary and LoadLibraryEx will both work, providing you use the
correctly. As I already pointed out, your usage was completely erroneous.
Reading the documentation is often a useful exercise in avoiding this sort
of problem.
joe

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Silvio Silva
Sent: Tuesday, August 02, 2011 3:58 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Implementing DLL in UMDF

Tom,

I will generate the 64-bit version of my DLL. But, what function I need to
use: LoadLibrary or LoadLibraryEx? Can you show me a example?

Thanks

On Tue, Aug 2, 2011 at 3:53 PM, Tim Roberts wrote:
Silvio Silva wrote:
>
> It doesnt load.
>
> See code below:
>
> typedef double (*importFunction)();
> …
> HINSTANCE hinstLib =
>
LoadLibraryEx(TEXT(“C:\Windows\System32\GerarDLL.dll”),NULL,LOAD_LIBRARY_
AS_DATAFILE_EXCLUSIVE);
> …
> importFunction addNumbers;
> addNumbers = (importFunction)GetProcAddress(hinstLib, MyFunction");
> //////////////////////////////////
>
> With I try to use LoadLibrary(), hinstlib is NULL. If I try to use
> LoadLibraryEx, hinstlib has a value, though addNumber is null.
>
> Which means, I believe that I can load the dll, but cant load the methods.
Well, not really. It means you can read the DLL as a file.
LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE just copies the bits into memory. It
doesn’t actually “load” the DLL, and you cannot call GetProcAddress on a
DLL loaded that way.

The reason you can’t load it is exactly what I said. A 64-bit process
cannot load a 32-bit DLL. You will have to build a 64-bit version of
your DLL.

By the way, never copy 32-bit DLLs into the System32 directory on a
64-bit system. 32-bit DLLs go in \Windows\SysWOW64. 64-bit DLLs go in
\Windows\System32.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the
List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

25

> LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE just copies the bits into memory. It

doesn’t actually “load” the DLL, and you cannot call GetProcAddress on a

But you can call FindResource(Ex), and this is the purpose of this flag.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com