IIS8/FastCGI/perl+COM RRS feed

  • Question

  • User629088133 posted

    I've got IIS8 working with fastcgi & perl in general, but when my test perl script tries to use Win32::OLE to create a COM object, the weirdness begins in earnest. If I run the perl script in a cmd.exe window, it works fine. The script attempts to create two different COM objects:

    • Scripting.FileSystemObject
    • Clearquest.session

    Again, from cmd.exe window it works fine. The user account I'm using is in the local administrators group. The same user is being used for the DefaultAppPool, so I'm pretty sure it's not security related. Here's what's weird: creating the COM object when the script executes in the fastcgi context fails with 0x800401f3 'Invalid class string'. So, I built a debug version of the Win32::OLE perl module & stuck a whole bunch of debugging messages in it. The call to CLSIDFromProgID is the culprit. Same object, works in one context and not the other. So, I fired up procmon to see what I could find there. This turned up a 'CreateFile' from perl.exe on 'C:\perl\bin\%systemroot%\Registration\R000000000012.clb', which clearly fails with 'PATH NOT FOUND'. Just for grins, I created a symlink in c:\perl\bin named '%systemroot%'. With that in place, creating the 'Scripting.FileSystemObject' object actually works, but not the 'clearquest.session'. 

    So, my general question is: what is different between the context of running from a command window vs. under IIS's fastcgi module that would cause this behavior and is there anything I can do to alter it?




      A few items I forgot to mention:

    • this happens with several different versions of perl, e.g. activestate 5.14, 5.16 & 5.20, strawberryperl 5.20
    • the %systemroot% symlink goes to c:\windows
    • it works OK as CGI rather than fastcgi, but the startup & login cost of the clearquest.session object is quite high, so I'd rather not use CGI
    • this is a porting project from apache 2.0/mod_perl on windows
    • the test perl script is only using Scripting.FileSystemObject for comparison. The clearquest.session object is the one I really need.
    • wrapping the handler with a cmd.exe /c (32 or 64 bit versions) fails spectacularly
    • the perl version in all cases is 32-bit
    • the app pool is 32-bit enabled
    • the app pool .Net Framework Version is set to 'No Managed Code'. This was originally v4.0. Changing had no effect (as I expected it wouldn't)
    Friday, May 8, 2015 4:58 PM