> the "main" > > application needs to run with local admin/debug privileges > and this might > > (not sure here about the amount) affect the secondary application's > > performance. > > Good point. That's probably prohibitive in most cases. I didn't > think of *that*. ;) > >
It's definitely prohibitive. Each time a 'debug event'[1] occurs, the child process is suspended while control transfers to the debugging application. One alternative worth exploring if (a) you (the original poster) can confirm that the dialog box being displayed actually is the standard OS dialog box for unhandled exceptions and (b) you're okay with a solution that works on >= Windows 2000 & XP is job objects. As the spawning process, you should be able to do something like so: (1) Create a job object (using CreateJobObject). (2) Configure it to force SetErrorMode to be called such that the standard unhandled exception dialog is never displayed and, instead, the process immediately dies (using SetInformationJobObject with JOBOBJECT_BASIC_LIMIT_INFORMATION.LimitFlags = JOB_OBJECT_LIMIT_DIE_ON_UNHANDLED_EXCEPTION). (3) Create a completion port that's not bound to anything in particular (using CreateIoCompletionPort). (4) Configure the job object such that you receive notifications whenever job limits (like the one set in 2) are reached (using SetInformationJobObject with JOBOBJECT_ASSOCIATE_COMPLETION_PORT filled out to refer to the IOCP created in 3). (5) Kick of a dedicated thread to hang out and wait on the IOCP for notifications (using GetQueuedCompletionStatus). (6) Spawn the application in suspended mode so that it doesn't run right away. (7) Associate the app spawned in 6 with the job object (using AssignProcessToJobObject). It's been a few years since I've done this (Windows 2000 was in beta), but this approach worked as advertised once upon a time. If what you're seeing is a win32 unhandled exception in the spawned process, then this is exactly what the JOB_OBJECT_LIMIT_DIE_ON_UNHANDLED_EXCEPTION feature of jobs objects was designed to address. It will probably be easier to write a little MC++ library to wrap the usage of the above mentioned Win32 apis and basically take care of 1-7, then just fire one of two discriminated events back to your managed code when the child app terminates (one for a normal exit, another if the app terminated unexpectedly). If the application is *not* incurring a true win32 unhandled exception, but some other modal dialog box, the above won't help in the least. -Mike http://www.bearcanyon.com [1] Refer to the docs on the DEBUG_EVENT structure in MSDN, but each thread start or stop and each dll load & unload qualifies as a debug event. So depending on the app there could be quite a few of these. =================================== This list is hosted by DevelopMentorŪ http://www.develop.com Some .NET courses you may be interested in: NEW! Guerrilla ASP.NET, 26 Jan 2004, in Los Angeles http://www.develop.com/courses/gaspdotnetls View archives and manage your subscription(s) at http://discuss.develop.com
