CarolinaPerler has asked for the wisdom of the Perl Monks concerning the following question:

'Working on a large application on Windows that uses the Win32::Lanman module. On XP, 2003, and 2007, the code works as written. On Win2008R2, it doesn't. We haven't tested on a huge number of machines, so I'm not sure the OS version is relevant. Maybe? Maybe not? Anyway, in the main application the problem code looks like: 
-----------------
unless (Win32::Lanman::NetLocalGroupEnum('', \@arrayOfHashes))
    {
    my $error = Win32::FormatMessage Win32::Lanman::GetLastError;
    $error = Win32::Lanman::GetLastError if ($error eq "");
    throw Error::Simple($error);
    }
-----------------

[download]
We're hoping @arrayOfHashes would contain an array of groups on the machine. It doesn't and we get an error "The specified procedure could not be found." I initially thought there was something wrong with Win32::Lanman or how we were using it. So, I wrote a little test like these: 
-----------------
package getGroups;
use strict;
use Win32::Lanman;
sub getGroupsViaLanman {
  my $arrayRef = shift;
  if (Win32::Lanman::NetLocalGroupEnum('', $arrayRef)){
  print "Package Array: " . Dumper($arrayRef) . "\n";     
  return $arrayRef;
  }
  else {
    my $error = Win32::Lanman::GetLastError();
    print  "ERROR: failed to get groups via Win32::Lanman::NetLocalGro
+upsEnum  ---> " . Win32::FormatMessage Win32::Lanman::GetLastError() 
+. "\n"; 
    exit;
  }
}
1;
-----------------

[download]
and 
-----------------
#!perl 
use strict;
use getGroups;
my @results;
getGroups::getGroupsViaLanman(\@results);

use Data::Dumper;
print "GROUPS: " . Dumper(@results) . "\n"; 
-----------------

[download]
That works. So, Win32::Lanman and the general approach to using it work. Ergo, we must be doing something in our larger application that is stepping on something that Win32::Lanman is using.

I copied that last chunk of code into our main application, replacing the previous version and the problem persists. So, my call to Win32::Lanman::NetLocalGroupsEnum works in my trivial test and fails when the same code (verbatim) is used in the main application.

How do I figure out what that is without resorting to a brute force exercise of reviewing code, printing voluminous debug, and .... divide and conquer? I generally live in a Linux/UNIX world. This is happening on a 64bit Windows machine. Could the 64 vs 32 bit wrinkles in windows (e.g. view of registries and such) effect this? ...'Heading off to start dissecting Win32::Lanman...

Replies are listed 'Best First'.
Re: Strategy to track failure...
by BrowserUk (Patriarch) on Jun 13, 2013 at 14:49 UTC

    The first thing I would do is (install Devel::Trace if you don't already have it), and run the failing script like this:

    perl -d:Trace theScript.pl 2 > log

    [download]

    When it stops (due to the throw Error::Simple($error);), the last few lines in the log will tell you where it had just been. It'll give you a starting point.

    If you then do the same with the working code, you should be able to match up the logs from the entry point in NetLocalGroupEnum() and see where they diverge which should get you to the point of failure quickly.

    Then you can start adding a few prints at that point to work out why.

    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]
[select]
      Then you can start adding a few prints at that point to work out why.
      Or, if you don't mind the shotgun approach, Devel::DumpTrace will print variable values, too. It may be too verbose to be useful in some cases.
[reply]
        BrowserUK and Toolic, thanks. I've used both of those before and they should help. Apparently, was having a brain cramp earlier and bothered y'all instead of thinking them up, myself.

        Lanx,
        - identical perl version.
        - identical modules installed.
        - Don't remember the results of tests during install.... 'Been a while. But, we're not in the habit of using modules that don't test out pretty cleanly.
        - Not my choice to use Win32::Lanman. That having been said, it seems to be widely used and stable.... (except for this wrinkle).
        - Hadn't thought about contacting the author. Good idea that I'll pursue if Devel::Trace and/or Devel::DumpTrace are not fruitful.


        Thanks all.
        Gives me plenty to chew on.
[reply]
Re: Strategy to track failure...
by LanX (Saint) on Jun 13, 2013 at 14:52 UTC
    First, I never used Lanman, here some general advices:

    • Do you use the same Perl version?

    • What about dependencies, do these modules work?

    • What about the results of the test suite when installing?

    • I tried to find Win32::Lanman on CPAN w/o succes... maybe an abandoned project?

    • Any mailinglist or support address to contact?

    HTH, Good luck!

    Cheers Rolf

    ( addicted to the Perl Programming Language)

[reply]
      I tried to find Win32::Lanman on CPAN w/o succes
      It is referenced in Module::ThirdParty.
      لսႽ† ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ
[reply]

Back to Seekers of Perl Wisdom