Hunt for application errors coming from csrss.exe
I am maintaining a legacy Delphi application. On machines running this program, Application Error
it sometimes appears with a title related to this Delphi application and the following message:
The instruction on "..." refers to memory in "...". The memory cannot be "read".
Click OK to complete the program.
The task manager says that the process associated with this message is csrss.exe . What would be a systematic way to find the root cause of this error?
The problem is that this Delphi program is quite complex and the error message appears relatively infrequently, so I can't just skip through the code and find the part that is causing the error. Also, the app starts automatically, without interrupting the user, so I can't ask the user what it is doing when the message appears. The application and system logs do not indicate any problems. The application does not stop working when a message box is present.
I hope someone has encountered such an error message before and was able to resolve the issue. Thank you for your help.
source to share
csrss
supports Windows console. I expect your application to target the console subsystem.
If you can't get your application to fail under the debugger, you need to add some diagnostic data to it. I recommend using a tool like madExcept or EurekaLog for this. I personally use madExcept and cannot recommend it highly enough. From what I've heard, EurekaLog is also a great product.
Integrate one of these tools with your application, and the next time it runs, you get a detailed diagnostic report. The most important thing is that you get a stack trace for every thread in your process. The stack trace for the thread crash will hopefully lead you to the root cause of your program's error.
I have a doubt that if an error occurs in csrss
, then the diagnostics in your process may not bear fruit. It is likely that your application has already crashed, which in turn resulted in an error message in csrss
. In this case, diagnostics in your application will help. If not, you may need to find a way to make a mistake in your process.
source to share
In addition to David's recommendation, I would recommend using procdump from sysinternals to track the process and force it to write a dump file when an unhandled exception occurs.
You can parse the dumpfile offline using Windbg and the like. While it may seem overwhelming at first, I strongly believe there is a lot to be gained from achieving speed with Windbg.
Introduction
ProcDump is a command line utility whose main purpose is to monitor an application for CPU spikes and create crash dumps during which an administrator or developer can use to determine the cause of the spike. ProcDump also includes verified window control (using the same window definition as Windows and Task Manager), unhandled exception monitoring, and can generate dumps based on system performance counter values.
Example
Start the process and then check it for exceptions:
C:\>procdump -e 1 -f "" -x c:\dumps consume.exe
source to share