4

I need a Windows tool that records inputs and debugging information that cause program's crashing. I don't mean a fuzzing software tool! For example, let me describe a scenario to explain what I'm talking about.

Sometimes while using a program, it will crash without a known reason, and when I want to debug it, I can't find helpful informations to know how the crash happened because the data that caused the crash no longer exists anywhere.

So I need a tool records all the inputs and debugging information to be able to reuse the input data and reproduce the crash under a debugger like Immunity Debugger and OllyDbg in order to understand how the crash happened.

EDIT: I need to be able to do this for a program that I did not write. Assume that I do not have access to view or modify its source code.

  • 1
    My compiler tools didn't come with a "debaucher". I'm so disappointed....I might have to write my own! (Sorry to tease you about your English, Barakat, but if you look up the English definition of "debauchery" I think you'll agree that it's hilarious in this context.) – Jim Lewis Jan 11 '11 at 06:59
  • @Jim Lewis: My IDE did. I think they call it "Intellisense". It's definitely "led me away from excellence or virtue". ;-) – Cody Gray - on strike Jan 11 '11 at 07:06
  • @Cody: I guess I was thinking more along the lines of adb or similar tools. "Go on...reset that flag...you know you want to! What's the worst that could happen?" But I suppose Intellisense fits the definition in its own way. – Jim Lewis Jan 11 '11 at 07:23
  • @Barakat: I'm still not sure what a "fuzzing" tool is. Is that a language translation issue or a typo? Also, it would be easier to provide a good answer if you edited your question to specify the language/compiler/IDE that you're using to write your application. – Cody Gray - on strike Jan 11 '11 at 07:25
  • 1
    @Cody: I've heard the term "fuzzing tool" before...the idea is to present the program under test with a stream of random-ish input, packets, or events, and see how it holds up to unexpected or invalid input. – Jim Lewis Jan 11 '11 at 08:02

3 Answers3

1

What compiler/IDE are you using?

Chances are, it includes a debugger that you can attach to any running process (like your application), whether you started it from within the IDE or not. This will allow you to see the current values of variables and present you with a stack trace (or helpful diagnostic information) whenever your program crashes unexpectedly. The debugger that comes with Visual Studio is particularly good, if you're developing a C++ or .NET application.

Another option is to implement extensive logging functionality in your application. You can write out detailed information about the program's current state at periodic intervals to a file or into the Windows Event Log, and then examine this information after a crash. This is particularly helpful if you're trying to debug errors that occur at a client's site because they can just send you the log file to analyze.

If you're talking about recording a particular set of user input that is causing your application to crash, logging is probably the best option.

There are some logging libraries you can use to make this job easier. Without knowing what language you're working in, however, it's difficult to make specific recommendations. For example, if you're developing a .NET application, Log4Net is an excellent choice. I've heard good things about Log4j for Java development. log4cxx is an option for C++ apps. Also see this question concerning best practices.

Community
  • 1
  • 1
Cody Gray - on strike
  • 239,200
  • 50
  • 490
  • 574
  • What if the program already exist and It doesn't have crash and debugging logs? I believe that I can use it only if I was the program's developer. –  Jan 11 '11 at 08:35
  • @Barakat: You're right; you're not going to be able to add logging to a program whose source code you can't access. It wasn't clear from your question that you were not the developer of the program in question. In that case, the only option you have is attaching a debugger to the program's running process or installing a keystroke logger on the user's computer. – Cody Gray - on strike Jan 11 '11 at 08:38
0

I guess the stack trace must help you to debug the issue. You can use

windbg

or

Debugdiag

tool to get the crash dumps. I have found that really useful

ckv
  • 10,539
  • 20
  • 100
  • 144
0

You told that you have to debug a code that you didn't write having no code to see.
In my experience it's not so easy but...
You can configure drwtsn32, if still present on you S.O., to write output files when the program crashes.

Old styled output is drtwsn32.log (Windows Version from NT 4.0 to actual Windows 7 places that file in different location on disk, just look around for that file) that gives you the stack trace, registries and a small amout of memory dump. Acutally you should have the .map file of the original program in order to identify the function that crashes and even the line of code in which the crashes occur (there's a handy method I started using a long time ago... but you need a full MAP file).

More recent version of drwtsn32 produce a set o files. They ar

  • appcompat.txt
  • manifest.txt
  • program.exe.hdmp
  • program.exe.mdmp

They are memory and process dump. Open it with a Microsoft IDE/Debugger as Visual Studio 2008/2010 and see.
It shows the full call stack, memory status, all registries and so on. If you also have the .pdb file of the program that crashes, you should be able to know which is the funcion and the code line but... without source file you're running in darkness, I guess.

So... MAP file or PDB file should be present or I think you'll face a very hard work.

HTH

Mr.Gate
  • 419
  • 4
  • 12