Having problem with VB CGI program that uses an ActiveX EXE object

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

I've created a testing VB6 Console app to use as a CGI program. It uses
standard in and standard out and when I install it in the CGI directory of
the IIS server and invoke it from IE the program works great and returns the
correct info to IE.

When I try to add a reference to an instance of an object from an ActiveX
EXE program running on the IIS server to this VB6 CGI program, the program
fails to run as a CGI program in IIS any more.

Here's some more background:

I've written a VB6 ActiveX EXE program that creates a resource pool of
objects from another program (for arguments sake, lets pretend this is a
pool of Excel spreadsheet objects or something). This resouce pool program
has public classes that give access to the elements in the resource pool.

I've got a "manager" program that I run that creates the initial instance of
the ActiveX EXE resource pool.

When I add code to instantiate an instance of one of the resource pool
element objects in my VB6 console program, it still works just fine when I
run the program from the command line (Program fires up, instantiates an
instance of the pool element, makes some method calls on the object and
closes cleanly). HOWEVER, when I try to run the same program through IIS by
invoking from IE, all that happens is I hear a loud "thunk" on the IIS box
and the program appears to just not run. I peppered the program with code
to write messages to files to see where it is failing and it appears to
completely crash as soon as it trys to instantiate the resource pool object.

Are there some kind of restrictions on accessing shared DLL's from within
programs being run by the IIS CGI engine or something? I seem to remember
something about options in IIS regarding using protected or shared memory
spaces or something... if my memory is correct this seems like a possible
culpret.. might I be on the right track?

Any help would be greatly appreciated!!!

Regards,
Tom Malia



.

Relevant Pages