Program doesn't work on 64-bit Windows Vista

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Try to run port mapper executable from "Port Map 1.0.zip" on 64-bit 
Windows

What is the expected output? What do you see instead?

What version of the product are you using? On what operating system?
Latest version from svn, revision 20

Please provide any additional information below.

I tried to compile the program myself in x86 mode, but every time I try to 
run the program I am getting this error:

Unable to load DLL 'natpmp.dll': Invalid access to memory location. 
(Exception from HRESULT: 0x800703E6)

Original issue reported on code.google.com by Roman.Sh...@gmail.com on 22 Dec 2008 at 1:19

[GoogleCodeExporter]

I verified the problem on 64-bit Windows, and it crashed just like you said.

In visual studio, I changed the solution platform to x86 (as opposed to the 
project platform).  This fixed the 
problem for me.  I then removed the "Any CPU" platform to prevent the same 
problem from popping up again.  
The changes were checked in as revision 21.

Please verify the problem was fixed.

Original comment by deu...@gmail.com on 30 Dec 2008 at 7:27

• Changed state: Started
• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

deusty, thank you very much for the fix.
I tested the revision 22, everything is OK now.

Roman

Original comment by Roman.Sh...@gmail.com on 3 Jan 2009 at 7:41

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

deusty, I did some more testing, revision 22 is still crashing on 64-bit 
Windows 
Vista (I am using Visual Studio 2008)

System.DllNotFoundException: Unable to load DLL 'natpmp.dll': Invalid access to 
memory location. (Exception from HRESULT: 0x800703E6)

   at TCMPortMapper.NATPMP.initnatpmp(natpmp_t& p)
   at TCMPortMapper.NATPMPPortMapper.RefreshExternalIPThread() in D:\Temp
\NewUpnp01\TCMPortMapper\TCMNATPMPPortMapper.cs:line 399
   at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, 
ContextCallback callback, Object state)
   at System.Threading.ThreadHelper.ThreadStart()

private void RefreshExternalIPThread()
        {
            Monitor.Enter(multiThreadLock);
            OnDidBeginWorking();

            NATPMP.natpmp_t natpmp = new NATPMP.natpmp_t();
            NATPMP.natpmpresp_t response = new NATPMP.natpmpresp_t();
            int r;
            Win32.TimeValue timeout = new Win32.TimeValue();
            Win32.FileDescriptorSet fds = new Win32.FileDescriptorSet(1);
            bool didFail = false;

Exception here -->      r = NATPMP.initnatpmp(ref natpmp);    <--Exception here
            if (r < 0)
            {
                didFail = true;
            }
...

Original comment by Roman.Sh...@gmail.com on 3 Jan 2009 at 8:22

[GoogleCodeExporter]

I occasionally get these crashes too, but I don't think it has to do with 
64-bit because I experience the 
problem in both 32 and 64 bit windows.  I think it's a windows and/or visual 
studio problem.  Here's how I 
usually solve it:

Without making any code changes, shut down visual studio, and then reopen the 
project, and rebuild the 
solution.  This solves the problem about 25% of the time for me.  If this 
doesn't work, reboot windows.  This 
solves the problem the other 75% of the time.

Is this a windows dll hell problem?

Original comment by robbieha...@gtempaccount.com on 3 Jan 2009 at 8:42

[GoogleCodeExporter]

I did as you suggested: restarted VS, rebuilt the project, it didn't help, 
rebooted 
pc, rebuilt the project again, but still getting the same error.
I have searched for natpmp.dll in all drives, the only place it was found is 
dotnetportmapper's source folder, so it is not a dll hell problem.

Original comment by Roman.Sh...@gmail.com on 3 Jan 2009 at 12:19

[GoogleCodeExporter]

Right, and the natpmp.dll and upnp.dll files should get copied into the build 
folder right next to the executable.  
Is this not happening on your machine?

Original comment by robbieha...@gtempaccount.com on 3 Jan 2009 at 10:01

[GoogleCodeExporter]

Here are the contents of my build folder:

 Volume in drive D is Data
 Volume Serial Number is ****-***

 Directory of D:\Temp\NewUpnp01\PortMap\bin\x86\Debug

04.01.2009  13:37    <DIR>          .
04.01.2009  13:37    <DIR>          ..
03.01.2009  16:38            40 197 miniupnp.dll
03.01.2009  16:38            25 076 natpmp.dll
03.01.2009  16:38           339 576 oui.txt
03.01.2009  21:13            36 864 PortMap.exe
03.01.2009  21:13            58 880 PortMap.pdb
03.01.2009  21:13            14 848 PortMap.vshost.exe
21.07.2007  01:33               490 PortMap.vshost.exe.manifest
03.01.2009  21:13            48 640 TCMPortMapper.dll
03.01.2009  21:13            97 792 TCMPortMapper.pdb
              10 File(s)        662 363 bytes

As you can see, everything gets copied in it. (You meant miniupnp.dll , not 
upnp.dll , right?)

Original comment by Roman.Sh...@gmail.com on 4 Jan 2009 at 4:43

[GoogleCodeExporter]

miniupnp.dll is correct.

I was under the impression that the application would look in the same 
directory as the application:
http://msdn.microsoft.com/en-us/library/ms682586.aspx

But perhaps we should be calling SetDllDirectory, or setting 
Environment.CurrentDirectory?

Original comment by robbieha...@gtempaccount.com on 4 Jan 2009 at 7:36

[GoogleCodeExporter]

It looks very similar to this case 
http://lists-archives.org/mingw-users/11142-net-
interface-with-dll-0x800703e6.html

Original comment by Roman.Sh...@gmail.com on 4 Jan 2009 at 7:45

[GoogleCodeExporter]

Very interesting.  Both dll's were created using dllwrap.  I'll see if I can 
create them without it...

Original comment by robbieha...@gtempaccount.com on 4 Jan 2009 at 7:53

[GoogleCodeExporter]

Ok, I just recompiled the dll's using "gcc -shared" instead of "dllwrap".  
According to users on the mingw lists, 
this should help solve the problem.

These changes were just committed.  Let me know if this fixes it.

Original comment by robbieha...@gtempaccount.com on 4 Jan 2009 at 8:35

[GoogleCodeExporter]

I downloaded the latest source, everything seems to be ok now, I can confirm 
that 
the problem is resolved, thank you!

Original comment by Roman.Sh...@gmail.com on 4 Jan 2009 at 2:03

[GoogleCodeExporter]

Awesome!

Original comment by deu...@gmail.com on 4 Jan 2009 at 10:44

• Changed state: Verified

[GoogleCodeExporter]

Is it possible for anyone to build the latest source and put it up to be 
available for 
download?

Original comment by ilta...@gmail.com on 2 Oct 2009 at 5:59

[GoogleCodeExporter]

Is it possible for anyone to build the latest source and put it up to be 
available for 
download?

Original comment by ilta...@gmail.com on 2 Oct 2009 at 5:59

[GoogleCodeExporter]

Please? Build a stable version, and release it so that it will work with 64bit 
computers!

Original comment by x86...@gmail.com on 15 Jan 2012 at 10:00