This project is read-only.

Failure to register v4.9.3.4 MapWinGis.OCX on W7 32 bit

Feb 6, 2015 at 6:33 PM
Using the v4.9.3.4-win32 on Windows 7 32 bit, MapWinGis.OCX is (silently) failing to register, either during the install, or when triggered manually (both done with admin permissions).

I have tried:
  • Running Depends on it and the list of DLLs it gives is identical to those on another machine which is registering the DLL as expected.
  • Cutting back the directories in the Path, in case something there was causing problems
  • Checking the compatibility files for anything that might have an odd effect.
Any other suggestions would be gratefully received.

cheers,
Ben
Feb 7, 2015 at 1:59 PM
Does dependency walker says it is missing some files? If so which one?
Your MapWinGIS folder should not be in your PATH, we did that in previous versions of the installer but it is no longer needed.
When you run regsvr32 without /s do you get an error?

Paul
Feb 7, 2015 at 9:10 PM
Only delay loads missing, which I've seen from other posts aren't required (ieshim.dll and missing entry points in ieframe.dll).
No, regsvr32 was doing nothing at all regardless of /s.

I've actually made this register now; in the end I cut the path back to just c:\windows and c:\windows\system32 and it worked. Adding the rest of the path incrementally, I isolated three different directories in the path which caused a problem. On initial inspection, the common factor seems to be that all three contain versions of libeay32.dll which is also part of MapWinGIS. I'm surprised by this though; I wouldn't have expected this to cause the problem since the search path would normally be based on the local directory first, and only look at the rest of the path thereafter. I haven't tried removing that file from the other path directories to see if there are any other conflicts.

cheers,
Ben
Feb 10, 2015 at 11:05 AM
Edited Feb 10, 2015 at 11:12 AM
Hi Ben,

thanks for your research. We would definitely like to fix this problem if it's the problem in MapWinGIS settings or installer. Any suggestion how can I reproduce it? I've already tried to swap the version of libeay32.dll in MapWInGIS folder with a few different versions installed by other apps but so far no luck in breaking registration - it still works. Dll loading order seems to be ok as well: dlls located in MapWinGIS folder have precedence.

I also created an issue to track it as there is one more report of a similar problem: https://mapwingis.codeplex.com/workitem/25977

Thanks,
Sergei
Feb 10, 2015 at 1:55 PM
Hi Sergei,

On my machine I can reproduce as follows:
  • Create a new empty directory and include it in the path
  • try and register Mapwingis.ocx - works
  • add to the new directory either one of the following files:
    • libeay32.dll, dated 06/06/2008, no version info, 856KB, installed as part of commercial s/w
    • libexpat.dll, dated 08/10/2008, no version info, 140KB, installed as part of Graphviz - probably v2.24.
  • try and register Mapwingis.ocx - silent failure
cheers,
Ben
Feb 10, 2015 at 4:52 PM
Edited Feb 10, 2015 at 4:53 PM
Ben, thanks for the info. I found libexpat.dll in Graphviz and it indeed incompatible with MapWinGIS. However I wasn't able to reproduce abnormal loading order by editing PATH.
  • I created c:\temp folder;
  • placed it first in PATH;
  • put wrong version of libexpat.dll in it;
  • MapWinGIS still registers fine with regsvr32 and Dependency Walker reports that gdal20.dll is linked against libexpat.dll in c:\dev\mapwingis folder (as it should be);
If swap libexpat.dlls, registration doesn't work - as expected.
If I place correct version in c:\temp and none in c:\dev\mapwingis, it's loaded correctly from PATH.

So it seems everything works as it should be on my PC.
Feb 10, 2015 at 6:35 PM
Hi Sergei,

Curious...

I had put the new directory last in the path, but I've just retried with it in first place and that doesn't make any difference. Dependency Walker also finds the libexpat.dll in the right place (not from the path) but then it is not loading it in the same way as windows so doesn't guarantee the same results.

I've run Process Monitor and looked at what is happening during the regsvr32.exe call. Here it is clear that xerces-c_2_8.dll is being loaded from elsewhere in my path (no problem caused by that because it happens to be the same version) and then libexpat.dll is loaded from my path, not from the local directory.

Is safedllseachmode enabled on your machine? I'm not sure what other parameters control the search path, but some of them are run-time options so would need to check the way that LoadLibrary is being called in GDAL2?

cheers,
Ben
Feb 11, 2015 at 7:46 PM
Edited Feb 11, 2015 at 7:47 PM
Hi Ben, curious indeed. No, safedllseachmode is disabled on my machine. I leave the issue for now as so far there is no evidence that something is wrong on our side.
Feb 12, 2015 at 9:10 AM
Hi Sergei,

Safedllsearchmode is the default since Windows XP, I believe, so may be worth seeing if the issue is reproducable on your machine if you enable this (it is enabled on mine).

But, yes, I agree it seems to be an oddity with GDAL2 rather than with MapWindow, so may be best to wait until that has settled down a bit.

thanks,
Ben
Feb 12, 2015 at 9:50 PM
Edited Feb 12, 2015 at 9:52 PM
Ben, sorry, I was inattentive when reading MSDN. I don't have SafeDllSearchMode value in the registry, so it was enabled (by default). I checked it with the value added - there is no change in behavior.