views:

486

answers:

4

I have a solution based on ASP, VB6, COM and SQL Server. The web server is IIS 6.

At irregular intervals, I get the following error message on the ASP page:

Microsoft VBScript runtime (0x800A01FB)
An exception occurred: 'objPSM.GetValue'

(where "objPSM" is my own session-handling COM class).

If I reload the page, it works.

I tried Googling the error code, it turns up this article (http://support.microsoft.com/kb/262681), but that should not apply to my problem as I do not use the Session object -- I have my own session-handling code that uses cookies and the database to store state.

Here is the VB code that bombs out:

Public Function GetValue(ByVal pSessionID As String, _
                         ByVal pName As String) As String

   Dim ErrSource As String
   Dim ErrNumber As Long
   Dim ErrDescription As String

   On Error GoTo Err_Handler

   Dim lConn As ADODB.Connection
   Dim cmd As ADODB.Command

   Dim lReturnValue As String

   Set lConn = GetDBConn
   Set cmd = CreateObject("ADODB.Command")
   cmd.ActiveConnection = lConn
   cmd.CommandText = "pss_getvalue"

   cmd.Parameters.Append cmd.CreateParameter("p_pss_id", adVarChar, adParamInput, 36, pSessionID)
   cmd.Parameters.Append cmd.CreateParameter("p_pss_name", adVarChar, adParamInput, 35, pName)
   cmd.Parameters.Append cmd.CreateParameter("p_pss_value", adVarChar, adParamOutput, 255)

   cmd.Execute , , adCmdStoredProc

   lReturnValue = Nvl(cmd.Parameters("p_pss_value").Value, "")

   lConn.Close
   Set cmd = Nothing
   Set lConn = Nothing

   GetValue = lReturnValue

Exit_Procedure:
   Exit Function

Err_Handler:
   ErrSource = Err.Source
   ErrNumber = Err.Number
   ErrDescription = Err.Description
   On Error Resume Next
   Call LogEvent(ErrSource & ".GetValue: ", ErrNumber & ": " & ErrDescription)
   GetValue = ""
   GoTo Exit_Procedure
End Function

Note that even though there is an error handler here, the code never gets here because the VB runtime stops and throws the exception, resulting in a broken ASP page instead of silently logging and returning a blank string.

Anyone know what the error code (0x800A01FB) means?

UPDATE: Talked to the hosting provider and they recycled the IIS application pool. The error went away. Will return to this question if the problem re-appears.

+1  A: 

The most likely source for this error is ADODB. See why-do-i-get-800a01fb-errors.

Since the COM class is your own have you considered attaching a debugger to the process in which ASP is running and having a look at where in your COM code the error is occuring? Failing that adding some error handling to your COM code to generate more details about the error before it leaves your component?

AnthonyWJones
Yes, most likely the OP must install/reinstall the latest version of MDAC as specified in the link you provided.
Richard Hein
Richard Hein
I've updated my question to show the VB code. The error handling does not work as the VB runtime just shuts down. Using a debugger is not possible as this error happens only on a hosted instance over which I have no control (the error does not happen in my dev environment, and only about every 4-5 page view in production, although the code is called on every page).
ObiWanKenobi
If your handler isn't catching the error then you are seeing a more catastrophic error, do you see anything in windows event logs? Can you talk to the server owners about the condition of the MDAC install on the server?
AnthonyWJones
Try adding a SET NOCOUNT ON at the top the Stored Procedure. Thats one of my common "try and see" solutions which for reasons that are beyond me often fix strange errors coming from ADODB. That said such errors could always be caught in VB.
AnthonyWJones
SET NOCOUNT ON is already present in the stored procedure.
ObiWanKenobi
A: 

Looks like - objPSM - may be using a RecordSet with adUseClient as one of the parameters either on the RecordSet or the Connection Object as this is being using in the GIT.

"COM provides a component called the Global Interface Table (GIT). The GIT allows an application to store a reference to an object's interface in the table so that the interface pointer can be retrieved at any time. When storing the interface pointer into the GIT, the object is queried for IMarshal and if IMarshal is exposed by the object, the marshaling data of the object is placed into a stream where it can be retrieved at some later time when the interface pointer is retrieved. IMarshal is exposed by the client cursor which actually does the passing of the recordset data. There is a problem if an open ADO Recordset object which uses adUseClient is placed into the GIT and then is later revoked from the table. An access violation will occur. To avoid the problem, place the Recordset's interface pointer into the GIT before calling Open on the Recordset. This will place the interface pointer into the GIT before the client cursor engine is invoked which will essentially cause standard marshaling to occur rather than record data being streamed from the cursor engine through IMarshal. Only a pointer to the ADO Recordset's interface will be stored in this case which is the real intent of the programmer." http://support.microsoft.com/kb/249175/EN-US/

To understand Marshalling http://support.microsoft.com/kb/248287/EN-US/

Looks like this was fixed in MDAC 2.6

How to check your server version of MDAC http://support.microsoft.com/kb/301202

A: 

All such error codes are defined in winerror.h (Googled it and got this link: winerror.h Read about the 32-bit error code format first to understand what each bit means, so that you can understand similar error codes in the future.

01FB is the error code: CO_E_OBJNOTREG (object is not registered)

00A refers to the "facility" where the error occurred:

#define FACILITY_CONTROL 10

azheglov
CO_E_OBJNOTREG is a ITF facility error, it does not map to the error in question. winerror.h does not define any errors for the CONTROL facility which is the whole point. Errors in the CONTROL facility (and the ITF over numbers 512) are allocated at the control or interface designers discretion. The 01FB cannot be correctly interpreted until the source is identified.
AnthonyWJones
+1  A: 

Talked to the hosting provider and they recycled the IIS application pool. The error went away.

ObiWanKenobi