How to execute WinDbg commands in regular intervals?

Question

I'd like to execute some commands in WinDbg in regular intervals, e.g. every minute. In this particular case I'd like to get the handle statistics (!handle) and .NET object statistics (!dumpheap -stat) to build a graph. As a workaround I'm currently using procdump and creating a dump every minute, but this takes a lot of hard disk space (full minidump for .NET) and requires me to analyze all dumps later (automated by scripts).

How can I execute WinDbg commands in regular intervals?

Assumptions: User mode live debugging. The target application is running all time. The command ends on ;g so that it will continue to run after the command has been executed. Timing does not need to be exact, especially the execution time of the command doesn't matter.

Before I start implementing my own debugger with the debugger engine, I thought I could ask if it is possible by the means of WinDbg itself.

Answer 1

You can use WMemoryProfiler which exposes the MDbg class (Managed debugger which is basically Windbg + SOS Loaded) and use a managed application to control the debugger and execute comamnds on it.

Or you use ClrMD which allows you do execute the SOS commands without Windbg on a live process from a managed process as well which is the future supported way.

To find handle leaks I have employed an alternative route. You can hook the Api calls which allocates and frees the handles (e..g EasyHook to hook any Api with managed code). In your hook you can then emit an ETW event which can be enabled e.g. via xperf of the Windows Performance Toolkit. The coolness of this approach is that you can log in your ETW event the handle allocate and free calls and get a log file which you can parse to find the outstanding calls which are the ones of your leak. Since I did log it via an ETW event I get full call stacks from the kernel to the RtlThreadStart method including a full managed call stack which is much more helpful if you are tracking handle leaks in managed applications. For an example what you can do with it check this. This approach is the best I have found so far because it does not slow the application down at all like Windbg does and you can monitor your application basically impact free a very long time.