We're moving our old Perl/CGI application to a new system internally and ran into a snag. When I run:

perl -MXML::Parser -e 1

From the command line, all is well. However, when I run it from a CGI script as use XML::Parser, all hell breaks lose:

Can't load
'C:/strawberry/perl/site/lib/auto/XML/Parser/Expat/Expat.dll'
for module XML::Parser::Expat:
load_file:The specified module could
not be found at
C:/strawberry/perl/lib/DynaLoader.pm
line 200, line 55. at
C:/strawberry/perl/site/lib/XML/Parser.pm
line 18 Compilation failed in require
at
C:/strawberry/perl/site/lib/XML/Parser.pm
line 18, line 55. BEGIN
failed--compilation aborted at
C:/strawberry/perl/site/lib/XML/Parser.pm
line 22, line 55. Compilation
failed in require at (eval 43) line 1,
line 55. BEGIN
failed--compilation aborted at (eval
43) line 1, line 55.

Other modules added onto the perl installation work fine (MD5, WIn32::ODBC, etc...) but this Expat one snarls.

The server is IIS 7 (new to us for this app), x64 Win2008 (also, new to us).

EDIT:

After futzing around with this for a while, this isn't the only module that fails to load. XML::Simple does as well. Almost the same error. The DLL's that Perl is claiming do not exist, exist just fine. And things work from the command line as well.

You may be completely right, I'm just having trouble putting the pieces together of why a bug in CWD that works on the command line stops working in CGI context. The guilty fingers both point in the general direction of Dynaloader, but I think one is a cause and the other is an effect.I did find a workaround (see below).
–
Clinton PierceOct 27 '10 at 13:59

After hours of poking away at this, the problem turns out to be in the IIS ApplicationPool settings. If you have Load User Profile set to False then Perl's Dynaloader craps itself and nothing works -- and without particularly useful messages. I don't know which is the default, but having it false causes everything to fail.

So right now things are working nicely, and here are the settings in the Application Pool:

32-Bit: Enabled
User: Application Pool
Load User Profile: True

I found this by attempting to get the CGI programs to run as a real user (the one that I was using at the command-line) and noting that I wasn't getting the environment I wanted even though I had the right user set up. Flipping this switch caused everything to work. Eventually I went back to using Application Pool but confirmed this switch was the cause.