Re: A Very Troubled Application...
Peter vd Weerd <[email protected]> Wed, 10 Jun 2009 22:28:44 +0200
| Newsgroups | gmane.comp.windows.devel.dotnet.advanced |
|---|---|
| Message-ID | <[email protected]> |
Since the errors occur in the process where the COM-component is hosted, IMHO it makes no sense to restart the hosting app. Your problem is that the out-of-process COM component failed. That process should be restarted. (see my previous postings how to force that). I would suggest to trap all expected exceptions, and act appropriate on those. Unhandled exceptions should be handled by the ThreadException. On that delegate you can force the hosted process to restart, do some logging, etc. The hosting app (your app) is not compromised by the memory corrupting failures of the hosted process. So again, your application doesn't need to be restarted (and also not the appdomain). Just force the refcnt on the COM-object (euh, all COM objects in that process) to reach zero, and the hosted process will probably be gone... /Peter ----- Original Message ----- From: "Mike Andrews" <[email protected]> To: <[email protected]> Sent: Wednesday, June 10, 2009 8:16 PM Subject: Re: [ADVANCED-DOTNET] A Very Troubled Application... > It's a stand-alone application and not a component but it does have a .NET > wrapped COM component that I'm using. > I'm not using a ThreadException as Peter suggested, but instead looking > for > the exceptions that occur and then closing the executable and AppDomain > and > then restarting the application and AppDomain. I'm also writing some code > to trap for random error dialogs thrown by the application. > > > On Wed, Jun 10, 2009 at 12:29 PM, Adam Tuliper > <[email protected]>wrote: > >> Mike, this is indeed a component, and not a standalone application? >> if so did you try the ThreadException as Peter mentioned? >> >> On Wed, Jun 10, 2009 at 1:26 PM, Mike Andrews >> <[email protected]>wrote: >> >> > Yes, I'd be curious as well as to how the system cleans up after a >> fault. >> > I >> > know yesterday when I intentionally caused the app to crash numerous >> times >> > my system (Windows XP Pro) became unstable in that Explorer would just >> > randomly "hang" and not let you utilize the task bar; it was >> > ridiculous. >> > >> > I have a similar situation that I'm working on where instead of using >> Word >> > I'm using some other 3rd party app that behaves very poorly but the >> > issue >> > is >> > moot since I must use it and must adapt it to be a "server" >> > non-user-monitored application. I'm well on my way to it and I've done >> > a >> > majority of the work but solving cases where the application just fails >> is >> > a >> > very difficult endeavor. >> > >> > On Wed, Jun 10, 2009 at 11:22 AM, Adam Tuliper <[email protected] >> > >wrote: >> > >> > > we had to do the same hacks for word.. using it as server side doc >> > > generation before good pdf components were available to us and I >> > > recall >> > > word >> > > would fail after a while. that goodness we've come a long way : ) >> > > >> > > For dlls being cleaned at termination time.. library code segments >> > > are >> > > shared between processes (that reference the same lib). So there is >> only >> > > one >> > > code section in memory (unless specifically designated otherwise I >> > > believe). >> > > When LoadLibrary is called, ref count is incremented. So when a >> > > process >> > > crashes.. how does the system know what to decrement counts for? I >> don't >> > > believe it does.. and hence a potential memory issue with crashed >> > > appliations leaving resources around. If I'm not 100% correct on >> this.. >> > I >> > > would like to know a reference to how the system cleans up.. Id be >> > curious >> > > of the inner workings, this is all from rusty memory. >> > > >> > > >> > > >> > > >> > > >> > > On Wed, Jun 10, 2009 at 2:01 AM, Peter vd Weerd <[email protected]> >> > wrote: >> > > >> > > > When windows terminates a process, all system-resources are cleaned >> up. >> > > > Dll's too. They are loaded in the virtual address space, and the >> > address >> > > > space is removed at termination. >> > > > Reference counting on dll's is only within a process. AFAIK there >> > > > is >> no >> > > > system-wide refcnt. >> > > > >> > > > Dll's are loaded by creating a named filemapping to this dll. This >> > > mapping >> > > > is a normal system resource and will be freed at termination time. >> > > > >> > > > Out of process COM objects are a different story. The process where >> > this >> > > > COM-object lives has nothing to do with the hosting process (as far >> as >> > > the >> > > > system knowns). And it is refcnted. >> > > > >> > > > So if the host process is getting terminated, the only way for the >> COM >> > > > process to get auto terminated is to do a watchdog check on its >> > > > host >> if >> > > its >> > > > still alive. There are some watchdog checks in the standard >> marshalling >> > > code >> > > > (hartbeats), but I'm not sure if they are used for terminating the >> > > process >> > > > with the COM object. Another question is how big the timeout for >> > > > this >> > > > watchdog is. So may be you want to restart the COM object before >> > > > the >> > > > watchdog timed out. >> > > > >> > > > I used my proposed solution (restarting the process after failure) >> > > > a >> > few >> > > > times in case of untrusted applications, and it worked fine. I can >> > > remember >> > > > problems with MSWord (out of process COM) years ago. After failure >> (the >> > > > process using MSWord died) I killed the MSWord instance too and >> > > > than >> > > > restarted my application. Ugly, but it worked. >> > > > I had more problems there, because word was not designed as a >> service. >> > > Its >> > > > a UI, so it will popup a dialog every now and than. I had to >> > > > 'answer' >> > > those >> > > > dialogs too :-) >> > > > >> > > > /Peter >> > > > ----- Original Message ----- From: "Adam Tuliper" < >> > > [email protected]> >> > > > To: <[email protected]> >> > > > Sent: Tuesday, June 09, 2009 10:30 PM >> > > > Subject: Re: [ADVANCED-DOTNET] A Very Troubled Application... >> > > > >> > > > >> > > > >> > > > I seem to recall the opposite was true.. Windows isn't very good >> about >> > > >> cleaning up resources (at least in the past) because of the way >> > > libraries >> > > >> dont get freed because the reference count handling is never >> > executed.. >> > > >> something along those lines. Although if someone can provide some >> more >> > > >> technical reference on if this is true or not.. Id love to read >> > > >> it. >> > > >> >> > > >> >> > > >> >> > > >> On Tue, Jun 9, 2009 at 1: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 > =================================== View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives