hCO[_7>\fEnFTH]^CT1A^BL@[^6iTbKebAoFY]37908FB`ET   
      
   By the way:   
      
   there exists a subfunction for DosSysCtl that can prevent a thread other    
   than thread 1 to call DosExit.   
   I think this DosSysCtl subfunction was invented when they created the    
   Warpzilla browser.   
   I guess you call the DosSysCtl once and then, no plugin can call DosExit (or    
   rather it will have no effect)   
   from its user-thread (which is most likely not thread 1):   
      
   http://www-01.ibm.com/support/docview.wss?uid=swg1PJ29697   
      
   In case IBM deletes the page, here is the text:   
      
   This APAR does NOT fix anything. Rather, it provides a debugging   
   tool capability. There have been numerous problems where a web   
   browser (and other kinds of programs) have "disappeared" from   
   the screen -- in fact, exited -- with no explanation. This is   
   usually because a browser plugin or java executable have called   
   DosExit while running in a helper thread. This APAR change adds   
   a new kernel API that optionally disallows calling DosExit (for   
   process scope) from threads other than the main process thread   
   (thread 1). A process name is passed in, and "add" or "delete"   
   is specified. Once a process name is added, if a tid>1 calls   
   DosExit to exit the process, a fatal argument fault is thrown,   
   instead. This results in a sys3175 for the process. At that   
   point, the registers can be reviewed, or a dump can be analyzed   
   (if system or process dump is enabled). The API info follows:   
   extern APIRET APIENTRY DosSysCtl(ULONG func, ULONG namep);   
   struct {   
       char *name;              // for example, "mozilla"   
       unsigned long action;    // 1=add, 0=remove   
   } parms;   
   rc = DosSysCtl(31, (ULONG) &parms);   
      
      
      
   Lars   
      
      
      
   "Steven Levine"  schrieb im Newsbeitrag    
   news:11p86vVJT4Oe-pn2-dHh7FG4L8rm1@slamain.slainc.com...   
   > On Thu, 21 Apr 2011 03:33:11 UTC, "Rich Walsh"   
   >  wrote:   
   >   
   > Hi Rich,   
   >   
   >> My impression is that Firefox 4.0 GA is much less crash-prone than any   
   >> of the betas.  So far, the only crashes reported have been in    
   >> TCPIP32.DLL.   
   >> While any crash is unfortunate, the number and variety of problems seem    
   >> to   
   >> be significantly reduced.  Is this the case or is it just wishful    
   >> thinking?   
   >   
   > This appears to be the case here.  There appears to be an intermittent   
   > problem storing cookie exceptions, but this is surprisingly difficult   
   > to analyze.  It generates a popuplog, rather than a .trp file.  I need   
   > to capture a process dump.   
   >   
   > I also see XCPT_PROCESS_TERMINATE in doscall1.dll.  These occur when   
   > the flash plugin (I assume) hangs while trying to exit.   
   >   
   > Steven   
   >   
   >   
   > --    
   > ---------------------------------------------------------------------   
   > Steven Levine    
   > eCS/Warp/DIY etc. www.scoug.com www.ecomstation.com   
   > ---------------------------------------------------------------------    
      
      
   --- Internet Rex 2.31   
    * Origin: Arcor (1:261/20.999)