My application calls a webservice, when I push a button on the application. The webservice adds some rows to my database. I can successfully call the webservice and see the rows in the DB many times.. but randomly without change to code, the button press within the app will raise this error (the little yellow ! in IE 7, like a javascript error):

Line: 1
Char: 1
Error: Unhandled Error in Silverlight 2 Application Exception has been thrown by the target of an invocation. at System.RuntimeMethodHandle._InvokeMethodFast(Object target, Object[] arguments, SignatureStruct& sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner)  at System.RuntimeMethodHandle.InvokeMethodFast(Object target, Object[] arguments, SignatureStruct& sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner)

...

This particular webservice (WEBSERVICE_A) method makes use of a COM Object, local on the webserver. I have other webservice method(WEBSERVICE_B)  that does not access this COM object. Once my application gets the error above, it can not call WEBSERVICE_A any more (keeps getting the error, the yellow "!"), but I can still call WEBSERVICE_B.

A quick way for me to fix this is to go into IIS on the server, open the application pool that the web app is running on, and "Recycle" the pool. This again allows my silverlight application to access the webservice_a  - without having to refresh / close the silverlight application.

My thoughts are that this is not totally silverlight related, but how can I diagnose this problem..?

So here are two test runs in kind of a timeline view, step by step:

Test run 1:

Open SilverlightTestPage.aspx
Call webservice_B
AsyncComplete for webserviceB - works, returns rows from database to the application

Call webservice_A - works, calls COM on server and adds rows to DB
AsyncComplete for webserviceA - works, calls COM on server and adds rows to DB

Call webservice_A - fails, posts error in first post to small "!" in IE7 in lower left corner, does not crash application

Can still browse to www.domain.com/app/webservice/servicename.svc, opens fine

Call webservice_B
AsyncComplete for webserviceB - works, returns rows from database to the application

Call webservice_A - fails..

Open IIS on webservice, recycle app pool

Call webservice_A - works, calls COM on server and adds rows to DB
AsyncComplete for webserviceA - works, calls COM on server and adds rows to DB

Close Silverlight Application

Test run 2:

Open SilverlightTestPage.aspx
Call webservice_B
AsyncComplete for webserviceB - works, returns rows from database to the application

Call webservice_A - works, calls COM on server and adds rows to DB
AsyncComplete for webserviceA - works, calls COM on server and adds rows to DB

Call webservice_A - fails, posts error in first post to small "!" in IE7 in lower left corner, does not crash application

Can still browse to www.domain.com/app/webservice/servicename.svc, opens fine

Call webservice_B
AsyncComplete for webserviceB - works, returns rows from database to the application

Call webservice_A - fails..

Close Silverlight Application

Open Silverlight App in new IE window

Call webservice_B
AsyncComplete for webserviceB - works, returns rows from database to the application

Call webservice_A - fails..

Recycle pool.. 

webservice_a works again

Debug your webservice and set a breakpoint where the service method is called and see where it fails.

(If this has answered your question, please click on "mark as answer" on this post. Thank you!)

Kind Regards,
Rob Houweling

Visit my blog at http://web-snippets.blogspot.com

Ok did that and it crashed on the webservice call, accessing the COM object. The COM Object has 7 events that I attach to. When it crashes, it does so when I attach to the first event with this error:

COM object that has been separated from its underlying RCW cannot be used.

I will google this further

Seems to be something related to closing and flushing the COM out of asp's memory.. at the end of my WCF service I do this by setting all of the classes from the com = null .. but there is probably a better way to do this.

Anyways it isn't SL related