Having issues setting up ActivePerl 5.32 on IIS10 (Windows Server 2019)

Perl
,
1

Hi,

I’m trying to setup my web site on a Windows Server 2019 machine using IIS10. The website is based on Perl files. I’ve installed a private ActiveState Perl project based off of ActivePerl 5.32.
I’ve configured the web server to invoke the Perl.exe file whenever any *.pl files are requested from the client’s browser using the IIS’s Handler Mappings configuration.

However, when I try executing the perlPerl file, I keep on getting the following error from my browser:

HTTP Error 502.2 - Bad Gateway
The specified CGI application misbehaved by not returning a complete set of HTTP headers. The headers it did return are “”.

Most likely causes:
The CGI process was shut down or terminated unexpectedly before it finished processing the request.
The CGI process has a flaw and does not return a complete set of HTTP headers.

Things you can try:
Check the event logs on the system to see whether the CGI process is shutting down unexpectedly.
Troubleshoot the CGI application to determine why it is not sending a complete set of HTTP headers.

Detailed Error Information:
Module CgiModule
Notification ExecuteRequestHandler
Handler StaticFile
Error Code 0xc0000142

The handler for the .pl file points to the Perl.exe file that was installed to location on my C:\ drive when I installed the ActiveState Perl project previously. There was a Perl.exe file and a Perl5.32.1.exe file in the same directory. I wasn’t sure which one to point to so I just used the Perl.exe file.

I’m pretty sure the configuration is not right somewhere and that’s why it’s not working. I wanted to make sure that I can use the ActiveState project as the target of the IIS handler mappings for the .pl file.

Any help is appreciated.

2

Windows 10 isn’t a good server, and that is entirely intentional. To get the parameter tunings that anything more than a proof-of-concept server will need, you’ll need one of the Windows Server 2019 editions intended to support webservers. It looks like you’ve already figured out that you need to add the IIS toolkit extensions that support legacy engines like the Classic ASP that CGI based sites must have, and that will be the case on a Server version as well.

Is for troubleshooting with IIS 7, but the general principles should be more or less the same.

If you can get those logs, it should show a CGI_LAUNCH event. Confirm there that the perl is configured to be started.

If all is as expected there, the empty headers being returned could mean that IIS is unable to start Perl or can’t run CGI from it. IIS is a service and unless you configure it differently, will be started by the (SYSTEM) userID that Windows uses to manage most services. By design in newer versions of Windows, the system user has very restricted access to what is on the disk. If Perl is not in a location which can be seen and executed by the system user, IIS will not be able to run Perl.

When 5.32 is installed a group of environment variables are set (and report at the end step of the deploy step). These may have only been set for your user ID. For others to run Perl, they need to be set globally. Another way (not great but possibly useful for testing) is to run the IIS process as a different user, such as yourself, to see if changing the environment will solve the startup problem.

You may also be lacking the CGI module. Old Perls defined that the CGI module was an inseparable part of Perl, so it would always be there, but our sample 5.32 projects are just as likely to not include it. If CGI is missing from your configuration, you’ll need to rebuild with CGI included, then remove and redeploy your current Perl instance.

A few years ago, CGI was removed from the core in order to encourage users to select better modern alternatives, like Plack, Catalyst, or Dancer web frameworks. Unfortunately for Windows Servers, all of modern Perl Frameworks expect to be served on webservers that are not IIS. You’ll find that hosting a Perl application on Linux offers many more choices, and if you are committed to using Perl, swapping out your server is likely inevitable.

3

Thank you for the response. Unfortunately, I have to continue to use CGI with IIS and also continue using existing legacy Perl scripts. Fortunately, once I get this issue resolved, I will get the opportunity to work with some modern Perl functionality, ie Mojolicious.

I added the CGI module and a few missing modules/pkgs to my ActiveState project and when I run the Perl scripts directly as arguments to Perl, it does execute correctly so the problem is somewhere with IIS or the Perl executable not being called.

I have been looking into starting IIS as the system user rather than as my userid, which it is currently running under. I’ve also tried installing Perl on a different drive (E:\ as opposed to C:) with no luck.

4

Are you using “state activate”, or “state deploy”, to place the runtimes?

5

I used “state deploy”.

6

Go to the settings panel that shows how your environment variables are set. “deploy” has set some variables for your user ID (bottom half of the GUI panel). IIS won’t be able to see those vars unless it runs as you. You can copy the variable up to the top half of the GUI panel so that they are set globally, and that allows other IDs on the system to run Perl.
The system ID is a special case, but making them global may be enough.

7

So I went back and re-deployed Perl and looked at the system variables that the deploy added/modified. It looks like it actually modified the system variables PATH and PKG_CONFIG_PATH. They were in the bottom window of the of the ENVIRONMENT VARIABLES dialog. I made the same changes to the upper window (User variables for ) and restarted the server and then tried again but still no luck.

8

On another note, I found that the Perl.exe and Perl5.32.1.exe files that were installed are only 20KB each. On another server where we have this same setup running correctly(except the ActiveState Perl version is 5.24 I believe), those two files are like 132KB and 138K respectively.

9

I have been working with MS to determine if Perl is being launched or not. We found out that indeed IIS and the CGI module is launching Perl but Perl is terminating unexpectedly. The error code is 0xc0000142. This error code according to MS means:

STATUS_DLL_INIT_FAILED {DLL Initialization Failed} Initialization of the dynamic link library %hs failed. The process is terminating abnormally.

Does this imply that this version of Perl needs to select the Perl DLL file as the handler to invoke as opposed to the Perl.exe file like we have used in that past. Or does it point to the fact that the Perl.exe file is only 20KB as opposed to 132KB as previous Perl versions?

10

It should still be the .exe file, I think.

The difference in size comes from them being build with different builder generations.
Up to 5.28 the Perl.exe would be around 130KB. From 5.32 and forward, they’re all around 20KB.

11

We will dig into the reason for the size difference. That might indicate a possible reason for throwing a 142 error.

12

Things have evolved a bit with 5.32 and higher and with how the State Tool does folder layouts between State versions 0.35 and older and the newer State Tools. If the IIS handlers are mapped in the old style to exe files in the ./bin folder it’s not going to work. Old Perls had a lot more static linking than the new ones, and were relocated differently during the installer process. The newer Perl layout has a ./exec folder, and in normal use this folder should be higher on the PATH than the ./bin folder. If the handlers are pointed at the files in ./exec instead of ./bin they are more likely to work.
“More likely” is about the best I can offer though. We haven’t tested the IIS + Classic ASP + CGI + Perl use case in years, and development in the Perl community has moved on, going to Plack middleware layers + a Perl framework instead of CGI.