locked
Foxisapi permissions issue (I think) RRS feed

  • Question

  • Windows Server 2003
    IIS 6
    VFP6.0 SP5
    Latest copy of foxisapi.dll
    http://localhost/common/foxisapi.dll/STATUS displays correctly
    I have a testServer method that just returns a string and it doesn't
    work, and the COM server does not load.
    http://localhost/common/foxisapi.dll/myServer.class.testServer returns "The page cannot be displayed"

    Web site is running ok.
    Everyone, IUSR_ & IWAM_ are set for default launch & access permissions in DCOMconfig.
    The COM process is set to use the default Launch and Access Permissions.
    The COM process is set to impersonate a user. I have logged in as that user
    and been able to run the exe.
    I have an error routine that logs errors but it is not getting called.
    I have set the impersonation account to have full control in the directory where the executable is.
    I have reinstalled IIS

    I am at a loss as to what to do next, any ideas?
    Thursday, July 21, 2005 12:57 AM

Answers

  • To test whether the webserver accounts can really create the server, you can use a small ASP page that instantiate the COM object:

    <%
      dim oref as object
      set oref = createobject("myserver.class")
      Response.Write( oref.testserver )
    %>


    Thursday, July 21, 2005 5:12 AM

All replies

  • To test whether the webserver accounts can really create the server, you can use a small ASP page that instantiate the COM object:

    <%
      dim oref as object
      set oref = createobject("myserver.class")
      Response.Write( oref.testserver )
    %>


    Thursday, July 21, 2005 5:12 AM
  • I did as you suggested. It worked! Which is not surprising really because you have helped me out with some tough ones before.
    So my current situation is that I have set an Application pool (IIS6) for my Foxisapi applications. The COM server can be started from an .asp page but not from the foxisapi.dll. I get "Cannot find server or DNS Error" and yet I can run the RESET and STATUS requests. It would seem that foxisapi doesn't have permissions to start the COM server but when that has happened in the past I was sure that I would get an "access denied" message back.
    Thursday, July 21, 2005 10:40 AM
  • I found this in the event log:
    "A process serving application pool 'foxisapi' terminated unexpectedly. The process id was '3152'. The process exit code was '0xc0000005'."
    c00000005 looks like the COM server is trying to start and dies before it really gets going. I have verified that that is not happening when it is run from the .asp page.
    Thursday, July 21, 2005 10:47 AM
  • Hi Paul,

    That's a difficult one. Are you using the latest FoxIsApi version? There were COM related problems in older ones, some of which should have been fixed in VFP 8.

    Can you monitor the page request using FILEMON and REGMON from http://www.sysinternals.com? The goal here is to determine at which point you get the crash. It might happen in your code, in the VFP runtime, or it might be the FoxIsAPI DLL. In your COM class write to a log file in the very first line, or use OutputDebugSttring like this:

    Declare OutputDebugString in Win32API String
    OutputDebugString("COM server started...")

    Use DbgView from Sysinternals to view the output from the API call above. If you have the address at which the crash occurs, you can use Process Explorer (again from Sysinternals, you should bookmark that site<g>)  to determine which DLL is causing the crash.

    If that doesn't work, do you have Visual Studio or VC++ installed? The next steps might include debugging the ISAPI Dll.
    Monday, July 25, 2005 6:03 AM
  • Thanks for your time Christof,
    I replaced the version of foxisapi with another one that I had, but to no avail.
    The next step was to write to a log file from the very first line in the olepublic class, it never made it that far.
    Anything beyond those 2 steps is going to take me into places that unfortunately can't be justified by the time and effort.
    I think it is the O/S environment. The box is running Small Business Server 2003 and it is configured with all sorts of unnecessary overheads for the job I need it to do. The next step for me is to install Windows 2000 server and get it to a point that I know works on other servers that I am running.

    Thank you very much for your help though, it was good to know that I had not missed anything too obvious.
    Monday, July 25, 2005 10:20 AM