in reply to Invalid Access to Memory location using DynaLoader

hello MattN
..it will not run on my work computer or anyone others in the office (all Windows 7 using Strawberry Perl). The program does run in safe mode,..
You know you are walking in quicksands.. Your tests seems to me very good and even if i have not a solution i have few suggestions:

Have you yet eliminated the 32bit / 64bit madness? Ive wrote some words about filesytem redirection; see this search ?node_id=3989;BIT=filesystem%20redirection;a=Discipulus

It is possible that you are victim of a Security policy? see how they describe it You need to test also to run the code under a 'NoPolicy' account to be sure about this.

The list of services that runs in safe mode tell you somthing evident? or probable? (why it runs in safe mode? this intrigue me enough..)

most of important of all: you can have some path problem? are 2 differetent Perl installed? There is some cgwin MinGW around? see http://millenia.cars.aps.anl.gov/pipermail/ifeffit/2012-June/010580.html
http://millenia.cars.aps.anl.gov/pipermail/ifeffit/2015-October/012793.html
http://millenia.cars.aps.anl.gov/pipermail/ifeffit/2013-October/011443.html
http://millenia.cars.aps.anl.gov/pipermail/ifeffit/2012-August/010693.html

you have my simpathy.. tell us

L*

UPDATE!! http://cars9.uchicago.edu/ifeffit/Demeter/MingwFix is what you need??

L*
There are no rules, there are no thumbs..
Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.

Replies are listed 'Best First'.
Re^2: Invalid Access to Memory location using DynaLoader - path?
by MattN (Novice) on Dec 09, 2015 at 21:30 UTC

    Thank you for the reply. I think everything is 64 bit. I changed the system32 path to Sysnative and the results remained the same.

    A security issue seems likely to me. There's all sorts of security and tracking software installed, but the IT guy says that's not the issue. I looked at the event log and AppLocker doesn't have any events associated with it. He said that the tracking software is all shut off on a clean boot. He also removed it from the workgroup to check the group policy. Here's a list of configurations he tried:

    Both 32-bit and 64-bit versions Both patches from the Demeter website Normal mode Last known good configuration Selective startup Disabled all non-critical local services Terminated all non-critical system and user processes Uninstalled Java Uninstalled .NET framework Reinstalled Java Reinstalled .NET framework Adjusted memory settings for best performance Verified use has full control of all of their profile data (including +appdata) and installation directory Attempted as a normal user and administrative user Windows 95 compatibility mode Windows 98 compatibility mode Windows NT 4.0 compatibility mode Windows 2000 compatibility mode Windows XP (SP2) compatibility mode Windows XP (SP3) compatibility mode Windows Server 2003 (SP1) compatibility mode Windows Server 2008 (SP1) compatibility mode Windows Vista compatibility mode Windows Vista (SP1) compatibility mode Windows Vista (SP2) compatibility mode Windows 7 Disabled visual themes Disabled desktop composition Disable display scaling on high DPI settings Install to default location Install to a specific location C:\demeter (not default) Workstation was removed from domain and joined to workgroup Various reboots throughout

    It only runs is safe mode and safe mode with networking. He also tried disabling the antivirus, but that didn't help either. I don't know what the difference is between the safemode and clean boot. that is causing the problem.

    As I understand it, the MinGW issue was resolved a while ago with the release of version 9.14 or so.

    Does any of this set off any new alarms? Unfortunately, I don't have much control of the computer, so I can't view the security settings or any of that.

    Thanks

      Hello MattN,
      your question is a cross-post: http://comments.gmane.org/gmane.science.physics.ifeffit/3475. while is permitted is also considered polite to inform about the other post. Infact many of the information you give here are yet present in the other page. You got also the author's support. is an important bit of information. Just for correctness.

      Anyway dont fool yourself with the event viewer inspection: is very rare in my expereince to find something useful in them, and they costs hours of psychoanalisys..

      Better if you concentrate on some trace tool: ProcessExplorer can tell you all about the DLL Hell; it has CRTL-D CTRL-H hotkeys to switch from handle view to dll one.

      You can create with process explorer also dump of processes for further analisys.

      Have you tried to put the right dll in the current directory? Assuming you can be sure what the current directory is when the program try to load the dll... current directory is searched normally as first thing.

      i think i've terminated th possible suggestions.

      L*
      There are no rules, there are no thumbs..
      Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.

        Sorry about the cross posting. I asked the ifeffit mailing list a while ago about this problem and it didn't occur to me to link to the online archive.

        I was having trouble getting Process Explorer to work yesterday and I just figured out what I was doing wrong and it turns out that I need administrative privileges to run it, which I don't have, so I will ask the IT department about running it.

        I have tried moving the .dll file around to different directories. If it can't find the file it gives the error:

        Can't locate loadable object for module Ifeffit in @INC (@INC contains: C:/demeter/perl/site/lib/MSWin32-x64-multi-thread C:/demeter/perl/site/lib C:/demeter/perl/vendor/lib C:/demeter/perl/lib .) at (eval 18) line 1.

        And if it is in a directory listed in @INC, it gives the same invalid access to memory location error.

        Thanks for the help, I appreciate it.