WinDbg | Application memory full dump - Show file path of file handle
For post-mortem debugging (crash dump analysis), there's no way, except if you have a kernel dump (I can't tell you how to do that then). Windows will close handles of a process that terminated.
!handle combined with !handleex
There is handleex on Github.
Combine !handle and !handleex to get nice information.
.foreach /pS 1 /ps 1 (file {!handle 0 4 FILE}) { .echo Handle file; !handleex file; .echo }

Example output
0:007> .foreach /pS 1 /ps 1 (file {!handle 0 4 FILE}) { .echo Handle file; !handleex file; .echo }
Handle 4c
Object Type: File
Handle Name: \Device\HarddiskVolume3\Users\T

Handle 8c
Object Type: File
Handle Name: \Device\HarddiskVolume3\Windows\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.19041.1110_none_60b5254171f9507e

Handle b4
Object Type: File
Handle Name: \Device\HarddiskVolume3\Windows\System32\en-US\notepad.exe.mui

...

!handle combined with SysInternals Handle
You can combine the !handle WinDbg command and the SysInternals Handle tool.
Example notepad debugging session:
:018> !handle 0 1 FILE
Handle 4c
  Type          File
Handle 8c
  Type          File
Handle b8
  Type          File
Handle 134
  Type          File
...

Combined with the information from the console:
C:\...>handle -p notepad.exe | findstr 8C:
   8C: File          C:\Windows\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.19041.1110_none_60b5254171f9507e

C:\...>handle -p notepad.exe | findstr B8:
   B8: File          C:\Windows\System32\en-US\notepad.exe.mui

Automating it doesn't really work well:
0:007> .printf "%d\n",$tpid
2168
0:007> .foreach /pS 1 /ps 1 (file {!handle 0 4 FILE}) { .shell C:\handle.exe -p 2168 | findstr file: }

The process seems to be too slow and require too much user input.

I created a memory dump of an application with procdump -ma abc.exe.
The application access various files.
I run !handle 0 f FILE and get over 100 file handles.
When I get a specific handle address, I run the following command !handle 000000000000161c f which results in:
0:000> !handle 000000000000161c f
Handle 000000000000161c
  Type          File
  Attributes    0
  GrantedAccess 0x12019f:
         ReadControl,Synch
         Read/List,Write/Add,Append/SubDir/CreatePipe,ReadEA,WriteEA,ReadAttr,WriteAttr
  HandleCount   2
  PointerCount  65479
  No object specific information available

Is there a chance to retrieve the actual file path? Something like that: How get file path by handle in windbg? seems to work only in kernel mode debugging.
