error '80004005' on a new method call

[rlawrence]

Once again, after several days of troubleshooting, I throw myself at the mercy of the gurus on this forum. I confess that I am not sure where to post this problem, but since it shows up in my ASP application, I'll start here.

I have a component application implemented in Visual Foxpro 7 and installed as a COM+ application on Windows 2003. I am adding this function of our web application implemented in Classic ASP. I recently added a new function to the application, which of course means there are new method calls on the component. Upon calling this new method, I receive the following error:

error '80004005'
/Payment.aspa, line 46

Here's the offending call:

If not [COLOR=red]rmcInvoice.AddPromotion(rcInvoice, cPromotionId)[/color] then
    Call Warning("Could Not Apply Promotion: " & cPromotionId, rcInvoice.rsOrder.cMessage)
    Exit Function
end if

Here's a list of actions and observations so far to better understand the cause of the problem:

[ol 1]
[li]First, of course, I tested the method in VFP and it is working.[/li]
[li]The VFP testing included instantiating the component from the DLL. That works as well.[/li]
[li]I have completely removed and reinstalled the COM+ component on the server to make sure the interface is up to date. After reinstalling, I can see the method call for AddPromotion() in the Component manager.[/li]
[li]The problem seems to be with the first paramter, "rcInvoice". If I substitute another variable set to "Nothing", my method correctly logs an error. When I reinstate rcInvoice, I get the unspecified error. In other words, it never makes it to my VFP code at all.[/li]
[li]rcInvoice is a custom object that holds the data for an order. It has been in use for years.[/li]
[li]I can look at the contents of rcInvoice just prior to the call and it looks fine.[/li]
[li]I can submit rcInvoice to other methods and they work just fine.[/li]
[li]On the chance that there was some problem with the reference to rcInvoice, I created a completely new instance of rcInvoice (using another variable) and retrieved the same order into that instance. The retrieval is successful. The subsequent call to AddPromotion fails in the same way.[/li]
[li]Retrieving a completely different order fails in the same way. So, it doesn't seem to be the data.[/li]
[li]In a completely different area of the application, a function that adds a product to the shopping cart is failing in the same way. This function has been in use for years.[/li]
[li]I can't find any other method calls or any other use of rcInvoice that causes this same behavior.[/li]

At this point, I'd be happy with new ideas on what to look for. Any help would be greatly appreciated.

Thanks in advance,
Ron



[/ol]

 

[MarkSweetland]

Not sure if it's applicable, but here's a link concerning parameter type mismatch issues in COM+ that cause the subject error:

http://support.microsoft.com/kb/237536/en-us

Mark

"You guys pair up in groups of three, then line up in a circle."
- Bill Peterson, a Florida State football coach

 

[rlawrence]

Thanks Mark,

I was coming to the point of trying an explicit declaration on the method parameters. I'm not sure why this method would require it where others (using the same parameter) do not. I'll give it a shot.

Ron

 

[rlawrence]

O.K. I'm feeling a little stupid now. I thought that an explicit declaration would be a pretty straight forward thing to try. I've certainly done it in some of my VFP components. But apparently I haven't done it for a custom object set up as a parameter for my methods. So, I guess I don't really know how to do that.

Furthermore, this same parameter, rcInvoice, is used in virtually EVERY other method in the component in question. So, I don't see an explicit declaration working for this one method when clearly it is not used or needed for any other.

Finally, it's also clear that the failure is happening long before it gets to the component. It's happening in VBScript immediately upon the call.

I've also been poking around the IIS and COM+ logging. COM+ apparently has a DUMP facility that logs a memory dump when a failure occurs. I could not get it to work. It seems to me that that MAY mean that the problem is not with COM+. The IIS log simply shows a 500 status at the point of failure. Not much help.

Any thoughts on how I can gain more visibility into this failure?

 

[MarkSweetland]

You may have to reset the registry on the server to allow the web server to serve up the object. Removing and reinstalling the component through the interface may have also removed the registry entry and maybe the client Id of the component changed.

It's been such a while ago since I messed with all that, but the entry for custom objects would be in HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\W3SVC\Parameters\ADCLaunch


Mark

"You guys pair up in groups of three, then line up in a circle."
- Bill Peterson, a Florida State football coach

 

[rlawrence]

I used RegSvr32 to uninstall and reinstall the DLL. Wouldn't that do what you describe?

I also just used RegEdit to look for the component. I didn't see the specific methods, but the component is certainly there.

There appears to be nothing in the registry path you mentioned. The path is there, but there are no values contained within.

What else should I be looking for?

 

[MarkSweetland]

I think the issue is really COM versioning and binary compatibility. The interface can't be changed once it's published under a specific GUID. Here's a link that explains it better that I can:

http://msdn.microsoft.com/en-us/library/windows/desktop/aa378963(v=vs.85).aspx

Mark

"You guys pair up in groups of three, then line up in a circle."
- Bill Peterson, a Florida State football coach

 

[rlawrence]

Thanks again Mark,

I think you are right. Here's a new development...

In my investigation, I have found a couple of helpful troubleshooting guides that give me confidence that the problem is not with IIS nor is it with ASP in particular.

Troubleshooting IIS 6.0

ASP Troubleshooting Tips and Techniques

Both are very well written. Although I was familiar with much of this material, I found it very reassuring to walk through these guides to better understand my problem. One suggestion that was particularly helpful from the IIS troubleshooting guide:

In order to determine or eliminate permissions as a cause, temporarily add the IUSR_machinename user to the Administrators group. In my case, I did so and it did not change the behavior. That eliminates a whole realm of possible causes.

It's also clear, since I can use Response.Write statements to view the content of rcInvoice just prior to the call to AddPromotion(), that I'm not dealing with any issues with IIS or HTTP.

So, I decided to go back to Foxpro. I modified my test program to work in the server environment and created a simple EXE that would use my component. The test program works on my development machine, but FAILS in exactly the same place (the call to the AddPromotion method) on the server. I get the following error message:

OLE Idispatch exception code 0 from ?: ?..

I believe this means that there is a problem with the interface, though I still do not understand why--particularly after completely uninstalling and resinstalling the DLL.
I'm now looking for ways to find the cause for the above error message. So far, my searches have not turned up anything helpful. The article you cite, Mark, sheds some light on what might be happening. Some sort of problem with the GUID, but it doesn't seem to explain what to do about it.

Sorry for the lengthy discussion. I'm writing this out for my own benefit as much as I hope it will help others. I suppose that means I should pull up stakes and move on to a more appropriate forum. However, when troubleshooting this kind of problem, the systems are so complex that it's not clear where to start. So, if it's O.K. with the keepers of this forum, I'd like to continue this discussion through resulution. I think I'm close.

 

[rlawrence]

Frustrated here... :-/

This looks like a straight forward interface problem, which seems like it should be easy to resolve by uninstalling and reinstalling the DLL. Using RegSvr32 to unregister and reregister the DLL has no effect. Subsequently, removing the components and reimporting them to COM+ also has no effect.

What am I missing????

 

[MarkSweetland]

The only other thing I can think of is Shadow Copy...

http://www.ipreferjim.com/2012/04/asp-net-appdomains-and-shadow-copying/

Mark

"You guys pair up in groups of three, then line up in a circle."
- Bill Peterson, a Florida State football coach