loadlibrary netapi32 32bit versus 64bit
Erick Engelke
I have a 32 bit application which works perfectly until I try to run it on
a Windows 2008R2 64 bit server.
The line:
DLLHandle = LoadLibrary("netapi32.dll");
always returns 0.
Static linking netapi32 also fails, but loadlibrary with kernel32 works.
I don't understand while the loadlibrary fails, there is a
c:\Windows\SysWOW64\netapi32.dll
and looking at its exports, it has the right functions even.
I can't change the code to 64 bit due to other libraries it has to use.
Any suggestionts?
Erick
Erick Engelke er...@uwaterloo.ca
Director PHY-3013
Engineering Computing (519) 885-1211 x35893
University of Waterloo http://www.eng.uwaterloo.ca/~erick
Erick Engelke
On Mon, 1 Nov 2010, Erick Engelke wrote:
>
> I have a 32 bit application which works perfectly until I try to run it on a
> Windows 2008R2 64 bit server.
>
> The line:
> DLLHandle = LoadLibrary("netapi32.dll");
> always returns 0.
>
> Static linking netapi32 also fails, but loadlibrary with kernel32 works.
>
> I don't understand while the loadlibrary fails, there is a
> c:\Windows\SysWOW64\netapi32.dll
> and looking at its exports, it has the right functions even.
>
> I can't change the code to 64 bit due to other libraries it has to use. Any
> suggestionts?
Also, the language is Delphi, which only produces 32 bit binaries.
Erick
Kerem Gümrükcü
check this out:
http://www.dnjonline.com/article.aspx?id=jun07_access3264
regards
K.
"Erick Engelke" schrieb im Newsbeitrag
news:2010110113...@engmail.uwaterloo.ca...
Stefan Kuhr
On 11/1/2010 5:51 PM, Erick Engelke wrote:
>
> I have a 32 bit application which works perfectly until I try to run it
> on a Windows 2008R2 64 bit server.
>
> The line:
> DLLHandle = LoadLibrary("netapi32.dll");
> always returns 0.
>
> Static linking netapi32 also fails, but loadlibrary with kernel32 works.
>
> I don't understand while the loadlibrary fails, there is a
> c:\Windows\SysWOW64\netapi32.dll
> and looking at its exports, it has the right functions even.
>
> I can't change the code to 64 bit due to other libraries it has to use.
> Any suggestionts?
>
What you try to do is entirely legal and works normally. What is the
last error immediately after the failing call to LoadLibrary? You get
the threads last error by calling GetLastError().
--
S
Erick Engelke
On Tue, 2 Nov 2010, Stefan Kuhr wrote:
>> DLLHandle = LoadLibrary("netapi32.dll");
>> always returns 0.
>
>
> What you try to do is entirely legal and works normally. What is the last
> error immediately after the failing call to LoadLibrary? You get the threads
> last error by calling GetLastError().
It's 2, ERROR file not found
It returns the same error if I copy the 32 bit DLL to the same
subdirectory. I suppose it could be missing one of the DLLs in its
dependancy list, but I don't know why it would, this is a fresh install.
Erick
Timo Kunze
missing and b) check in which folder Windows searches for netapi32.dll
(using the profiling feature).
Timo
--
www.TimoSoft-Software.de - Unicode controls for VB6
"Those who sacrifice freedom for safety deserve neither."
"Demokratie ist per Definition unsicher. Ihr Schutz entsteht aus der
Überzeugung, dass die demokratischen Kräfte überwiegen und sich – auf
demokratischem Wege – durchsetzen."
Stefan Kuhr
Then a DLL on which netapi32 is dependent is missing. Did you mess
around with the PATH environment variable, either for your computer or
for your process?
And as Timo wrote, the profiling feature of depends.exe comes in handy,
and also running Process Monitor, while your call fails.
--
S
Erick Engelke
On Wed, 3 Nov 2010, Stefan Kuhr wrote:
>> On Tue, 2 Nov 2010, Stefan Kuhr wrote:
>>>> DLLHandle = LoadLibrary("netapi32.dll");
>>>> always returns 0.
>
> Then a DLL on which netapi32 is dependent is missing. Did you mess around
> with the PATH environment variable, either for your computer or for your
> process?
>
> And as Timo wrote, the profiling feature of depends.exe comes in handy, and
> also running Process Monitor, while your call fails.
I found the reason I was running into this, I was running the application
from my network drive (where I compiled it). Copying it to the C: drive
caused windows to work as expected.
I didn't try searching MSDN as to why that happens. It's not a nice
effect, we teach our students to compile on the network drive where
everything is backed up.
Erick
Stefan Kuhr
This can hardly be the reason for this behaviour. Running an app from a
network drive doesn't change the Loader behaviour. I suspect that it is
something entirely different. Did you get any results from running your
app inside depends.exe, as Timo suggested, or did running Process
Monitor yield any results?
Do you have any "Security Solution" running that maybe prevents apps
from running from a network drive if they load DLLs that do networking?
Maybe Software Restriction Policies?
--
S
Erick Engelke
> On 11/3/2010 2:51 PM, Erick Engelke wrote:
>>>
>> I found the reason I was running into this, I was running the
>> application from my network drive (where I compiled it). Copying it to
>> the C: drive caused windows to work as expected.
>>
>> I didn't try searching MSDN as to why that happens. It's not a nice
>> effect, we teach our students to compile on the network drive where
>> everything is backed up.
>>
>
> This can hardly be the reason for this behaviour. Running an app from a
> network drive doesn't change the Loader behaviour. I suspect that it is
> something entirely different. Did you get any results from running your app
> inside depends.exe, as Timo suggested, or did running Process Monitor yield
> any results?
>
> Do you have any "Security Solution" running that maybe prevents apps from
> running from a network drive if they load DLLs that do networking? Maybe
> Software Restriction Policies?
Actually, the depends program wouldn't load from the network drive either.
When I copied both to the local drive, both depends and my program worked
perfectly.
This is not as outrageous as it sounds. Starting in Vista, exe files on
the network drive would sometimes raise warnings before executing as
though they had been downloaded with IE (they weren't). The network drive
was Samba in both cases, I haven't tried it with a Windows file server.
ERick
Stefan Kuhr
On 11/3/2010 9:05 PM, Erick Engelke wrote:
> <snip>
> Actually, the depends program wouldn't load from the network drive
> either. When I copied both to the local drive, both depends and my
> program worked perfectly.
>
> This is not as outrageous as it sounds. Starting in Vista, exe files on
> the network drive would sometimes raise warnings before executing as
> though they had been downloaded with IE (they weren't). The network
> drive was Samba in both cases, I haven't tried it with a Windows file
> server.
>
Then you most probably have some security measures in place that
restrict you (and your students) from running apps on a network drive.
This could either be SRPs or some 3rd party solution. You might want to
talk to your Administrators in order to create exceptions to their
policies so your students can build their apps on the network drive.
As a side note: I would never, ever, build a binary entirely on a
network drive, a funny coincidence is, that the only time I had to do
this, was at university. Building on a network drive is sloooooooowwww.
The argument that on the network drive everything is backed up is moot,
since you don't want to back up your object files and debugging symbols,
heck, not even your created binaries. All you want to back up is your
source files, make files and project files, and this is what a version
control system is there for. Set up a subversion or CVS server for your
students, this way they learn something useful they will always be able
to apply in their life after university and they will learn to
differentiate what is important to back up and what is unimportant.
--
S