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