Re: A Very Troubled Application...

I don't have direct access to their COM object.  They have wrapped their COM
in their own .NET wrapper and I use it instead.
This program has been around for a long time (and I'm not at liberty to
divulge the name) but you can tell that it is very poorly written with
numerous bugs, especially when accessing the details via COM (through their
wrapper).

I am able to catch the exception but it's never consistant.  One time it's a
COMException and then another time it's a BadImageFormatException.
Grant it, this does not occur very often, but I need to make this
application (mine) as reliable and available as humanly possible by making
this 3rd party app "reliable".  Perhaps I'm trying to work miracles here but
I really need something to work.

On Tue, Jun 9, 2009 at 4:59 PM, Peter vd Weerd <[email protected]> wrote:

> 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
>

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