Great idea! I didn't think of this. Two things I guess could affect the original poster however: 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.
Great idea nevertheless. I guess I'll add it to my virtual bag of tricks - this could become handy. Cheers, -Ingo Independent .NET and Web Services Consultant. Microsoft Regional Director - Austria. Author of "Advanced .NET Remoting". http://www.ingorammer.com Subscribe to Ingo Rammer's Architecture Briefings at http://www.ingorammer.com/NL -----Original Message----- From: Moderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Steve Johnson Sent: Wednesday, January 07, 2004 4:09 PM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Catching access violations Ingo Rammer wrote: > One possible workaround should therefore be to create a dummy windows > executable (which just starts and immediately exists) and register > this .exe as the system's JIT debugger.... Another solution would be to launch the process with the DEBUG_PROCESS flag. Then just enter a very simple WaitForDebugEvent() loop and monitor for first-chance exceptions. If you get an access violation (code 0xC0000005), just tear down the process. When you get the process exit debug event, exit your loop. -- Steve Johnson =================================== 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 =================================== 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
