Background: 

Occasionally, I get leaks in my MFC [dApp](https://en.wikipedia.org/wiki/Decentralized_application) programs under development. MFC nicely dumps detected leak blocks out in the Output pane in Visual Studio showing their {block number} and hex address. Some leaks don't have source file paths and line numbers except to fx strcore.cpp etc. These leaks origins are hard-to-find and are in need of a better solution. 

Studying up on WinDbg Preview with its Time Travel Debugging (TTD), I can see how this would be the right tool to quickly find the hard MFC leaks.

Leak Find Test:

I created a small MFC program and put a leak in it:

```
void LeakInThread()
{
  int* intLeak = new int[ 500 ];
}

wchar* leak = new wchar[ 100 ];
std::thread t1( LeakInThread ); // added leak in thread
t1.join();   

```

The program produced: `{274698} normal block at 0x000001AFA34D9790, 200 bytes long.`

Using WinDbg I created a Trace file, Time Traveled to the end to make sure the leak was created, and used WinDbg commnd `!heap -i x000001AFA34D9790` to locate the TTD block where the error occurred. Here is the output:

`0:000> !heap -i 0x00000180F42E3790
Detailed information for block entry 00000180f42e3790
Assumed heap : 0x0000000000000000 (Use !heap -i NewHeapHandle to change)
Header content : 0xCDCDCDCD 0xCDCDCDCD
Block flags : 0x1 LFH (busy )
Total block size : 0x0 units (0x0 bytes)
Requested size : 0xffffec00 bytes (unused 0x1400 bytes)
Subsegment : 0x25dac2f1e46abc2eUser blocks not available`

Question: Is there a WinDbg command(s) that shows me the file and line number in the WinDbg source pane?

**Edit1:**

Experimented with this query command:

`dx -g @$MemRes = @$cursession.TTD.Resources.HeapMemory`

and got:

```
======================================================================================================================================
=           = ResourceId       = ResourceIdNew    = Size    = Function                   = ThreadId  = UniqueThreadId = Position     =
======================================================================================================================================
= [0x0]     - 0x180f4282870    - 0x0              - 0x4c    - ntdll!RtlAllocateHeap      - 0x59e4    - 0x2            - C819:58      =
= [0x1]     - 0x180f42b79d0    - 0x0              - 0x48    - ntdll!RtlAllocateHeap      - 0x59e4    - 0x2            - 5545:62      =
= [0x2]     - 0x180f4282870    - 0x0              - 0x0     - ntdll!RtlFreeHeap          - 0x59e4    - 0x2            - C827:13F     =
= [0x3]     - 0x180f42b32a0    - 0x0              - 0x6a    - ntdll!RtlAllocateHeap      - 0x59e4    - 0x2            - 2E1C:58      =
= [0x4]     - 0x180f744d330    - 0x0              - 0x24    - ntdll!RtlAllocateHeap      - 0x59e4    - 0x2            - 9609:4C      =
= [0x5]     - 0x180f74572e0    - 0x0              - 0x48    - ntdll!RtlAllocateHeap      - 0x59e4    - 0x2            - 960C:20D     =
= [0x6]     - 0x180f42b32a0    - 0x0              - 0x0     - ntdll!RtlFreeHeap          - 0x59e4    - 0x2            - 2E23:147     =
= [0x7]     - 0x180f42c1990    - 0x0              - 0x6a    - ntdll!RtlAllocateHeap      - 0x59e4    - 0x2            - FB23:58      =
= [0x8]     - 0x180f42d9fd0    - 0x0              - 0x0     - ntdll!RtlFreeHeap          - 0x59e4    - 0x2            - 12D1B:13F    =
= [0x9]     - 0x180f42c1990    - 0x0              - 0x0     - ntdll!RtlFreeHeap          - 0x59e4    - 0x2            - FB2A:147     =
= [0xa]     - 0x180f7453160    - 0x0              - 0x30    - ntdll!RtlAllocateHeap      - 0x59e4    - 0x2            - 9625:4C      =
= [0xb]     - 0x180f42c0810    - 0x0              - 0x6a    - ntdll!RtlAllocateHeap      - 0x59e4    - 0x2            - FB2E:58      =
= [0xc]     - 0x180f42b9160    - 0x0              - 0x0     - ntdll!RtlFreeHeap          - 0x59e4    - 0x2            - 2E25:4B      =
= [0xd]     - 0x180f42e9bd0    - 0x0              - 0x0     - ntdll!RtlFreeHeap          - 0x59e4    - 0x2            - 15481:13F    =
= [0xe]     - 0x180f42d9fd0    - 0x0              - 0x4c    - ntdll!RtlAllocateHeap      - 0x59e4    - 0x2            - 12D0D:58     =
= [...]

```

Since `ResourceID` looks similar to the MFC output address, I narrowed the output with this select query:

`dx -g @$MemRes.Where(x => x.ResourceId == 0x00000180F42E3790)`

but the output grid has no results.

**Edit2:**

"If the leak occurred in the MainFrame thread, the source file and line number are shown as well. No so when the leak occurred in another spawned thread." is not true. But leaks that don't point back to their source and line numbers do occur. There is still a possibility that the MFC debugger program is missing some source path defines allowing it to find the source code. More study is required.

**Edit3:**

On further review, the leaks produced from my MFC program, even with no keys pressed after launch, have different data addresses each time it is run. (The leaks were introduced many check-ins ago unnoticed until now). This means that I can't use WinDbg TTD's `dx ...` command to iterate through the trace's frames comparing data addresses to frame `LocalVariables` `Values` simply because the data addresses of the leaks will be different each time the program is run including when the Trace is being recorded. But, however, commands could be used to determine if a heap allocation is outstanding at the close of the program.