I'm using SysInternal's handle.exe and I'm trying to understand the output.
Here's a snippet:
24C: File (RW-) C:\Program Files (x86)\Google\Chrome\Application\Dictionaries\en-US-8-0.bdic
2E8: Section \Sessions\1\BaseNamedObjects\CrSharedMem_5ae414b12a307dbddc3f42b8b35edcbf313107945050b3aaab1602ecd937c940
2F4: Section \Sessions\1\BaseNamedObjects\CrSharedMem_ccfa88ab65617b75dbdcb72cb6512bf1a9cc76d07a25e9f770b46f4f7c2234bf
314: File (R--) C:\Windows\Fonts\arial.ttf
324: File (R--) C:\Windows\Fonts\arialbd.ttf
328: File (R--) C:\Windows\Fonts\arialbi.ttf
The first column is the HANDLE value, it serves as the unique identifier of the OS kernel object. Like the ID column of a database record. It is only useful if you need to compare it with what the debugger tells you when you debug code.
The second column identifies the type of OS object. "File" is obvious, a "Section" is an object that allows processes to share memory. "Memory mapped file" is the usual phrase in programming. "Mutant" tends to be confusing, it is a mutex in normal speech. The author of the program uses the kind of terms that David Cutler likes, he speaks with a VMS lisp. The WinObj utility is another way to look at these kernel objects.
The letters in parentheses are the sharing options specified when the object was created. The third argument to CreateFile. Important to know since it tells you what another program can do when it also wants to access the object. R says that it can read, W says that it can write, D says that it can delete the object without affecting anybody else that uses the object. The object won't be destroyed until everybody closes their handle. An anti-malware scanner or search indexer are typical examples of programs that use delete sharing.