3

I'm the maintainer of a legacy Delphi application. On machines running this program an Application Error appears sometimes with the caption referring to this Delphi app and a message like the following:

The instruction at "..." referenced memory at "...". The memory could not be "read".

Click on OK to terminate the program.

Task Manager says the process belonging to this message box is csrss.exe. What would be a systematic way to find the root cause of this error?

The problem is, this Delphi program is fairly complex, and the error message appear relatively rarely, so I cannot simply step-through the code and find the part which causes the error. Moreover, the app runs automatically, without user interruption, so I can't ask the user what she does when the message appears. Application and system logs don't indicate any problem. The app does not stop working when the message box is present.

I hope someone has run into such an error message before and was able to solve the problem. Thank you for your help in advance.

kol
  • 27,881
  • 12
  • 83
  • 120

2 Answers2

7

csrss supports Windows consoles. I expect that your application targets the console subsystem.

If you cannot get your application to fail under the debugger then you need to add some diagnostics to it. I recommend using an tool like madExcept or EurekaLog to do this. Personally I use madExcept and cannot recommend it highly enough. From what I have heard, EurekaLog is also a fine product.

Integrate one of these tools with your application and the next time it faults it will produce a detailed diagnostics report. Most significantly you will get stack traces for each thread in your process. The stack trace for the faulting thread should hopefully lead you to the root cause of your program's bug.

The doubt I have is that if the fault is occurring in csrss then including diagnostics in your process may not to yield fruit. It's plausible that your application already faulted, which in turn led to the error message in csrss. In which case diagnostics in your app will help. If not then you may need to find a way to make the fault occur in your process.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
  • +1 Thank you, David. We do use Eureka in the development phase, but it's turned off in the release version. I'm definitely going to give it a try today, and report here what I find. – kol Feb 12 '13 at 12:08
  • 3
    Turned off in the release version?! Why would you do that?! That's exactly when you need it. I probably fix around one bug a month purely from customer supplied ME bug reports. That stuff is like gold dust. – David Heffernan Feb 12 '13 at 12:10
  • You are right, but in this case there is no user, because the app runs automatically. The problem is that Eureka opens a nice message box on every exception, and halts the app, which is unacceptable in this case. – kol Feb 12 '13 at 12:36
  • 1
    I don't know about Eureka, but surely these things can be configured. They certainly can for ME. For ME you can save the diagnostics to a file. I do exactly that in the DLL version of my code which can run without UI. Surely you can do the same for Eureka. – David Heffernan Feb 12 '13 at 12:39
  • We have been using version 6 for a long time, and AFAIR the message box could not be turned off for GUI apps (an ELF file is also written). We changed to the latest version recently, so I should check this out again. – kol Feb 12 '13 at 12:44
  • I'm sure you know better than I do. I do know that ME is completely configurable in this regard. – David Heffernan Feb 12 '13 at 12:47
  • 1
    I can attest that ME is configurable to not show anything but I would be very surprised if Eureka isn't. – Lieven Keersmaekers Feb 12 '13 at 12:57
6

In addition to David's recommendation I would recommend using procdump from sysinternals to monitor the process and have it write a dumpfile when an unhandled exception occurs.

You can analyze the dumpfile offline with Windbg and the likes. While that might seem overwelming at first, I strongly believe there's a lot to be gained by getting yourself up to speed with Windbg.

Introduction

ProcDump is a command-line utility whose primary purpose is monitoring an application for CPU spikes and generating crash dumps during a spike that an administrator or developer can use to determine the cause of the spike. ProcDump also includes hung window monitoring (using the same definition of a window hang that Windows and Task Manager use), unhandled exception monitoring and can generate dumps based on the values of system performance counters.

Example

Launch a process and then monitor it for exceptions:

   C:\>procdump -e 1 -f "" -x c:\dumps consume.exe
Lieven Keersmaekers
  • 57,207
  • 13
  • 112
  • 146