Bug #120581 for Win32-API: Win32::api::loadlibrary not returning value on Win 10

Fri Mar 10 18:26:29 2017 mike.shannon64 [...] gmail.com - Ticket created

Subject:	Win32::api::loadlibrary not returning value on Win 10
Date:	Fri, 10 Mar 2017 18:25:39 -0500
To:	bug-Win32-API [...] rt.cpan.org
From:	Mike Shannon <mike.shannon64 [...] gmail.com>

When trying to load a DLL on Win 10 using Win32::api::Loadlibrary the routine returns a 0 I have seen this same return on Win 7 On Vista this worked. Could someone verify this and/or offer a work around? Win32::API version 0.84 Perl version 5.14.3 Routine call $l_cedsni_handle = Win32::API->new($l_tmp, '_cedsniDump@8', 'PP', 'N'); if (not defined $l_cedsni_handle) { die "DSN Interface failed \n"; exit (0); } Inside this call you can see that the actual call to loadlibrary returns 0 TY Mike

Mon Mar 13 15:33:06 2017 BULKDD [...] cpan.org - Correspondence added

On Fri Mar 10 18:26:29 2017, mike.shannon64@gmail.com wrote: Show quoted text

> When trying to load a DLL on Win 10 using Win32::api::Loadlibrary > > the routine returns a 0 > > I have seen this same return on Win 7 > > On Vista this worked. > > Could someone verify this and/or offer a work around?

What does Win32::GetLastError() return?

Mon Mar 13 15:33:07 2017 The RT System itself - Status changed from 'new' to 'open'

Mon Mar 13 17:19:00 2017 mike.shannon64 [...] gmail.com - Correspondence added

Subject:	Re: [rt.cpan.org #120581] Win32::api::loadlibrary not returning value on Win 10
Date:	Mon, 13 Mar 2017 17:18:06 -0400
To:	bug-Win32-API [...] rt.cpan.org
From:	Mike Shannon <mike.shannon64 [...] gmail.com>

$l_tmp is the location of the DLL - it is for testing purposes in the same folder as the script calling the routing $l_cedsni_handle = Win32::API->new($l_tmp, '_cedsniDump@8', 'PP', 'N'); $l_error = Win32::GetLastError(); $l_cedsni_handle contains a value of 0 $l_error is 0 I am guessing there is an issue that the DLL was built for a Win32 system and this script is running on a Win64 system (???) On Mon, Mar 13, 2017 at 3:33 PM, Daniel Dragan via RT < bug-Win32-API@rt.cpan.org> wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=120581 > > > On Fri Mar 10 18:26:29 2017, mike.shannon64@gmail.com wrote:

> > When trying to load a DLL on Win 10 using Win32::api::Loadlibrary > > > > the routine returns a 0 > > > > I have seen this same return on Win 7 > > > > On Vista this worked. > > > > Could someone verify this and/or offer a work around?

> > > What does Win32::GetLastError() return? >

Mon Mar 27 18:01:50 2017 BULKDD [...] cpan.org - Correspondence added

On Mon Mar 13 17:19:00 2017, mike.shannon64@gmail.com wrote: Show quoted text

> $l_tmp is the location of the DLL - it is for testing purposes in the same > folder as the script calling the routing > > $l_cedsni_handle = Win32::API->new($l_tmp, '_cedsniDump@8', 'PP', 'N'); > $l_error = Win32::GetLastError(); > > $l_cedsni_handle contains a value of 0 > $l_error is 0 > > I am guessing there is an issue that the DLL was built for a Win32 system > and this script is running on a Win64 system (???)

Run the process with http://www.dependencywalker.com/ , open perl.exe in the tool, then do profile-start profiling, fill out the window with the command line args to perl, and look at the log in the bottom of the depwalker window to see what went wrong with.

Mon Mar 27 18:04:27 2017 BULKDD [...] cpan.org - Correspondence added

On Mon Mar 27 18:01:50 2017, BULKDD wrote: Show quoted text

> Run the process with http://www.dependencywalker.com/ , open perl.exe > in the tool, then do profile-start profiling, fill out the window with > the command line args to perl, and look at the log in the bottom of > the depwalker window to see what went wrong with.

Also you can use "dumpbin /headers foo.dll" if you have VC installed or "objdump -f foo.dll" if you have Mingw/Strawberry installed to check 32 bit vs 64 bit for your DLL.