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

Anointed ones,

I have a question concerning using win32::tieRegistry. I have a little script that just pokes into the registry and grabs the application path. It works ok, but it whines a bit at the end. See below:

#!/usr/bin/perl -w use strict; use Win32::TieRegistry ( Delimiter=>"/" ); my $regString = $Registry->{'LMachine/Software/Microsoft/Windows/Curre +ntVersion/App Paths/ProMassXcali.exe//'}; use File::Basename; my($basename, $AppPath, $suffix) = fileparse("$regString",'\..*'); print "$AppPath\n";

Here's the error message that it spits out at the end.

(in cleanup) Can't call method "FETCH" on an undefined value at C:/Perl5 61/site/lib/Win32/ line 1486 during global destruction.

Is there something wrong with the way I'm doing this? I'm running win2k with Perl 5.6.1 build 626 from ActiveState.


#!/usr/bin/perl -w $camel = $hump do { theHumpty($camel); }

Replies are listed 'Best First'.
Re: Win32::tieRegistry question
by chinman (Monk) on Jul 22, 2001 at 20:35 UTC

    This problem mysteriously went away after I updated to the latest version of Perl 5.6.1 build 628.

    I guess that means I'm the..."weakest link, bye, bye"!


    #!/usr/bin/perl -w $camel = $hump do { theHumpty($camel); }
Re: Win32::tieRegistry question
by aquacade (Scribe) on Jul 22, 2001 at 20:42 UTC

    I had this same error message using DBI. See bug reports at using link for "5.6 and later" and search on both 1486 and individually to see this error message has been a long standing "feature" in module.

    Someone on the DC Perl Mongers mailing list found a reference for me (which I cannot direct you to at the moment, but will look for it) which suggested that the warnings code logic within has a snarl and by *gasp* not using the -w during production (but using -w faithfully in development) I could suppress this *bogus I hope* error message. This informant also observed that since Perl automagically cleans up that this error, while seeming alarming, doesn't seem to effect the processing.

    Since this error occurs 12 times for me when each of 12 DBI-using Perl programs I run as a batch finish execution, I have painstaking confirmed (at least to my satifaction and in my case) that I can safely ignore this error during my production runs (and safely hide it by not using -w).

    Update (minutes after your update):   I see you found a solution WHILE I was writing this response. I'll make sure I'm in 5.6.1 at work as well and hope this fixes my error message in while using DBI! Thanks!

      Actually, it is a feature of how Perl's global destruction is not done in an orderly manner in order to save time. Whether or not you get the error depends on some rather random things.

      I don't see how not using -w would help as trying to call a method on an undefined value does not require -w in order to trigger. Perhaps you are just getting lucky.

      You don't have to upgrade Perl to solve this problem. Simply upgrade Win32::TieRegistry. If you go to and search for "TieRegistry", you'll find version 0.24. Click on the very first link and then click on the Changes file to see:

      Revision history for Perl extension Win32::TieRegistry.
      0.24  2001-02-06 19:00
              - Silenced error that could appear "at random" during "cleanup":
                      (Can't call method "FETCH" on an undefined value)
      (Well, when I did that I got an error which I'm hoping is a temporary problem with the web site.)

      In any case, I was able to download the module. Then unzip the file and install it like any CPAN module (or, if you don't have a version of "make", run the included Install.bat). The latest version may also be available in PPM form from some repository (I don't keep track much since I don't seem to have the ability to affect what gets made available).

      As for the error being harmless, you are mostly correct. The only thing related to that error that is a problem is fairly minor, especially considering that it only affects a feature that is rarely used. From the Bugs section of manual:

      Current implementations of Perl's "global destruction" phase can cause objects returned by Load() to be destroyed while keys within the hive are still open, if the objects still exist when the script starts to exit. When this happens, the automatic UnLoad() will report a failure and the hive will remain loaded in the Registry.

              - tye (but my friends call me "Tye")

        Thank you Brother Tye for an excellent exposition of the root problem! I only received this error when exiting each program. I do have a follow-on question for you:

        Do I now have to manually delete entries from my registry (using regedit) to clean it up? Your last sentence indicates "the hive will remain loaded in the Registry?" Thanks!