Thread View: borland.public.optimizeit.net.general
6 messages
6 total messages
Started by Mike Swaim
Thu, 15 Apr 2004 19:08
How do I tell where an application crashes?
Author: Mike Swaim
Date: Thu, 15 Apr 2004 19:08
Date: Thu, 15 Apr 2004 19:08
15 lines
1706 bytes
1706 bytes
I have a DB application that crashes consistently when run under the CPU profiler. Unfortunately, I can't tell where, because Windows pops up a dialog offering me the choice of debugging or terminating it. If I choose to debug, Visual Studio complains that it can't connect because there's another debugger already in use for the EXE. It works fine when run under the memory usage debugger, or in the Visual Studio debugger. One thing that we do that's apparently unusual is that the application loads two .net DLLs, each of which uses a different namespace from the EXE and each other. -- Mike Swaim swaim@hal-pc.org at home | Quote: "Boingie"^4 Y,W & D MD Anderson Dept. of Biostatistics & Applied Mathematics mpswaim@mdanderson.org or mswaim@odin.mdacc.tmc.edu at work Disclaimer: Yeah, like I speak for MD Anderson.
Re: How do I tell where an application crashes?
Author: Will McQueen
Date: Thu, 22 Apr 2004 17:39
Date: Thu, 22 Apr 2004 17:39
31 lines
2304 bytes
2304 bytes
Hi Mike, The CPU Profiler uses the debug API, but the Memory Profiler does not. So that's why using the Microsoft Visual Studio debugger together with the CPU Profiler will cause this error message of another debugger already in use. Using more than one debugger at the same time is not supported. Using just the Memory Profiler should not generate this error message. Hope this helps. Regards, - Will "Mike Swaim" <mswaim@odin.mdacc.tmc.edu> wrote in message news:407edd92$1@newsgroups.borland.com... > I have a DB application that crashes consistently when run under the > CPU profiler. Unfortunately, I can't tell where, because Windows pops > up a dialog offering me the choice of debugging or terminating it. If I > choose to debug, Visual Studio complains that it can't connect because > there's another debugger already in use for the EXE. It works fine when > run under the memory usage debugger, or in the Visual Studio debugger. > One thing that we do that's apparently unusual is that the > application loads two .net DLLs, each of which uses a different > namespace from the EXE and each other. > > -- > Mike Swaim swaim@hal-pc.org at home | Quote: "Boingie"^4 Y,W & D > MD Anderson Dept. of Biostatistics & Applied Mathematics > mpswaim@mdanderson.org or mswaim@odin.mdacc.tmc.edu at work > Disclaimer: Yeah, like I speak for MD Anderson. >
Re: How do I tell where an application crashes?
Author: Mike Swaim
Date: Fri, 23 Apr 2004 15:20
Date: Fri, 23 Apr 2004 15:20
22 lines
1765 bytes
1765 bytes
Will McQueen wrote: > Hi Mike, > > The CPU Profiler uses the debug API, but the Memory Profiler does > not. So that's why using the Microsoft Visual Studio debugger > together with the CPU Profiler will cause this error message of > another debugger already in use. Using more than one debugger at the > same time is not supported. > > Using just the Memory Profiler should not generate this error message. > > Hope this helps. Not really. The program _only_ crashes under the CPU profiler. What I'd really like to find out is where it dies and why. -- Mike Swaim swaim@hal-pc.org at home | Quote: "Boingie"^4 Y,W & D MD Anderson Dept. of Biostatistics & Applied Mathematics mpswaim@mdanderson.org or mswaim@odin.mdacc.tmc.edu at work Disclaimer: Yeah, like I speak for MD Anderson.
Re: How do I tell where an application crashes?
Author: Will McQueen
Date: Tue, 27 Apr 2004 01:49
Date: Tue, 27 Apr 2004 01:49
43 lines
2521 bytes
2521 bytes
Hi Mike, > Not really. The program _only_ crashes under the CPU profiler. What > I'd really like to find out is where it dies and why. Both the CPU Profiler and MS Visual Studio are attempting to use the debug API. This is the source of the problem. Here are some scenarios you can try: 1) If you want to use the Memory Profiler: Use MS Visual Studio and Memory Profiler at the same time Or 2) If you want to use the CPU Profiler: Profile your app with Optimizeit Profiler 1.1 for .Net with CPU Profiler, outside of MS Visual Studio. Regards, - Will "Mike Swaim" <mswaim@odin.mdacc.tmc.edu> wrote in message news:40893441$1@newsgroups.borland.com... > Will McQueen wrote: > > > Hi Mike, > > > > The CPU Profiler uses the debug API, but the Memory Profiler does > > not. So that's why using the Microsoft Visual Studio debugger > > together with the CPU Profiler will cause this error message of > > another debugger already in use. Using more than one debugger at the > > same time is not supported. > > > > Using just the Memory Profiler should not generate this error message. > > > > Hope this helps. > > Not really. The program _only_ crashes under the CPU profiler. What > I'd really like to find out is where it dies and why. > > -- > Mike Swaim swaim@hal-pc.org at home | Quote: "Boingie"^4 Y,W & D > MD Anderson Dept. of Biostatistics & Applied Mathematics > mpswaim@mdanderson.org or mswaim@odin.mdacc.tmc.edu at work > Disclaimer: Yeah, like I speak for MD Anderson. >
Re: How do I tell where an application crashes?
Author: Mike Swaim
Date: Wed, 28 Apr 2004 15:32
Date: Wed, 28 Apr 2004 15:32
28 lines
2020 bytes
2020 bytes
Will McQueen wrote: > Hi Mike, > > > Not really. The program only crashes under the CPU profiler. What > > I'd really like to find out is where it dies and why. > > Both the CPU Profiler and MS Visual Studio are attempting to use the > debug API. This is the source of the problem. Here are some > scenarios you can try: > > 1) If you want to use the Memory Profiler: Use MS Visual Studio and > Memory Profiler at the same time > Or > 2) If you want to use the CPU Profiler: Profile your app with > Optimizeit Profiler 1.1 for .Net with CPU Profiler, outside of MS > Visual Studio. That's what I did. I only tried loading the session into Visual Studio _after_ the application had crashed, and I got the dialog giving me the option of letting the application die, or try to load it into a debugger. -- Mike Swaim swaim@hal-pc.org at home | Quote: "Boingie"^4 Y,W & D MD Anderson Dept. of Biostatistics & Applied Mathematics mpswaim@mdanderson.org or mswaim@odin.mdacc.tmc.edu at work Disclaimer: Yeah, like I speak for MD Anderson.
Re: How do I tell where an application crashes?
Author: Will McQueen
Date: Fri, 30 Apr 2004 22:21
Date: Fri, 30 Apr 2004 22:21
66 lines
3987 bytes
3987 bytes
Hi Mike, The CPU Profiler connects to the .NET application using the debugger API exported via the process dll. When the .NET application crashes, the out-of-process application will still live and so the debug API that the process uses will still be active. That's why clicking the option (in the dialog box you mention) to load the .NET application into the debugger will cause the error message you describe of another debugger already in use. You mentioned that your application loads two .net DLLs, each of which uses a different namespace from the EXE and each other. But this seems to be the case for all .NET apps (using system.mscorelib does that). What could your .NET app be doing that's different from other .NET apps? Is there another .NET app you can test with the CPU Profiler to see if the issue occurs with it also? Regards, - Will "Mike Swaim" <mswaim@odin.mdacc.tmc.edu> wrote in message news:408fce92$1@newsgroups.borland.com... > Will McQueen wrote: > > > Hi Mike, > > > > > Not really. The program only crashes under the CPU profiler. What > > > I'd really like to find out is where it dies and why. > > > > Both the CPU Profiler and MS Visual Studio are attempting to use the > > debug API. This is the source of the problem. Here are some > > scenarios you can try: > > > > 1) If you want to use the Memory Profiler: Use MS Visual Studio and > > Memory Profiler at the same time > > Or > > 2) If you want to use the CPU Profiler: Profile your app with > > Optimizeit Profiler 1.1 for .Net with CPU Profiler, outside of MS > > Visual Studio. > > That's what I did. I only tried loading the session into Visual > Studio _after_ the application had crashed, and I got the dialog giving > me the option of letting the application die, or try to load it into a > debugger. > > -- > Mike Swaim swaim@hal-pc.org at home | Quote: "Boingie"^4 Y,W & D > MD Anderson Dept. of Biostatistics & Applied Mathematics > mpswaim@mdanderson.org or mswaim@odin.mdacc.tmc.edu at work > Disclaimer: Yeah, like I speak for MD Anderson. > > I have a DB application that crashes consistently when run under the > CPU profiler. Unfortunately, I can't tell where, because Windows pops > up a dialog offering me the choice of debugging or terminating it. If I > choose to debug, Visual Studio complains that it can't connect because > there's another debugger already in use for the EXE. It works fine when > run under the memory usage debugger, or in the Visual Studio debugger. > One thing that we do that's apparently unusual is that the > application loads two .net DLLs, each of which uses a different > namespace from the EXE and each other. > > -- > Mike Swaim swaim@hal-pc.org at home | Quote: "Boingie"^4 Y,W & D > MD Anderson Dept. of Biostatistics & Applied Mathematics > mpswaim@mdanderson.org or mswaim@odin.mdacc.tmc.edu at work > Disclaimer: Yeah, like I speak for MD Anderson
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads