which windbg command to locate heap block number or address?

[rtischer8277]

I am learning WinDbg Preview. My test program, LeakDbg, has this statement in it:

wchar* str = new wchar[100];

The program is MFC which dumps out this information:

Detected memory leaks!
Dumping objects ->
C:\Users\Amber8277\Documents\Visual Studio 2019\Projects\LeakDbg\MainFrm.cpp(47) : {274689} normal block at 0x00000280639412C0, 200 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
Object dump complete.

I have created a Trace and can Time Travel forwards and backwards. Which command(s) would I use to discover where this leak is?

 

[x BlueRobot]

Is this a user-mode application?

I would suggest reading this this series here for debugging memory leaks - Troubleshooting Pool Leaks Part 1 – Perfmon

However, I would take a look at commands like !poolused, !vm and !heap.

I am learning WinDbg Preview. My test program, LeakDbg, has this statement in it:

wchar* str = new wchar[100];

The program is MFC which dumps out this information:


I have created a Trace and can Time Travel forwards and backwards. Which command(s) would I use to discover where this leak is?

I assume that you're referring to time travel debugging? Time Travel Debugging - Overview - Windows drivers

 

[rtischer8277]

(Couldn't find the WinDbg Commands forum BlueRobot suggested)

For this MFC test program, LeakDbg, I get this output:

Detected memory leaks!
Dumping objects ->
C:\Users\Amber8277\Documents\Visual Studio 2019\Projects\LeakDbg\MainFrm.cpp(47) : {274689} normal block at 0x00000180F42E3790, 200 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
Object dump complete.

I have deliberately added a leak which I want to find using my new WinDbg skills:

wchar* leak = new wchar[ 100 ];

I created a Trace file and at the command line execute:

!heap -l

In Debugger.chm help says:

-l
Causes the debugger to detect leaked heap blocks.

The output of the WinDbg command is:

Searching the memory for potential unreachable busy blocks.
Heap 00000180f4270000
Heap 00000180d86e0000
Heap 00000180f4480000
Heap 00000180f5dd0000
Scanning VM ...QueryVirtual failed
No potential unreachable blocks were detected.

My questions:
- why does this command not return any information about the leak?
- I expected the {274689} normal block in the MFC output to pop out. Is the MFC "normal block" different from the Debugger.chm definition of "block"?
- can I use the ba 0x00000180F42E3790 4 to stop the forward time travel trace at the leak statement? Unfortunately not, since this command gives an unspecified syntax error.

Still learning WinDbg...

 

[x BlueRobot]

I've moved this thread into WinDbg commands sub forum which is part of the BSOD Academy section.

If you use the bell icon next to your user login, then you'll always be able to find the thread. Alternatively, you can check your previous posts from your user profile page.

 

[x BlueRobot]

Could you please post your test code and the dump file you're looking at? Have you examined the call stack to which native Windows calls it's making when performing the heap allocations?

From the WinDbg documentation on !heap:

These parameters work with Segment and NT heaps.

I haven't used C/C++ for a very long time so my knowledge is a little rusty in this area, and so, I can't remember exactly which system calls the new operator makes on Windows. However, have you used NotMyFault to practice troubleshooting memory leaks with WinDbg? NotMyFault - Windows Sysinternals

I'll continue looking into this for you.

Edit:

Just done a quick investigation, you may find the following helpful:

C++ supports dynamic allocation and deallocation of objects using the new and delete operators. These operators allocate memory for objects from a pool called the free store.

Source - new and delete Operators

The StackOverflow post provides a nice explanation of the difference between the heap and free store:

C++, Free-Store vs Heap

 

[x BlueRobot]

Okay, I've looked into memory allocations using the new operator, and it appears that the allocations are handled by Windows in the following manner:

1. Call HeapAlloc ~ kernel32.dll
2. Call RtlAllocateHeap ~ ntdll.dll
3. Call NtAllocateVirtualMemory ~ ntdll.dll

The sequence of operations will allocate an area within the process heap of your application, which can be an NT heap or a segment heap. Segment heaps were introduced with Windows 10 and have a slightly different structure to NT heaps, which are the traditional legacy heaps. Windows will decide which heap to use at runtime.

Now,the !heap extensions will work in our situation, however, it is understanding which parameters to use and when. I haven't used the !heap extension for a long time, since memory leaks are usually very rare in modern applications unless there is a very large leak.

With your test application, did you added the debugging directives as described here? How to detect memory leaks in MFC | codexpert blog

I believe that the exception is actually raised because the a corresponding delete statement has not been found with that variable, rather than the application actually experiencing a memory leak. Also, did you ensure that you were in the context of your application's process when you used !heap?

This article may useful too - manually Debugging native memory leaks