-1

When a program is misbehaving, it is pretty easy to capture a memory dump of the process, and then analyze it with a tool like WinDBG. However, this is pretty limited, you only get a snapshot of what the process is doing, and in some cases finding why a certain part of the code was reached is really difficult.

Is there any way of capturing memory dumps for a period of time, like recording a movie rather than taking a picture, which would indicate what changed in that period of time, and the parts of the code that were executed in that time interval?

Tibi
  • 4,015
  • 8
  • 40
  • 64
  • 1
    https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/time-travel-debugging-overview Live debugging is still recommended, but you might try Time Travel Debugging. – Lex Li Oct 14 '20 at 15:29
  • Obviously, live debugging is best, but we can't setup a dev environment on a customer's machine, which is why we rely heavily on memory dumps. – Tibi Oct 15 '20 at 07:52
  • use [Windows Performance Toolkit, to capture memory usage grow](https://channel9.msdn.com/Shows/Defrag-Tools/Defrag-Tools-154-Memory-Footprint-and-Leaks) – magicandre1981 Oct 15 '20 at 13:17

1 Answers1

2

Recording many memory dumps

Is there any way of capturing memory dumps for a period of time, like recording a movie rather than taking a picture

Yes, that exists. It's called Procdump and you can define the number of dumps with the -n parameter and the seconds between dumps with -s. It might not work well for small values of s, because it takes longer to take the crash dump.

Example:

procdump -ma -n 10 -s 1 <PID> ./dumps

However, this technique is usually not very helpful, because you now have 10 dumps to analyze instead of just 1 - and analyzing 1 dump is already difficult. AFAIK, there's no tool that would compare two dumps and give you the differences.

Live debugging

IMHO, what you need is live debugging. And that's possible with WinDbg, too. Development debugging (using an IDE) and production debugging are two different skills. So you don't need to install a complete IDE such as Visual Studio on your customer's production environment. Actually, if you copy an existing WinDbg installation onto a USB stick, it will run portable.

Simply start WinDbg, attach to a process (F6), start a log file (.logopen), set up Microsoft symbols, configure exceptions (sx) and let the program run (g).

Remote debugging

Perhaps you may even want to have a look into WinDbg's remote debugging capabilities, however, that's a bit harder to set up, usually due to IT restrictions (firewall etc.).

Visual Studio also offers remote debugging, so you can use VS on your machine and just install a smaller program on your customer's machine. I hardly have experience with it, so I can't tell you much.

Logging

the parts of the code that were executed in that time interval?

The most typical approch I see applied by any company is turning on the logging capabilities of your application.

You can also record useful data with WPT (Windows Performance Toolkit), namely WPR (Windows Performance Recorder) and later analyze it with WPA (Windows Performance Analyzer). It will give you call stacks over time.

Thomas Weller
  • 55,411
  • 20
  • 125
  • 222