Re: A Very Troubled Application...

Did they make their own wrapping assembly? Strange!
I would assume that they had generated it by imptlib.
If so: the method with Marshal.ReleaseComObject() will work. Did you try it?

Did you try to use the Application.ThreadException event? What happened?
Why is inconsistency in the exceptions a problem?

/P

----- Original Message ----- 
From: "Mike Andrews" <[email protected]>
To: <[email protected]>
Sent: Wednesday, June 10, 2009 4:05 AM
Subject: Re: [ADVANCED-DOTNET] 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 

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