Re: A Very Troubled Application...

So it is an out-of-process COM-component?
Where is the actual access violation? I mean: is it in the process where the 
real component lives and is the exception marshalled (probably)? Or does it 
occur in the hosting process?

Are you able to try - catch the exception?
It is also possible to set an unhandled exception filter on your 
application: see the Application.ThreadException event.
You can log your exception there and try to go on...

The hosted process, where the COM-component lives will only die if the 
refcount goes to zero.
To forced decrement the refcnt you can explicitly set the reference to null 
and do a garbage collection.
The other way is to call Marshal.ReleaseComObject() on that reference.
Note that ALL references should be handled that way.
After that, the process should be gone.



----- Original Message ----- 
From: "Mike Andrews" <[email protected]>
To: <[email protected]>
Sent: Tuesday, June 09, 2009 8:57 PM
Subject: Re: [ADVANCED-DOTNET] A Very Troubled Application...


> Normally I would agree with you but I'm not sure how I can do this.
> The real problem is that I need to create the COM object in my primary 
> .net
> assembly (the assembly that handles the necessary method calls to the COM
> object to do the work I need done).  The COM object then instantiates the
> executable.  (It's not fun to work with let me tell you...)
>
> I can do as you suggest, but only my primary .net assembly will utilize 
> the
> COM object and that's where the COMException will occur and then I have no
> control over when it crashes.  Are you suggesting that I create a 
> secondary
> assembly that wraps the COM object and that that assembly works with the 
> COM
> object and then I can isolate the COM that way and then I utilize my
> secondary assembly within my primary assembly?  Also, how can I fix the
> random behavior exhibited when the application crashes such as an Access
> Violation which results in a dialog?
> I really appreciate the help.
>
> Thanks,
> Mike
>
> On Tue, Jun 9, 2009 at 1:42 PM, Peter vd Weerd <[email protected]> wrote:
>
>> Hi Mike,
>>
>> Because you use COM-components, and because you don't trust them, 
>> creating
>> a separate AppDomain (.NET's notion of a process) is less robust than a
>> separate process. A failing COM-component is able to corrupt the memory 
>> that
>> is used by the .Net VM. Even memory that is used by a different 
>> AppDomain.
>>
>> Yes, I propose to create an application wrapper, that does nothing more
>> than spawning your original application, and wait for it. If it ends (by 
>> a
>> crash), just spawn it again.
>> To discriminate between a crash and a normal end, return a special 
>> non-zero
>> returncode from your original application. For instance 123. Of course 
>> both
>> the wrapper and the original app should agree on this value.
>>
>> The fact that your primary application can be spawned only once doesn't
>> feel like a problem: the application wrapper will only spawn a new one if
>> the previous instance failed...
>>
>> /Peter
>>
>>
>>
>> ----- Original Message ----- From: "Mike Andrews" <
>> [email protected]>
>> To: <[email protected]>
>> Sent: Tuesday, June 09, 2009 7:08 PM
>> Subject: Re: [ADVANCED-DOTNET] A Very Troubled Application...
>>
>>
>>
>> Hi Peter,
>>>
>>> Thanks for the reply.
>>>
>>> Right now I'm creating a separate AppDomain and instantiating my Wrapper
>>> object (which wraps all of the COM method calls because any method call
>>> can
>>> cause a COM exception) inside that AppDomain.  Another problem with this
>>> process is that it only allows one instance at a time (by reading the
>>> process list and seeing if it's already there and if it is it throws up
>>> another dialog).
>>>
>>> I'm not sure what you mean by creating a worker-process.  Would I create
>>> an
>>> application wrapper that then spawns the primary application?  If the
>>> primary application fails would the worker-process fail or would I just
>>> attempt to restart it?
>>>
>>> Thanks,
>>> Mike
>>>
>>> On Tue, Jun 9, 2009 at 12:00 PM, Peter vd Weerd <[email protected]>
>>> wrote:
>>>
>>> Mike,
>>>>
>>>> In general: if you have access violations caused by COM-components, its
>>>> not
>>>> a good idea to recover from that.
>>>> If you can isolate the complete application to a kind of a
>>>> worker-process,
>>>> you write a controller-program that starts this worker-process, and if 
>>>> it
>>>> fails, just start a new one.
>>>>
>>>> Windows is very good in recovering from crashed processes: all 
>>>> resources
>>>> are freed. So, when the controller process fires up a new 
>>>> worker-process
>>>> its
>>>> a brand new one with clean memory, a clean .NET virtual machine, etc.
>>>>
>>>> /Peter
>>>>
>>>>
>>>> ----- Original Message ----- From: "Mike Andrews" <
>>>> [email protected]>
>>>> To: <[email protected]>
>>>> Sent: Tuesday, June 09, 2009 6:06 PM
>>>> Subject: [ADVANCED-DOTNET] A Very Troubled Application...
>>>>
>>>>
>>>>  I have a very troubled application (not mine but a 3rd party) that 
>>>> likes
>>>>
>>>>> to
>>>>> fail with various Unhandled exceptions (memory access and others) when
>>>>> certain files are loaded (I have no idea of the reason).  Sometimes
>>>>> loading
>>>>> a file causes a COM exception to occur (no one knows why and it's very
>>>>> unlikely that the manufacturer will ever fix it).  This causes the
>>>>> entire
>>>>> application to crash (and/or provide some other unpredictable 
>>>>> behavior).
>>>>> This does not occur most of the time but only occasionally.  However I
>>>>> must
>>>>> account for these eventualities as this process will be running on
>>>>> multiple
>>>>> servers and I need it the most stable I can get it.
>>>>>
>>>>> What I have been doing is looking for the process in the process list
>>>>> and
>>>>> then killing it.  That works most of the time but when one of those
>>>>> dialogs
>>>>> is thrown up asking you to click OK it really messes things up.  I've
>>>>> started looking for the dialog, but the time when the dialog appears
>>>>> varies
>>>>> so any predictability is out.
>>>>>
>>>>> What I need to know is if it's possible to attach a hook (or some 
>>>>> other
>>>>> such
>>>>> mechanism) to the window to intercept any unhandled win32 exceptions
>>>>> similar
>>>>> to the capability available in the .NET framework.  I'm at my wit's 
>>>>> end
>>>>> here
>>>>> on this one.  I need to create something stable enough so I can 
>>>>> recover
>>>>> on
>>>>> the server and continue.
>>>>>
>>>>> Any help or information would be most appreciated.
>>>>>
>>>>> Thanks,
>>>>> Mike
>>>>>
>>>>> ===================================
>>>>> View archives and manage your subscription(s) at
>>>>> http://peach.ease.lsoft.com/archives
>>>>>
>>>>>
>>>>> ===================================
>>>> View archives and manage your subscription(s) at
>>>> http://peach.ease.lsoft.com/archives
>>>>
>>>>
>>> ===================================
>>> View archives and manage your subscription(s) at
>>> http://peach.ease.lsoft.com/archives
>>>
>>>
>> ===================================
>> View archives and manage your subscription(s) at
>> http://peach.ease.lsoft.com/archives
>>
>
> ===================================
> View archives and manage your subscription(s) at 
> http://peach.ease.lsoft.com/archives 

===================================
View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives