Perl.exe Has Stopped Working

[Karon Howey]

Isaw the same question here, and question was about TeXLive manager error perl.exe stopped working. However, many of answers was about this error during installation. I decided to create one more question.

However, I can't guarantee this works fully since the packages I was interested in had no updates. Note, however, that when I tried this from the GUI I got the same error as you did; so the above at least gives no errors!

I had the same problem while updating TeXLive 2016. It seems like after a update the perl gets buged or something, during install there might be no errors at all.Maybe some other program made the perl file corrupted, I don't know.

I'm running ActivePerl 5.24 build 2401 x64. Previously, when I was running this build and version in Windows 7, my scripts, when encountering a fatal error, would indicate the line and reason (e.g. "Line too long in file, line 11") in the command prompt from which I was running it. This was great for me to figure out what was wrong and to debug the file.

I've recently migrated to a Windows 10 system. But now, whenever encountering an error in a script, all that happens is a window pops up saying "Perl Command Line Interpreter has stopped working". There is no additional information, and it's a pain in the butt because I have no idea where the script errored and crashed.

To be clear, Perl is installed correctly on the Windows 10 system. When I corrected the script and/or data file, everything ran swimmingly. It's only when there's an error that it displays this message, and it's useless at helping me figure out what's wrong.

Any pointers? Any way I can have the error messages print in Windows 10 in the command prompt rather than popping up a useless message? Or is there another debugging setup that I can use? I tried using perl -d but the debugger is a little too much for my level right now.

It's hard to be certain, but I would guess that you're picking up an old, faulty installation of perl instead of the one you think you are. That would explain why installing Strawberry Perl shows no change

I am working on windows 7 32 bit machine.Perl 5.24 version is installed on my machine which was working fine for years. 1.All of a sudden it stopped working by throws an error message "Perl56.dll is missing". 2. Referred the sites and followed the resolution to uninstall and then install the perl version 5.24.2 3. After that I am getting an error message "Perl command line interpreter has stopped working"

I don't see a 'community' version of 5.24 being available on the ActiveState downloads page. Perhaps paying customers get access to different versions. Perhaps of interest Strawberry Perl offers 32 and 64bit builds.

I suspect that: Your perl524.exe should need perl524.dll, which means you have an extra ancient Perl 5.8 perl.exe hidden somewhere (without it's perl58.dll in that same directory). This ancient perl's PATH is BEFORE the new installation (which has appended itself to the end of the PATH)What I want you to do is drop to the CMD, and from there call perl -v. What happens? call perl524 -v. What happens?I have 5.24 StrawberryPerl on my windows.The minimal perl installation is perl.exe (an identical copy of perl524.exe) and perl524.dll (or at least, was a few years ago) and does not require modules (*.pm and others)note that Strawberry perl also needs 3 gcc related dlls, but I do not have an AS-Perl around now, so that might also be required for AS-Perl.So we drop to the CMD and run: where perl.exeThis will give you a path where perl.exe is located. If not, then your Perl is not in your PATH and you need to set it first. (then try again)Great. Now create an empty directory and go into it:md TESTcd TEST[download]Now empty the PATH variable by doing a set PATH=.You can now run "perl" and it will not find that executable.and copy the perl.exe over: copy C:\SOMEPATH\perl.exenow run perl again:perl.exeit will tell you it needs a DLL, it should be in the same directory as the perl.exe was. Copy them over (lazy, in one go) copy C:\SOMEPATH\*.dll C:now try again. Does it come up with version information or pupup/crashes? If you get version information, the binaries are not corrupt (for example: could be a virus that slowly encrypts things, although those virus leave DLL's alone and hunt for office documents and images).Once you give us more information, we will know what's the problem.[reply]

[d/l]

[select]Back toSeekers of Perl Wisdom

I think the way it works is the form Action is to reach out across the internet and run the FormMail.pl residing in the root of my domain. The error message above suggest to me there has been a fault whithin the formmail script when it tries to run sendmail

If the form has suddenly stopped working after working when initially deployed/tested and you have made no recent updates to the code then that points to the server being updated without your knowledge and the script is no longer compatible. This should not happen without your prior knowledge but chances are its a shared server and updates happen 'behind your back'. Having said that FormMail.pl is a very old dated perl script for handling form submissions, it might be time to bite the bullet and

I don't know anyone who still uses Perl programming (aka cgi-bin) for forms. If your server supports Perl, it very likely supports modern PHP code too which is what we use to collect & process form data in the 21st century. But writing secure scripts requires some coding skills. This PHP mail sending library is the one most web hosts recommend.

If the form has suddenly stopped working after working when initially deployed/tested and you have made no recent updates to the code then that points to the server being updated without your knowledge and the script is no longer compatible. This should not happen without your prior knowledge but chances are its a shared server and updates happen 'behind your back'. Having said that FormMail.pl is a very old dated perl script for handling form submissions, it might be time to bite the bullet and update the way the information from the form is handled.

Some hosts stopped supporting the default php mail function by default because a lot of amatuer developers didnt know how to use it responsibly and it was attracting spammers who could send mail through the hosting providers mail service, which potentially would get them blacklisted.

If you validate the form information correctly this can't happen but amatuers most would not use any validation, so the form was open to abuse. phpMailer usually requires authentication so its more secure in terms of spamming and less open to being incorrectly deployed by amatuers

We have recently moved our NPM over to new Servers and updated to NPM 12.5. We use NPM primarily to monitor network infrastructure (routers, switches, firewalls, APs, etc.) and have it working with our HPSM ticketing system to generate tickets on alerts.

We have a few alerts setup that executes a program using perl when a WAN interface goes down. The perl script telnets to a router and pulls some show run commands and then emails our ticketing system in xml format. These alerts are triggering since we moved to new Servers and updated 12.5 however there seems to be an issue with the perl script.

I have installed ActivePerl on the new Servers and have copied over all the appropriate files for the scripts from our old NPM server. I am having trouble figuring out where I can look on the NPM server to see if the perl (.pl) file is even being exexcuted.

I am reaching out to the community to see if anyone that has used ActivePerl with alerts could help point me where to start troubleshooting or logs to look at as to why the script may not be working or even being executed. I can run the script from a command prompt on the server and it seems to run.

I setup the windows audit and when I run a simulation I see the perl.exe file being accessed in the Windows Security Logs. Now it seems I must discover what is failing or not working with the .pl file. I am new to perl and ActivePerl so I am not sure how to see why the script is not completing or what in the script is failing. Would there be any log files associated to ActivePerl? I have tried to duplicate everything from the old server on the new server like Environment Variables, script paths, etc.

Not a solution to your problem but I've had similar problems often enough that whenever I write scripts these days I always include a chunk of boilerplate code to make sure it writes a log output somewhere. So many hours wasted trying to reverse engineer scripts that I find laying around on client systems.

These are scripts that have been inherited and the author is no longer with our company. All the scripts have been working for years but we just moved over to new Servers (windows 2012 to 2016) and updated NPM (12.1 to 12.5) these scripts are not working. I think I have been able to determine that the script is being called as it should (by doing the windows auditing) so it would be great to somehow have some log output to help see what is going on in the script is called. I do not have any real perl experience so I am not sure how to include boilerplate code.

Yes it looks like it may be Perl module related. The old server had ActivePerl 5.1.42 and now it looks like 5.26 or 5.28 are available. I am having trouble getting some of the modules needed installed for both 5.26 and 5.28. The following are the modules being called. I have been able to get Net::Telnet:Cisco and MIME::Lite installed but having trouble getting Win32::Env. I have tried using cpan and Win32::Env fails with dependencies of Win32::Console and Win32::TieRegistry. I have tried to cpan install both those modules but does not seem to complete. I am also having trouble getting ppm installed and I have not had any luck building a configuration on the ActiveState fork custom build. I keep getting an unable to build the distributions for this project when I select the Win32 modules to be included in the build.

3a8082e126