Application crash
in [Win32 API]
|
From: Piranha on 2 Apr 2010 08:32 I have a multithreaded application, or better I´m developping one. So far it doesn´t work properly, meaning, it will crash once in a while, showing the typical Windows error message "Application caused errors and must be closed" or something similar. I´m aware, Windows replaces at this time the application window with a ghost window, while the actual application is already gone. Anyway, after clicking OK and restarting the application, something remains in the system, meaning CPU usage and memory usage slightly increases, but Task Manager doesn´t show anything, or better doesn´t give me any indication why. My guess is, that one of the threads in the application might still be running after the crash, but that´s plain guesswork. The obvious solution is to reboot my PC, and the long term solution is to fix the bug(s), but I´m wondering, is there a way to clean up the leftovers from the crash without rebooting?
From: Bob Masta on 3 Apr 2010 09:15 On Fri, 2 Apr 2010 05:32:06 -0700 (PDT), Piranha <eu_piranha(a)gmx.net> wrote: >I have a multithreaded application, or better I=B4m developping one. >So far it doesn=B4t work properly, meaning, it will crash once in a >while, showing the typical Windows error message "Application caused >errors and must be closed" or something similar. > >I=B4m aware, Windows replaces at this time the application window with a >ghost window, while the actual application is already gone. >Anyway, after clicking OK and restarting the application, something >remains in the system, meaning CPU usage and memory usage slightly >increases, but Task Manager doesn=B4t show anything, or better doesn=B4t >give me any indication why. > >My guess is, that one of the threads in the application might still be >running after the crash, but that=B4s plain guesswork. > >The obvious solution is to reboot my PC, and the long term solution is >to fix the bug(s), but I=B4m wondering, is there a way to clean up the >leftovers from the crash without rebooting? If you are using XP (but not Vista or 7, alas!) you can get a crash report from DrWatson. The first time you do this, it's a bit of a struggle to find out where the report is hidden. There is a "proper" way to do that, which I've forgotten, but here is the basic idea: The path is "C:\Documents and Settings\All Users\ Application Data\Dr Watson\drwtsn32.log". Once you have it, you can create a desktop icon that opens this location in Notepad (for future crashes!). Note that drwtsn32.log contains *all* the crash reports that ever happened on your system, so it might be quite long. (In the future, you can delete this file or rename it, and a new drwtsn32.log will be created for the next crash.) If you scroll to the end, you'll see the report for the most recent crash. The last section of the report is a stack dump, which I have never found too useful. But just before that is the disassembly of the code that caused the crash. There will be a full page of code, with the offending instruction in the middle marked 'FAULT ->'. The column on the left is the memory location of the instruction. If it is in your own code area (004xxxxx) then you are in luck, otherwise the crash may have been in a Windows DLL, etc, where the report doesn't help much. Assuming it is in your own code, look just before the code listing to find the register contents at the time of the crash. Typical problems are divide overflow or pointer out of range, which the registers can help you figure out. The biggest problem may be figuring out exactly where in your source code this fault code lies. It's not too bad if you can recognize some "signpost" in the disassembly, something that is used in only a few places. Otherwise, you may have to resort to crude methods, like adding code (at the *end* of your existing code, so you don't mess up the addresses) that displays the locations of various source code blocks during normal running. Then you can use trial and error to home in on the offending part. Hope this helps! Bob Masta DAQARTA v5.10 Data AcQuisition And Real-Time Analysis www.daqarta.com Scope, Spectrum, Spectrogram, Sound Level Meter Frequency Counter, FREE Signal Generator Pitch Track, Pitch-to-MIDI DaqMusic - FREE MUSIC, Forever! (Some assembly required) Science (and fun!) with your sound card!
From: Piranha on 3 Apr 2010 09:45 On 3 Apr., 15:15, N0S...(a)daqarta.com (Bob Masta) wrote: > On Fri, 2 Apr 2010 05:32:06 -0700 (PDT), Piranha > > > > > > <eu_pira...(a)gmx.net> wrote: > >I have a multithreaded application, or better I=B4m developping one. > >So far it doesn=B4t work properly, meaning, it will crash once in a > >while, showing the typical Windows error message "Application caused > >errors and must be closed" or something similar. > > >I=B4m aware, Windows replaces at this time the application window with a > >ghost window, while the actual application is already gone. > >Anyway, after clicking OK and restarting the application, something > >remains in the system, meaning CPU usage and memory usage slightly > >increases, but Task Manager doesn=B4t show anything, or better doesn=B4t > >give me any indication why. > > >My guess is, that one of the threads in the application might still be > >running after the crash, but that=B4s plain guesswork. > > >The obvious solution is to reboot my PC, and the long term solution is > >to fix the bug(s), but I=B4m wondering, is there a way to clean up the > >leftovers from the crash without rebooting? > > If you are using XP (but not Vista or 7, alas!) > you can get a crash report from DrWatson. The > first time you do this, it's a bit of a struggle > to find out where the report is hidden. There is > a "proper" way to do that, which I've forgotten, > but here is the basic idea: The path is > "C:\Documents and Settings\All Users\ Application > Data\Dr Watson\drwtsn32.log". Once you have it, > you can create a desktop icon that opens this > location in Notepad (for future crashes!). > > Note that drwtsn32.log contains *all* the crash > reports that ever happened on your system, so it > might be quite long. (In the future, you can > delete this file or rename it, and a new > drwtsn32.log will be created for the next crash.) > > If you scroll to the end, you'll see the report > for the most recent crash. The last section of > the report is a stack dump, which I have never > found too useful. But just before that is the > disassembly of the code that caused the crash. > There will be a full page of code, with the > offending instruction in the middle marked 'FAULT > ->'. > > The column on the left is the memory location of > the instruction. If it is in your own code area > (004xxxxx) then you are in luck, otherwise the > crash may have been in a Windows DLL, etc, where > the report doesn't help much. > > Assuming it is in your own code, look just before > the code listing to find the register contents at > the time of the crash. Typical problems are > divide overflow or pointer out of range, which the > registers can help you figure out. > > The biggest problem may be figuring out exactly > where in your source code this fault code lies. > It's not too bad if you can recognize some > "signpost" in the disassembly, something that is > used in only a few places. Otherwise, you may > have to resort to crude methods, like adding code > (at the *end* of your existing code, so you don't > mess up the addresses) that displays the locations > of various source code blocks during normal > running. Then you can use trial and error to home > in on the offending part. > > Hope this helps! > > Bob Masta > > DAQARTA v5.10 > Data AcQuisition And Real-Time Analysis > www.daqarta.com > Scope, Spectrum, Spectrogram, Sound Level Meter > Frequency Counter, FREE Signal Generator > Pitch Track, Pitch-to-MIDI > DaqMusic - FREE MUSIC, Forever! > (Some assembly required) > Science (and fun!) with your sound card!- Zitierten Text ausblenden - > > - Zitierten Text anzeigen - Thanks for the answer. My problem is not to figure out why it crashed, or how to fix the bug, in most cases it´s a new function I just added, where I have a typo in the code or something, easily fixed. My problem is that after the crash my PC seems to run slower, higher CPU and memory usage, without anything in Task Manager that could explain why. I figured, maybe something from the crashed application remains in memory, or some thread keeps running, even though the system should clean that up, maybe it just doesn´t. After rebooting my PC it´s all back to normal, but during development, with frequent application crashes it costs a LOT of time to reboot my PC after every application crash. So the question is, how do I cleanup CPU and memory usage, without rebooting my PC.
From: David Schwartz on 6 Apr 2010 00:08 On Apr 3, 6:45 am, Piranha <eu_pira...(a)gmx.net> wrote: > My problem is that after the crash my PC seems to run slower, higher > CPU and memory usage, without anything in Task Manager that could > explain why. > I figured, maybe something from the crashed application remains in > memory, or some thread keeps running, even though the system should > clean that up, maybe it just doesn´t. > After rebooting my PC it´s all back to normal, but during development, > with frequent application crashes it costs a LOT of time to reboot my > PC after every application crash. > So the question is, how do I cleanup CPU and memory usage, without > rebooting my PC. You can track down the cause of the higher CPU by looking at what process is using the CPU. Higher memory usage is not an issue -- virtual memory is not a scarce resource. DS
From: Arny on 6 Apr 2010 19:53 On 02.04.2010 14:32, Piranha wrote: > I have a multithreaded application, or better I�m developping one. > So far it doesn�t work properly, meaning, it will crash once in a > while, showing the typical Windows error message "Application caused > errors and must be closed" or something similar. > > I�m aware, Windows replaces at this time the application window with a > ghost window, while the actual application is already gone. > Anyway, after clicking OK and restarting the application, something > remains in the system, meaning CPU usage and memory usage slightly > increases, but Task Manager doesn�t show anything, or better doesn�t > give me any indication why. > > My guess is, that one of the threads in the application might still be > running after the crash, but that�s plain guesswork. > > The obvious solution is to reboot my PC, and the long term solution is > to fix the bug(s), but I�m wondering, is there a way to clean up the > leftovers from the crash without rebooting? Windows should clean everything up afterwards, but of course that's not always the case. Instead of rebooting, just log out and in again. Works like a charm when debugging faulty system-wide hooks. An invaluable tool you should take a look at is "process explorer" from sysinternals. - RaZ
|
Pages: 1 Prev: Any body know about Dia2Dump SDK and its usage? Next: Button font color? |