none
.NET 2.0 COM interop issue - when calling from Classic ASP RRS feed

  • Question

  • Since last year December 2007 I’m facing two errors in our Classic ASP application: The problem occurs when the code tries to create an instance of a .Net DLL from an ASP page:

     Error No.

                   Server object error 'ASP 0177 : 80131509'

                                    Server.CreateObject Failed

                                    /includes/trk_SessionEndTime_Cookie.asp, line 32

    CODE:

                                    Dim oCom

    Line 32 - - - >      set oCom = server.CreateObject("ComName.Class")

                                    oCom.Extract Session("Session_id"), false , 0

     

    Error No. 
                error '80070002'

                                    /includes/ServerProc.asp, line 193

    CODE:

                                    Set objCommand = Server.CreateObject("ADODB.Command")

    Line 193- - - >     set oCom             = server.CreateObject("ComName.Class")

                                    oCom.Extract cookieVal_array(0), false, 0

    Server.CreateObject works when creating ADODB.Command object but fails when creating my own COM object. If I re-start the IIS then application once again work without any problem.

    The difference in two errors mentioned above is not same. Error: 80131509 is intermittent and some users have to see this error. The COM class is usually called on every users every page hit.

    COM property is setup true for “Make assembly COM visible”. And also registered as regasm /cobebase /tlb parameters

    We suspect that this error usually comes when there is heavy traffic on site, but yesterday we faced this issue at 2:45 AM in monning. At that time there is usually no load on server.

    I saw many posts on site for help on this issue, but no one was satisfiied and posted his final satisfactory comments how they solved their issues? If someone has this faced and fixed - plz share.


    Shamshad Ali.

    Saturday, August 16, 2008 12:37 PM

Answers

  • You are making an awfully big assumption when you say that exceptions should be reproducible.  Far from it, they are designed to deal with unusual problems in exceptional circumstances.  Heavy loads would certainly qualify.  You are posting to the wrong forum about IIS or ASP problems under heavy load.  Try forums.iis.com and forums.asp.net.  Giving them a stack trace of the crash will no doubt get you a quick answer.
    Hans Passant.
    • Marked as answer by Zhi-Xin Ye Wednesday, August 20, 2008 11:33 AM
    Sunday, August 17, 2008 6:02 PM
    Moderator

All replies

  • The .NET code is throwing an InvalidOperationException that isn't being caught.  That happens.  Could be anything, you'll need to add some catch blocks to your code that captures the stack trace and logs it.  Letting a debugger break on the first chance exception is another way to trap it.  No idea how to do that with an ASP app.
    Hans Passant.
    Saturday, August 16, 2008 1:44 PM
    Moderator
  •  

    Thanks for your reply, appreciated.

    My own opinion is that if .NET code is throwing an InvalidOperationException, then it should not work for all the time or it should be frequent. But from our experience on production, this error comes only when there is load on site and it is faced two times in the duration of 8 months.

    Also does such exception may cause IIS to stop responding? Until we reset IIS it won't work anymore.

    Debugging production scenario is typically hard to setup and find clue, I will try your suggestion by implementing catch block in code and try to capture logs on local testing.



    Shamshad Ali.

    Saturday, August 16, 2008 2:47 PM
  • You are making an awfully big assumption when you say that exceptions should be reproducible.  Far from it, they are designed to deal with unusual problems in exceptional circumstances.  Heavy loads would certainly qualify.  You are posting to the wrong forum about IIS or ASP problems under heavy load.  Try forums.iis.com and forums.asp.net.  Giving them a stack trace of the crash will no doubt get you a quick answer.
    Hans Passant.
    • Marked as answer by Zhi-Xin Ye Wednesday, August 20, 2008 11:33 AM
    Sunday, August 17, 2008 6:02 PM
    Moderator